[arekm]

Distros like Fedora, Debian and others use yescrypt by default, but there is no maintained Python library that creates such hashes through the system's crypt() (libxcrypt). Going through crypt() keeps the hashes consistent with PAM, shadow and everything else on the box. crypt_r already verifies "$y$" hashes, it just can't create them, hence this very simple PR (which I think is acceptable for a library that is mostly in maintenance mode).

It adds "METHOD_YESCRYPT". The salt and cost come from libxcrypt's "crypt_gensalt()", because yescrypt needs a specially encoded salt that mksalt()'s random characters don't give. "rounds" is libxcrypt's cost (1-11).

It's backward compatible: existing methods and hashes work exactly as before, and the default stays SHA-512, because the new method is listed after the SHA-2 ones (as Blowfish is). Without "crypt_gensalt()" the new method isn't listed in "methods" at all.

Tested with tox (py311-py315) on Fedora.

[hroncok]

Thank you. I am not sure if we want to accept this here.

The README explicitly said:

This library does not expose modern hashing methods like libxcrypt's yescrypt. The last wrapper update is from 2017. No future development is planned.

For example, anaconda uses crypt_r for yescrypt this way: https://github.com/rhinstaller/anaconda/blob/7c8f9520e5d5a40c8beec6a5b3932b3f45c0376c/pyanaconda/core/users.py#L52

That does not seem too bad, does it? I do not think that evrybody should copypasta their code, but I don't want to add new methods here either. What is your main motivation to add this?

[arekm]

Mainly to unify several local scripts that each duplicate salt generation, and getting the salt wrong is much easier for yescrypt than for the other algorithms.

I don't have strong opinions on this PR. It's just that this is the only maintained (I think) library that uses libc/libxcrypt crypt() directly, and it already verifies yescrypt hashes just fine (when the underlying crypt() supports yescrypt). Only creating them needs a hand-built salt.

[hroncok]

cc @encukou @hrnciar @frenzymadness @stratakis @befeleme @vstinner

What do you think about adding yescrypt? Generally, I do not want to add new features here, but if this was still in CPython, this would be a reasonable addition. It is after all the default on Fedora anyway.

[vstinner]

I don't think that https://github.com/fedora-python/crypt_r is the good home to add new yescrypt method.

There other other projects which more actively maintained, such as:

• https://foss.heptapod.net/python-libs/passlib
• Python stdlib: https://docs.python.org/dev/library/hashlib.html
• https://argon2-cffi.readthedocs.io/ (well, more specific to Argon2)
• https://pypi.org/project/bcrypt/

[encukou]

There other other projects which more actively maintained, such as [passlib, hashlib, argon2-cffi, bcrypt]

So, it seems no one else picked up wrapping crypt_r.
If Fedora's Anaconda would use METHOD_YESCRYPT, it makes more sense to maintain it here than in a hack there. I'm not sure how to best define the scope of the project. Maybe an honest “additions can be made when needed for Fedora”?
Or, with a major version bump, the code could probably be simplified at the cost of requiring more features from the underlying library and emitting worse, errno-based, error mesages:

• Use crypt_gensalt_rn for all methods
• Use the OS default (CRYPT_GENSALT_IMPLEMENTS_DEFAULT_PREFIX), rather than methods[0]