-
Notifications
You must be signed in to change notification settings - Fork 907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chocolatey does not handle passwords with non ASCII characters when interacting with authenticating sources #3600
Comments
Python file to reproduce the server side :
C# code to trigger the problem:
|
Thank you for raising this! As this appears to be a .NET Framework issue, this can't be resolved until we move to .NET (Core). I've added it to the milestone when we expect that to happen. The recommendation would be to only use ASCII characters for the password. I appreciate that doesn't help here though. |
You can also push the workaround. As ugly as it seems, it actually works and I don't see any drawbacks so far in using it |
Checklist
What You Are Seeing?
French here, some of our users are using french characters ( éèàù§... ) in their passwords. And our nexus server serving chocolatey packages requires authentication.
Problem : those users enter their correct password but it fails to authenticate correctly.
This applies to both interactive prompt for user/password or user/password stored with source add --user --password
What is Expected?
Users having password with non ascii characters should still be able to use chocolatey with authenticating repositories
How Did You Get This To Happen?
Interactive :
Non Interactive :
System Details
Chocolatey CLI Version: 2.4.1
Chocolatey Licensed Extension version:
Installed Packages
Output Log
Additional Context
I tracked this down because I really need chocolatey to authenticate to nexus for all our users.
The password is correctly read by chocolatey, an object NetworkCredential with the correct password is passed to WebRequest .
So this is actually a .NET Framework bug, which I was able to reproduce quite simply. The bug is present in .NET Framework 4.8.1 but not in .NET 5 and above .
The problem is that .NET incorrectly encodes the authentication header in the http request. It's kind of a grey area but most servers and at least nexus expect the authentication header to contain user + password, in UTF8, base64 encoded . It looks like .NET 4.8.1 uses a different encoding, probably a reinterpretation of UTF16 but I am not clear on that part.
A simple way to reproduce the problem :
The installation will fail but the interesting part is on the python server : it shows you that it could not decode the Authentication header in UTF8
I attach also a simple CS file to reproduce the problem more simply with the same python server.
And last but not least, I have a workaround for this. Not a pretty one. Basically, .NET Framework 4.8 incorrectly interprets NetwordCredential objects with a password containing non ASCII characters. By cheating on the password value, it's possible to have .NET issue the correct authentication header .
It looks like this :
I'll submit a PR sometimes for this
The text was updated successfully, but these errors were encountered: