I'm all for nudging people in the direction of xcrypt. I assume we can't
just switch the C-level crypt with xcrypt and leave the Python API
However until a usable solution exist (either in the stdlib or as 3rd
party) I don't think we should deprecate anything (deprecating things
before the replacement is ready is stressful for everyone involved).
I'm also not sure I agree with removing support for old hashes. By all
means put in the docs that they are unsafe. But if someone has a database
full of old hashes it would be nice to be able to at least read/verify it,
Was a release already made with blowfish, extended DES and NT-Hash? (And
what's so bad with blowfish? It's mentioned in the heading of the xcrypt
On Fri, Feb 2, 2018 at 7:23 AM, Christian Heimes <christ...@python.org>
> in PR 3854  Serhiy added blowfish, extended DES and NT-Hash to
> Python's crypt mdodule. I vetoed against addition of the APIs because
> all these hashing algorithms are not state of the art. Their quality
> ranges from old to horribly, horriblye broken beyond any repair.
> Shortly after the PR has landed, I was made aware that glibc has
> deprecated crypt(3) API  and favor of an external library called
> libxcrypt  from OpenWall Linux. I have patched Python 3.7  to
> support libxcrypt.
> In light of deprecation of crypt(3) glibc function and bad quality of
> hashing algorithms, I'd like to raise the motion to revert 3854 and
> deprecate the crypt module. The whole module should be rather moved into
> 3rd party library that wraps xcrypt.
>  https://github.com/python/cpython/pull/3854
>  https://github.com/besser82/libxcrypt
>  https://bugs.python.org/issue32635
> Python-Dev mailing list
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
--Guido van Rossum (python.org/~guido)
Python-Dev mailing list