[knome]

if they're going to be arbitrarily against env vars, like CURL_HOME, CURL_SSL_BACKEND, CURL_CA_BUNDLE, or the other dozen-ish variables curl already checks, an option in could .curlrc seem reasonable.

of course, having a CURL_ALLOW_ONION would allow the oniux program to set it, which would very easy and straight forward for both sides.

alternately, oniux could itself run a proxy and set the appropriate proxying environment variable, like HTTPS_PROXY. This would have the advantage of curl not having to do anything, but would add a rather ugly bit of complication to oniux.

seeing as the ability to run and inform curl of a proxy means oniux can already bypass the onion blocking with an envvar, adding one specifically to do that is convenient for callers, and does not expose the user to parent programs controlling onion exposure any more than it already does.

at best you could argue that requiring a full proxy makes it slightly harder for naive users to accidentally expose themselves since it would raise the bar for exposure from what curl knows, being the env var, to what curl has, in the form of an available proxy endpoint, but this isn't really a great excuse not to implement the CURL_ALLOW_ONION env var.

it's nice that curl is helpful for blocking by default, but having curl require the user to jump through hoops to unblock onion is a bit much.

[remram]

This doesn't really fix the problem. Curl is not the only tool to have implemented this block, many tools have, this was the point of Tor requesting this mechanism via an RFC. Is oniux going to set hundreds of environment variables to deactivate the block in all programs they know about? And cause users to send bug reports to all programs complying with their RFC that their tool doesn't yet know the workaround for?

The fix is much simpler: have oniux set $http_proxy (and drop non-tor traffic). This is the mechanism that makes the more sense and is in line with their own RFC.

[nytpu]

Almost like those existing env vars made it clear that they were mistakes that make behavior inconsistent (especially libcurl) and they want to avoid repeating it with additional env vars. Having almost contributed to Curl before, they repeatedly note for contributors that just because old code does something questionable doesn't mean your new code is allowed to do it—if anything, you're just highlighting the questionable piece of old code as being important for them to rewrite soon (of course they can't remove the current env vars for compatibility reasons).

And the article specifically notes that the current solution doesn't work, but it requires discussion on what the best solution is instead of just taking the literal first solution suggested by someone.