#26016 closed Bug (fixed)
Django 1.9 dropped compatibility with py-bcrypt (as an alternative to bcrypt)
Reported by: | Raphaël Hertzog | Owned by: | Tim Graham |
---|---|---|---|
Component: | contrib.auth | Version: | 1.9 |
Severity: | Normal | Keywords: | |
Cc: | FunkyBob | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
In Debian, our python-bcrypt package is currently based on py-bcrypt (https://pypi.python.org/pypi/py-bcrypt) and it always worked fine with Django. With version 1.9 however, the test suite now fails with errors like this:
====================================================================== ERROR: test_bcrypt (auth_tests.test_hashers.TestUtilsHashPass) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/adttmp.u2Wozt/django-tests/auth_tests/test_hashers.py", line 167, in test_bcrypt encoded = make_password('lètmein', hasher='bcrypt') File "/usr/lib/python3/dist-packages/django/contrib/auth/hashers.py", line 74, in make_password salt = hasher.salt() File "/usr/lib/python3/dist-packages/django/contrib/auth/hashers.py", line 289, in salt return bcrypt.gensalt(rounds=self.rounds) TypeError: gensalt() got an unexpected keyword argument 'rounds'
This code works with bcrypt (https://pypi.python.org/pypi/bcrypt). I believe that keeping the compatibility with py-bcrypt is as easy as replacing the named parameter with the positional parameter that was used until commit 23529fb19594ffcc6ba6d716356b828157200288
The commit does not give a good reason why this change was actually needed... so I would suggest to revert it (and on the Debian side we will still upgrade our python-bcrypt to bcrypt instead of py-bcrypt but I wanted to file this to let you know and at least to document this regression for other users).
Change History (5)
comment:1 by , 9 years ago
Cc: | added |
---|---|
Component: | Uncategorized → contrib.auth |
Triage Stage: | Unreviewed → Accepted |
Type: | Uncategorized → Bug |
comment:2 by , 9 years ago
No, no reason... I believe the original motive was "explicit is better than implicit" ... a vague hope to protect ourselves against future prototype changes.
Well, we spotted the change... but didn't it didn't protect us.
comment:3 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Curtis, any reason not to revert the change?