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.