shadow-utils has changed how they gather entropy and it looks like they have made some mistakes which make entropy generation rather slow (Arne's system took more than 10 minutes to generate a salt). Since more modern alghorithms are available and libxcrypt is building great functions to easily use them in third-party software, we should look at migrating our salted passwords from SHA512 to yescrypt (https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Yescrypt-PW-Hashing). Arne has reverted the latest release because of this problem: https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=14aa983025562b72ee62a1c7515b25c680658516
So I have rebuilt shadow using 4.11.1 as there have been a couple of updates since I submitted the original 4.9 version. I added --with-yescrypt to ./configure and changed the hash type in logs.def to yescrypt. I didn't add --without-sha512 in ./configure as I wasn't sure if shadow needed this to be able to read the hashes as well as create them. Anyway I then installed the built iso onto a vm on my testbed and the root password was accepted with no problems and no slowness . After full installation I checked the /etc/shadow file and the password hash starts with $y for yescrypt instead of the existing $6 for sha512 so it is working okay. I will submit the patch for it next.
Patch submitted to dev mailing list and patchwork. https://patchwork.ipfire.org/project/ipfire/patch/20220118091455.1453-1-adolf.belka@ipfire.org/
(In reply to Adolf Belka from comment #1) > So I have rebuilt shadow using 4.11.1 as there have been a couple of updates > since I submitted the original 4.9 version. I added --with-yescrypt to > ./configure and changed the hash type in logs.def to yescrypt. Perfect. > I didn't add --without-sha512 in ./configure as I wasn't sure if shadow > needed this to be able to read the hashes as well as create them. We will still need support for the old hash because existing systems have it stored in that format. And generally I do not think it is worth switching this off. > Anyway I then installed the built iso onto a vm on my testbed and the root > password was accepted with no problems and no slowness Yay. > After full installation I checked the /etc/shadow file and the password hash > starts with $y for yescrypt instead of the existing $6 for sha512 so it is > working okay. > > I will submit the patch for it next. Cool. I sent a question on the list because I didn't see your response on here. So please ignore that.
I ran a further test with my vm testbed. Password was changed to a different one to the one in a backup. The changed password is hashed with yescrypt and works. Carried out backup and password was changed back to what was in the backup, with the old sha512 hash. Confirmed by checking in /etc/shadow . This password also worked. Then running setup I set the password to the same as it was. Confirmed in /etc/shadow that the hash was now based on yescrypt. That password worked fine. The backup has both the root user and another user with restricted rights. So I ended up with a shadow file with root with a yescrypt hashed password and the other user with an sha512 hashed password. Both passwords work. So have confirmed that any new password created is yescrypt hashed but any existing sha512 hashed password will still be usable.
Perfect. Thank you for confirming. This is exactly what we need.
https://git.ipfire.org/?p=people/pmueller/ipfire-2.x.git;a=commit;h=5b28df47a5f94bf05cd19de1439e6cf78307b96f Not setting to MODIFIED since this is only my temporary branch for C164.
The patch has been merged into next for CU164 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5b28df47a5f94bf05cd19de1439e6cf78307b96f
Core Update 164 has been released with this fix. https://blog.ipfire.org/post/ipfire-2-27-core-update-164-released