When running tl-setup on latin-1 system and entering a password for Web Admin containing Unicode (eg. 'åäö'), the password will not work. It works fine on UTF-8 system. I tested running tl-setup on tl-4.12.0-server on Ubuntu20.04, LANG=sv_SE.ISO-8859-1. Then trying to log in with Firefox 83.0. It does not crash but the password is incorrect.
After some investigation, I have found that at least Firefox, since three years ago, will encode the password with 'UTF-8'[1]. Since 2015 there is a new RFC 7617 on 'Basic' HTTP Authentication Scheme [2] that introduce a 'charset' auth parameter. The only allowed value is 'UTF-8' so this is a step towards standardizing a default encoding. However, there is still no default due to backwards compatibility reasons. The problem for us right now (on latin-1 system) is that we create the password as latin-1 encoded and then compare it to UTF-8-encoded password from the web client. This should be solved when we create new passwords with Python 3 and use UTF-8 encoding when creating the password hash. These two scripts need to be converted to Python 3 before this bug can be closed: * tl-gen-auth * tl-setup [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1419658 [2] https://tools.ietf.org/html/rfc7617
(In reply to Frida from comment #1) > > These two scripts need to be converted to Python 3 before this bug can be > closed: > > ✓ tl-gen-auth > * tl-setup tl-gen-auth is now converted to run with Python 3, this was done as a part of bug 7554.
Tested this now that tl-setup runs with Python 3 (Bug 7692). As we expected this works just fine now. Tested on RHEL 8 with Latin-9. | | GUI | Text | | tl-4.12.1 | ✓ | ✗ | | Build 2176 | ✓ | ✓ | Note: running the graphical tl-setup on Latin-9 and setting password to non-ASCII worked before. It was only tl-setup in text mode that had the issue. Also made sure that it works as before on UTF-8 systems. Closing since no changes needed and the issue should be very rare in reality so no need for release notes.