Proxy bypass list with "*" will still return regex quantifier parsing errors with version 0.10.11

[johlandabee]

Just created a new issue to raise attention for #1532 which is still a problem and not fixed as the merge was rejected.

Here an example:

ERROR: Exception setting "BypassList": "parsing "*.mycompany.tld" - Quantifier {x,y} following nothing."
The install of gitkraken was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\gitkraken\tools\chocolateyInstall.ps1'.
 See log for details.

The proxy is configured using http_proxy environment variables.

[ferventcoder]

@johlandabee can you provide a log showing a repro of this? It will be helpful to see where this is occurring so we can determine why it's not getting set properly.

[jburaczewski]

@ferventcoder I got the same error on version 0.10.11. What is interesting it's not happening for every app. In my case I was able to install 7zip.install or googlechrome, but installation of vscode fails every time. log.txt

[johlandabee]

@ferventcoder Here's a log (choco.log) running the following command: choco install dotnetcore --force --log-file=C:\\choco.log

[t0r0X]

@johlandabee I don't think the current behaviour is wrong, because the regular expression "*.mycompany.tld" is not correct. It should be ".*.mycompany.tld". See my comment in #1532

[ferventcoder]

@johlandabee can you verify if you make the change that @t0r0X mentioned to make it valid regex that it works appropriately?

If so we can add some documentation to show this particular example.

[johlandabee]

@ferventcoder I've just taken my answer from #1532. Maybe you can close this issue so we can continue the discussion there?

@t0r0X Actually, most implementations do use globbing and not regex to match no_proxy entries. Infact, your example does not work for such, as it will match .xxx.mycompany.tld but not xxx.mycompany.tld. Changing the entries would probably work for chocolatey, but break other apps. Furthermore, .*.mycompany.tld means, the dots match any character. To make this technically correct, you'd have to escape them (.*\.mycompany\.tld) which would - yet again - not work for other applications.

A workaroundish solution would be to add a config flag to ignore set environment variables as the system proxy (auto config script) works properly. Or maybe honor system settings - if set - over environment vars?

[boernsen-development]

From my understanding, this is still unresolved as Windows (or at least PowerShell) seems to interpret the system's bypass list as non-regex wheras Chocolatey inherits it, but misinterprets it as regex.

Reproduction:

• Use a system, which has NO internet access, EXCEPT through proxy. Chocolatey's own proxy bypass list is EMPTY.
• Global bypass list contains the entry: .internal, i.e. in PowerShell: $env:no_proxy = ".internal"
• Then this works in PowerShell (i.e. proxy is not bypassed!): [System.Net.HttpWebRequest]::Create('https://download.sysinternals.com/files/RDCMan.zip').GetResponse().StatusCode (result: OK)
• This doesn't work (i.e. the proxy is unintentionally bypassed): choco install rdcman --yes
• ERROR: ERROR: The remote file either doesn't exist, is unauthorized, or is forbidden for url 'https://download.sysinternals.com/files/RDCMan.zip'.

Current workaround for me:

• Use these parameters for all choco install/upgrade commands: --proxy=$env:http_proxy --proxy-bypass-list=$([Regex]::Escape($env:no_proxy)) Hence explicitely use the regex-escaped bypass list from the system to to stop Chocolatey from misinterpretating it.
• Alternatively set choco's bypass list explicitely with regex considered (note that in this case it has to kept in sync with system manually though!): choco config set proxyBypassList $([Regex]::Escape($env:no_proxy))

Suggested solution:

• Fix chocolatey's behavior, so that it interpretates the system's bypass list as non-regex (e.g. by regex-escaping it)
• Make logging very clear about whether the proxy is bypassed for a specific URL and why!

Quick and dirty solution:

• Make documentation very clear about it.

[corbob]

@boernsen-development thank you for providing this information. I have done some digging, and I think I see what you're seeing and why you might be seeing it. In all of my testing, I do not believe Windows PowerShell uses any of the "proxy" environment variables, and so setting $env:no_proxy will have no effect on it. Further to that, in all of my testing I have not found .internal to be a valid bypass list even through all of the Windows interfaces. If you go into the proxy settings and try to set it to .internal, clicking save neither indicates a problem, nor does it save the settings. Closing the page and coming back the proxy bypass settings will be back to what they were prior. If you put a valid proxy bypass in there and save it, within Windows PowerShell you are able to run [System.Net.WebProxy]::GetDefaultProxy() and see that it will return your proxy configurations, and the BypassList will be converted to regular expression.

Unfortunately, as noted in the documentation, the proxy bypass settings may not work when set through the system interface, so your best bet is likely to set the config option as you've noted.

I have opened issues #3401 and chocolatey/docs#954 to clarify the documentation that the Bypass list is treated as a regex.

[boernsen-development]

I have found several ways to set the Windows Proxy and I don't know the exact differences, but it seems using different methods lead to different problems, so it might be helpful to clarify that in the documentation as well (i.e. recommend to set the Choco Proxy explicitely or clarify which Windows proxy settings are inherited in which syntax and which are not). It is quiet confusing to me.

I came across these to show the different settings: Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | findstr -I proxy netsh winhttp show proxy [System.Net.WebProxy]::GetDefaultProxy()

(e.g. as discussed at https://superuser.com/questions/709096/how-can-i-change-the-system-proxy-from-the-command-line/709103)

At least for the netsh variant, I had *.internal set as a bypass entry, which finally is shown as .internal in the $env:no_proxy variable, so apparently it can be a valid setting (except *.internal was already wrong?).

[corbob]

I thought the issue reported here was still ocurring, but I am not able to reproduce the reported error on either Chocolatey CLI 1.4.0 or 2.2.2. We've also updated the documentation around proxies to be more explicit about how it works, and what order of precedence settings are considered in.

As such, I'll go ahead and close this issue. If it's still an issue and we can reproduce it, we can reopen it.