On Tue, Jun 29, 2010 at 2:25 PM, Marc-Andre Lemburg
<report@bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal@egenix.com> added the comment:
>
> Antoine Pitrou wrote:
>>
>> Antoine Pitrou <pitrou@free.fr> 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