Message163630
| Author |
hynek |
| Recipients |
Jon.Oberheide, alex, christian.heimes, fijall, georg.brandl, hynek, loewis, ncoghlan, petri.lehtinen, pitrou, python-dev, serhiy.storchaka |
| Date |
2012年06月23日.15:35:09 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<73651495-417A-4F18-8A2E-F969904D0390@ox.cx> |
| In-reply-to |
<1340464138.35.0.479623648128.issue15061@psf.upfronthosting.co.za> |
| Content |
> For 3.4, I hope to see a discussion open up regarding the idea of something like a "securitytools" module that aims to provide some basic primitives for operations where Python's standard assumptions (such as flexibility and short circuiting behaviour) are a bad fit for security reasons. That would include exposing a C level full_compare option, as well as the core pbkdf2 algorithm.
Strong +1 on that one. We could even consider adding bcrypt and scrypt as C isn't really an issue for us.
Ideally we'd add a module with docs which both promote and leverage secure behavior. Basically how to realize http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html in Python. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年06月23日 15:35:10 | hynek | set | recipients:
+ hynek, loewis, georg.brandl, ncoghlan, pitrou, christian.heimes, alex, fijall, python-dev, petri.lehtinen, serhiy.storchaka, Jon.Oberheide |
| 2012年06月23日 15:35:10 | hynek | link | issue15061 messages |
| 2012年06月23日 15:35:09 | hynek | create |
|