Martin v. L=F6wis wrote:
> "A.M. Kuchling" <amk@amk.ca> writes:
>=20
>=20
>>Do we want to do anything about this for 2.3? A benefit is that AES
>>is useful, and likely to remain so for the next 20 years; a drawback
>>is that it might entangle the PSF in export-control legalities. I
>>vaguely recall the PSF getting some legal advice on this point; am I
>>misremembering? What was the outcome?
>=20
> I think we now formally meet all US export requirements. The
> requirement is that we inform some agency that we do export
> cryptographic software. Jeremy did that. I don't recall the exact
> details of that registration, but I think it would be easy to update
> it to also report that we export an AES implementation (or, perhaps,
> our registration was generic to cover all future additions to the SF
> CVS tree).
>=20
> So I'm all in favour of adding AES to the Python standard library.
-1.
Why do you only look at US export rules when discussing crypto
code in Python ? There are plenty of other countries where
importing/exporting and/or using such code is illegal:
http://rechten.kub.nl/koops/cryptolaw/cls2.htm
Please keep the crypto code separate from the core Python
distribution.
--=20
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Apr 24 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
EuroPython 2003, Charleroi, Belgium: 61 days left
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4