🎁 Check lower-cased proxy settings as well - #354
Conversation
f61670e to
1a30dae
Compare
| let no_proxy: string = process.env[EnvironmentVariables.NO_PROXY]; | ||
| let no_proxy: string = process.env[EnvironmentVariables.NO_PROXY] | ||
| if (!no_proxy) { | ||
| no_proxy = process.env[EnvironmentVariables.NO_PROXY.toLowerCase()]; |
There was a problem hiding this comment.
Thank you for the contribution! Your change is reasonable given the issue described in the article you linked.
However, we also need to consider the possible impact of this change in case someone has stale lower-case proxy information defined. One possible option would be to raise a user-visible warning, but I don't think there is a pattern in this library to surface warnings. We'd like to hear your thoughts on this option or any other suggestions you might have.
There was a problem hiding this comment.
I wouldn't worry about stale env variables. A lot of tools uses lower-cased proxy settings, a majority. I don't think this is an issue.
Taking the worst case into account: Someone has a compromised machine with malicious setting in http_proxy var. If that's the case, that person is already scudded, as countless tools use lower-cased http_proxy, far more than they use HTTP_PROXY. That's why I wouldn't bother to care about it.
Also, I have never seen a tool to warn that you are using http_proxy in a wrong case. They all seem to just use whatever they support.
See the thread: https://unix.stackexchange.com/a/212972
Of course, you could hide this change behind a feature flag. But, as I said above, I think this is kinda pointless. I made this PR just for the convenience of using defaults. I spent like ~2 hours debugging why Mitmproxy isn't working with this library. Until, I jumped into the sources to find that this lib uses HTTP_PROXY. Every other tool I have, uses http_proxy. That's a default for Linux/Mac.
2 participants
This change resolves an issue that may likely arise on Linux/Mac machines. Those default to using lower-cased proxy environment variables.
I think it's a good idea to support both.
See, the article describing this madness: https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/