geremy condra <[email protected]> added the comment: On Tue, Jun 29, 2010 at 2:25 PM, Marc-Andre Lemburg <[email protected]> wrote: > > Marc-Andre Lemburg <[email protected]> added the comment: > > Antoine Pitrou wrote: >> >> Antoine Pitrou <[email protected]> added the comment: >> >>> If we are to require OpenSSL or some other crypto lib, >> >> We already depend on OpenSSL for both hashlib and ssl, this proposal >> wouldn't change anything in this regard. > > hashlib can still works without OpenSSL and hash algorithms don't > fall under crypto laws. ssl doesn't work without OpenSSL, but also > doesn't require adding any crypto code to the stdlib.
This won't change the status quo, as my code simply leverages OpenSSL rather than being an independent implementation. > The main point that needs to be addressed is shipping Python > with crypto code. If OpenSSL is optionally used, we're fine, > but if we start shipping crypto code, things are more contrived. As I say, we're doing things exactly how they're already done. Python would not be shipping any more crypto code with this module than it already does. > See http://rechten.uvt.nl/koops/cryptolaw/ for a survey. I've looked over it before and didn't notice anything glaringly applicable, outside of the Windows situation. IANAL, though. > We're hosting the Python software on servers in The Netherlands, > so have to follow the Wassenaar Arrangement if we include > crypto code. Fortunately, that agreement includes a clause which > pretty much exempts open source crypto code from export regulations. Again, this seems to me something more relevant to the OpenSSL folks than to us. > However, users of Python downloading installers with crypto software > would import and use it in their resp. countries and that may get > them into trouble, so they need to be warned if we decide to > ship crypto code with Python. Your suggestion about a warning for Windows downloads seems appropriate. I'm not sure how much more than that needs to be done, though. > They way I understand Geremy's suggestion is to just include a > wrapper for OpenSSL, so that's fine. The PEP should include a > mention of the above to argue against putting e.g. pycrypto > into the stdlib (not because it's poor software, much to the > contrary, only because it causes lots of problems for our > users and the developers). I'll add mention of the concern over export laws, but it's probably not feasible to get similar security properties out of any reimplementation that could be crafted in a reasonable time anyway. As a note, I intend to have prototype code ready at approximately the same time as the PEP, so, time permitting, you should be able to play with this before too long. Geremy Condra ---------- _______________________________________ Python tracker <[email protected]> <http://bugs.python.org/issue8998> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
