Bug 2548931

Huh. It actually seems worse than I thought, it even seems to be failing when we use 'weakpassword' as the password - see https://openqa.stg.fedoraproject.org/tests/7146020 . Will look into this more tomorrow/Monday. I think this is only affecting Rawhide for some reason, but I'll double check.

OK, so I can consistently reproduce this now. Steps:

1. Get a current F45 or Rawhide Workstation live image (e.g. https://kojipkgs.fedoraproject.org/compose/branched/Fedora-45-20261013.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-45-20261013.n.0.x86_64.iso )
2. Boot, launch the installer. Change the language to Turkish
3. Click the blue link to the right of "Klavye". This will launch the GNOME keyboard layout panel
4. Add the plain Turkish keyboard layout, remove the US keyboard layout
5. Close the keyboard layout panel, return to the installer. Wait for the keyboard layout shown next to "Klavye" to change from "us" to "tr"
6. Proceed through the installer (click "Sonraki", then "Tum diski kullan" and "Sonraki" again, then "Sonraki" again, then check the checkbox and click "Verileri sil ve kur"). When install completes, boot to the installed system
7. Proceed through g-i-s (click "Ileri") to the user screen, set user name to "test"
8. Proceed to the password screen, set password to "weakpassword"
9. Click "Ileri"

What ought to happen is you get to a desktop as test, but instead the system just gets stuck. If you reboot it you'll be at a GDM login prompt with no user account available. The journal shows the errors I pasted above.

I hacked shadow to log the password hash it doesn't like, and ran an install with the hacked shadow. Here's what it says:

Oct 13 13:03:09 fedora accounts-daemon[2337]: chpasswd: (line 1, user test) invalid password hash $y$j9T$lChB5KbMj.6n51V3DjPfn0$6WyruF4YWm9GDgKx2mik5QEHE6J4m2RVXXegiqrfjI8

Proposing as a Final blocker as it does seem pretty bad, it kinda seems like normal Turkish Workstation installs may be affected. Not sure if there's anything special about 'weakpassword' or it would happen with *any* password. I'll try a few others.

Poked at this some more but can't quite pin it down. That string *should* pass the regex check and when I isolate the regex check and run it locally, it does, even with LC_ALL=tr_TR.UTF-8 . I *suspect* what's going on is something subtle with the Turkish locale and the definition of `[a-z]` so far as regex parsing goes (Turkish is a bit unusual about letters).

Looks like this bug already existed in F44 too, we just didn't spot it at the time.

Adam,

(In reply to Adam Williamson (Fedora) from comment #4)
> That string *should*
> pass the regex check and when I isolate the regex check and run it locally,
> it does, even with LC_ALL=tr_TR.UTF-8 .

For me it doesn't.

With:
'''
static bool match_regex(const char *pattern, const char *string)
{
      regex_t regex;
      int result;
      if (regcomp(&regex, pattern, REG_EXTENDED) != 0)
              return false;
      result = regexec(&regex, string, 0, NULL, 0);
      regfree(&regex);
      return result == 0;
}

int main(void)
{
      const char *loc = setlocale(LC_ALL, "");
      printf("locale in effect : %s\n", loc ? loc : "(setlocale failed!)");

      printf("[a-z] matches i  : %d\n", match_regex("^[a-z]$", "i"));
      printf("[A-Za-z] match i : %d\n", match_regex("^[A-Za-z]$", "i"));
      printf("[A-Za-z] match I : %d\n", match_regex("^[A-Za-z]$", "I"));

      return 0;
}
'''
where `match_regex()` is a copy of https://github.com/shadow-maint/shadow/blob/e9bc595fd20558cf51aef096db262232090e8fb8/lib/chkhash.c#L18

```
$ LC_ALL=C ./check 
locale in effect : C
[a-z] matches i  : 1
[A-Za-z] match i : 1
[A-Za-z] match I : 1

$ LC_ALL=tr_TR.UTF-8 ./check 
locale in effect : tr_TR.UTF-8
[a-z] matches i  : 0
[A-Za-z] match i : 0
[A-Za-z] match I : 0
```
 --  in `tr_TR.UTF-8` locale regular letters 'i'/'I' do *not* fall into '[a-z]'/'[A-Z]' ranges.
That's because of 'ı'/'İ'.
I bet a lot of sw was bitten by this many times..

Adam, is there a way to try https://github.com/alexey-tikhonov/shadow/commit/0bc412257a05ac773586091bb8b595911a7b3348 ?

>  --  in `tr_TR.UTF-8` locale regular letters 'i'/'I' do *not* fall into '[a-z]'/'[A-Z]' ranges.
> That's because of 'ı'/'İ'.

Aha! Yes, that's more or less exactly what I was expecting, but I was confused that I couldn't reproduce it, but - not being a C coder - I did not realize I needed an explicit `setlocale` call in my test script. If I add one, it also reproduces for me:

[adamw@toolbx fedora-toolbox-44 ~]$ ./crypttest 
locale in effect : en_CA.UTF-8
Generated Salt Configuration: $y$j9T$n1FCuiytsO72//12.wem6/
Final Secure Hash (Store this in DB): $y$j9T$n1FCuiytsO72//12.wem6/$V0/t/jfXZVSfMyZBLbGphuenXNdNzhdktjkOxpfUgD4
Hash OK!
Known Hash OK!
[adamw@toolbx fedora-toolbox-44 ~]$ LC_ALL=tr_TR.UTF-8 ./crypttest 
locale in effect : tr_TR.UTF-8
Generated Salt Configuration: $y$j9T$dyL/n0Rlnjj1BaXYnWzGN.
Final Secure Hash (Store this in DB): $y$j9T$dyL/n0Rlnjj1BaXYnWzGN.$aFSIFFmmXjTbY0Khh2HHfwHMnIl4If3WxPuKvBl9Q/4
Hash not OK!
Known Hash not OK!

> I bet a lot of sw was bitten by this many times..

Yeah, it's a fairly well-known issue *if* you do localization testing :D

> Adam, is there a way to try https://github.com/alexey-tikhonov/shadow/commit/0bc412257a05ac773586091bb8b595911a7b3348 ?

Yes, I can do that. Thanks for the quick fix. Will report back soon.

Fix looks good, after a few rounds of testing. Thanks! It would be great if we could get it in official Rawhide and F45 builds/updates ASAP.

Also proposing as an FE, as that's an easier vote.

Upstream PR: https://github.com/shadow-maint/shadow/pull/1772

+3 FE in https://forge.fedoraproject.org/quality/blocker-review/issues/2226 , marking accepted. I want to get an RC built soon and it'd be good to include this fix, so I will backport the fix shortly.

FEDORA-2026-78aa6059e7 (shadow-utils-4.20.0-2.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-78aa6059e7

FEDORA-2026-78aa6059e7 has been pushed to the Fedora 45 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-78aa6059e7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-78aa6059e7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

*** Bug 2517109 has been marked as a duplicate of this bug. ***

+4 for blocker in https://forge.fedoraproject.org/quality/blocker-review/issues/2226 now, upgrading to accepted blocker.

Fix looks good here. I ran a Turkish install of RC1 and it worked fine; I checked the password hash and it has an 'i' in it. So I think we're good.

(In reply to Alexey Tikhonov from comment #11)
> Upstream PR: https://github.com/shadow-maint/shadow/pull/1772

Fixed upstream as of https://github.com/shadow-maint/shadow/commit/76b02d12ee3a42afb82c200b2da98623a06061e2

FEDORA-2026-78aa6059e7 (shadow-utils-4.20.0-2.fc45) has been pushed to the Fedora 45 stable repository.
If problem still persists, please make note of it in this bug report.