libxcrypt: Remaining changes #195271
libxcrypt: Remaining changes #195271
Conversation
github-actions
bot
added
6.topic: nixos
8.has: documentation
8.has: module (update)
labels
mweinelt
force-pushed
the
libxcrypt-continued
branch
from
4163a1e
to
0e80ea2
Compare
mweinelt
force-pushed
the
libxcrypt-continued
branch
from
0edab11
to
9771e3b
Compare
|
|
||
| users = set() | ||
| try: | ||
| with open("/etc/shadow", "r") as fd: |
There was a problem hiding this comment.
I should probably grab getent shadow to account for other lookups. But is crypt even involved in that case? 🤔
| @@ -32,8 +32,7 @@ account will cease to exist. Also, imperative commands for managing users and | |||
| groups, such as useradd, are no longer available. Passwords may still be | |||
| assigned by setting the user\'s | |||
| [hashedPassword](#opt-users.users._name_.hashedPassword) option. A | |||
| hashed password can be generated using `mkpasswd -m | |||
| sha-512`. | |||
| hashed password can be generated using `mkpasswd -m yescrypt`. | |||
There was a problem hiding this comment.
What's the rationale for this change? sha-512 $6$ is still allowed as good_schemes.
Also note that yescrypt is the default method when calling mkpassword without -m.
There was a problem hiding this comment.
I'll reference https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow, where the author of libxcrypt explains why sha256crypt & sha512crypt are not optimal.
I'm aware it is the default, the ordering comes from the order in https://github.com/besser82/libxcrypt/blob/v4.4.28/lib/hashes.conf#L41.
I'm fine with removing the -m parameter entirely, and I'm against sticking with sha512 explicitly, because documentation gets outdated far too quickly.
| print( | ||
| """ | ||
| WARNING: The following users are relying on password hashes that will | ||
| be removed in NixOS 23.05. They should be renewed as soon as possible!""", | ||
| file=sys.stderr, | ||
| ) |
There was a problem hiding this comment.
Can we abort the switching in a next deprecation step?
There was a problem hiding this comment.
I also thought this was a good idea, but realized it's an obvious bad idea when doing nixos-rebuild boot into e.g. 23.05 -- the system would just fail to boot with that message, which... I don't know if we want that. Maybe we do? Not sure.
There was a problem hiding this comment.
We can harden the validation for hashedPassword using strMatching, but we don't have an equally good solution for mutable passwords.
|
We should also warn earlier at eval-time if users set |
mweinelt
force-pushed
the
libxcrypt-continued
branch
from
9771e3b
to
9cf0f03
Compare
|
Converting to draft while untested and with open change requests. If someone wants to work on the warning for |
mweinelt
force-pushed
the
libxcrypt-continued
branch
from
9cf0f03
to
ab00e27
Compare
The shadow test uses a password that is hashed with libxcrypt and the login test uses the passwd command.
mweinelt
force-pushed
the
libxcrypt-continued
branch
from
ab00e27
to
5f7f739
Compare
github-actions
bot
removed
6.topic: nixos
8.has: documentation
8.has: module (update)
labels
|
Reduced to the uncontroversial changes so they land in the same staging cycle as the libxcrypt migration. Moving documentation and deprecation warning changes into dedicated PR. |
Description of changes
Updates that I didn't want to push into #181764 anymore. These should be uncontroversial updates to the libxcrypt package and manual updates.
And an activation script that notifies users if they need to update their password hashes in
/etc/shadow.Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes