Since passlib leverages the crypt module specifically in order to handle old and insecure password hashes, it may make sense to forklift the code from stdlib into the project or collaborate on creating an external fork which it can consume for Python 3.13 and later.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
@tiran went ahead and vendored the standard crypt source code in https://pypi.org/project/legacycrypt/ so we might want to use that. I found it among the "replacements" list in that very PEP-594.
Would it make sense if this was an optional dependency that users should opt-in? This would be breaking change, though.
Just saw this error pop up in our tests as we upgraded to Python 3.11. A little annoying to see in our tests, would be great to get some kind of fix in. Prefer not to have to add an import in our code, but not the end of the world if we need to do so.
Passlib developer here - Coming back into this project, I've gotta say I didn't expect 'crypt' to get deprecated; that definitely surprised me!
That said, the way python3 adapted the crypt module had one big wart that caused some issues in passlib -- crypt.crypt() stopped accepting bytes, which meant passlib couldn't provide passwords that used a custom encoding. Whichever alternate bridge gets settled on, it would be great to be able to provide bytes again, that would actually simplify some of the internals.
Another alternative is adding an FFI bridge within passlib. I'm slightly hesistant to do that because passlib has historically avoiding having anything to do with C-level directly (since the maintenance & testing burden for that is much higher) -- but it does reduce the surface area of how many moving parts are involved.
Regardless of that, this would definitely be a new feature that would go in a major release. I'm marking it currently for 1.8; but may let that slip if things aren't ready yet. Passlib should already be tolerant of 'crypt' not being available (e.g. when run on windows systems); though having degraded support under posix + py313 is far from ideal.
I'd like to help out. From skimming the code, it looks like safe_crypt almost always (except for bcrypt) falls back to a builtin for non-UTF8 bytes. Would a merge request that just always does that be a good first step?