Gerhard Häring wrote:
On Mon, Oct 29, 2001 at 09:36:41AM +0100, M.-A. Lemburg wrote:
[Integrating more crypto code into Python]
Please don't proceed in this direction. Crypto code has a long tradition of making world-wide distribution hard and painful, either to export, to import or to usage restrictions.
True. But there's not much you can do about stupid governments, except not voting for them next time.
I think it's more difficult than that... this is about politics and can be a very touchy subject depending on at which angle you look at it.
There's a good reason why e.g. mxCrypto was developed outside the US, in fact I wrote that package because I couldn't legally export Andrew's code from the US. OpenSSL itself was developed in large parts in Australia for much the same reason.
The problem is that there needs to be some crypto support so that HTTPS, SMTP over TLS, etc. works if the crypto is available. So, at least the crypto hooks (SSL API) must be there, right?
What would be your suggestions? Would you prefer to go in the direction of my original proposal - only providing a SSL API, but not the implementation?
Note that even the hooks can cause legal problems, because some (countries) consider the hooks as guns without amunition. I'd suggest to leave serious crypto completely out of Python and to use one of the available third-party toolkits in case it should become necessary, e.g. M2Crypto has been around for a while and probably provides all that's necessary to do HTTPS or other SSL/TLS-based protocol and amkCrypto provides all the low-level tools to write your own secure procotols. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/