Skip to content

Conversation

henderkes
Copy link

Motivation here is that "libargon2" has seen very little maintenance over the years, as it was mostly a reference implementation for the password hashing contest, while OpenSSL is actively developed.

OpenSSL 3.2 is widely supported and means that "libargon2" support could be dropped in the long term. Note that if the value was not explicitly enabled, it will silently disable in case openssl >= 3.2 cannot be found. In case it was explicitly passed with --with-openssl-argon2, it will fail like it did before.

One thing I'm not sure about is what will happen when --with-password-argon2 and --with-openssl-argon2 are passed. I suspect the "libargon2" implementation will be used, but I'm not sure if it's sensible to change that.

Since this does not affect userland, I haven't created an RFC. I'm generally open to votes on whether this should or shouldn't be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant