You can deprecate the crypt module, update the docs to explain it's outdated and point to other 3rd party solutions. A few years from now we may be able to delete it. (With an intermediate step of issuing a non-silent deprecation warning.) Until then just leave it be. Possibly that's what your desired outcome is anyway?
On Sat, Feb 3, 2018 at 4:07 AM, Christian Heimes <christ...@python.org> wrote: > On 2018-02-02 17:18, Guido van Rossum wrote: > > 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 > > unchanged? > > > > 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, right? > > > > 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 > > project too.) > > I answered some of your questions in other replies and will answer the > remaining concerns on Monday. > > You suggested a 3rd party module. I have cloned the crypt module with > Serhiy's improvements and turned it into a standalone module with a > ctypes interface, https://github.com/tiran/legacycrypt . I'll release > the package as soon as I find time to polish the documentation and give > Serhiy his will deserved credit for his work. > > Christian > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
