Bug 7674 - SSO assumes UTF-8 as the system character set
Summary: SSO assumes UTF-8 as the system character set
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Agent (show other bugs)
Version: 4.12.1
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.13.0
Assignee: William Sjöblom
URL:
Keywords: frifl_tester, prosaic
Depends on:
Blocks: 7663
  Show dependency treegraph
 
Reported: 2021-04-07 08:53 CEST by William Sjöblom
Modified: 2021-04-14 11:23 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description William Sjöblom cendio 2021-04-07 08:53:45 CEST
Currently, SSO does not respect the character encoding set by the system locale and instead assumes UTF-8. This can cause issues for external programs using our SSO system that likely expect us to follow the system character encoding.

To reproduce:
- Set system locale to latin-1
- Add a user with a password containing an "ö"
- Start a new ThinLinc session with the newly created user
- Run `tl-sso-password | cat'
This is expected to print the above set password including the "ö" (which is part of latin-1), but as of now the system character encoding is assumed to be UTF-8, and thus the utf-8 "ö" is replaced by the corresponding "ö" since our system locale is set to latin-1.
Comment 1 William Sjöblom cendio 2021-04-07 13:19:09 CEST
Clarification regarding reproduction: Due to lacking character encoding support in both OpenSSH, the bug can currently only be reproduced using webaccess to start the new ThinLinc session mentioned above.
Comment 3 William Sjöblom cendio 2021-04-13 14:12:31 CEST
As of the conversion to python 3, and the improved handling of string thereof, this issue is now resolved.
Comment 4 Frida Flodin cendio 2021-04-14 11:23:35 CEST
This works as expected now! There are two ways to see the issue.
1. To be able to log in with non-ASCII password you need a build before this was
   fixed but after Webaccess was converted to Python 3. I tested on build 1981,
   as described in the description and comment 1.
2. Instead of trying to log in with non-ASCII password you can set the sso
   password with tl-sso-update-password and then see the effect of
   tl-sso-password.

Tested that it was fixed on RHEL8, Latin-9 locale and build 2005.

When verifying this we had a discussion if this really was the desired
behavior. We came to the conclusion that it is, since the Single Sign-on
mechanism should replace manually entered passwords from the user. If the user
was to enter the password manually it should be sent system locale encoded to
the application.

Note You need to log in before you can comment on or make changes to this bug.