
First I'd like to say hello. I'm new to this list :-) I've some concerns with the latest development wrt SSL development in Python. The SSL support in the Python core seems to have been added with Python 2.0, and Guido told me in a SF patch discussion, that Pythonlabs doesn't know the code very well. Meanwhile it seems like Jeremy has tried fixing bugs. I've also submitted several patches to the SSL code. As you might know, there are several third-party SSL implementatations for Python (m2crypto, pyOpenSSL, POW). I've contacted the maintainers of these packages and asked them if they'd like to review my patches. The two that answered told me that the reason they implemented their own packages was that the SSL support in Python itself was very incomplete and, to sum it up, Python's SSL is just plain broken. The current state is that there is a single ssl() method in the socket module that can be used to instantiate client-side SSL connections. There's also a patch on Sourceforge that adds server-side SSL functionality. Several points why the current API is broken: - no support for specifying the SSL protocol (SSL v2/SSL v3/SSL v2|3) - no proper certicate checking - SSL objects are neither compatible with sockets nor are they file-like objects - no advanced features like SSL callbacks (to allow the user to accept a cerficicate, for example) What I'd suggest for Python 2.2 is to *not* add any new features, like server-side SSL but only accept bugfixes for the current client-side code. As the current implementation is broken and there is probably little SSL knowledge in the Python core team, I propose to "outsource" the problem: It should be possible to define a "Python SSL interface" that describes an API for SSL. The various modules in Python that use SSL (urllib, smtp, ...) would then be rewritten to use the new API. The socketmodule.c would be rewritten to use the new API instead. Then, wrappers could be written for the various SSL modules that wrap them into the new "Python SSL interface" API. As for me, I'm not an expert in SSL, but I'd be willing to try coordinate the efforts, write a PEP, talk with the module maintainers and such. I'd be grateful to hear your opinions about this newbie proposal :-) Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Sounds good to me.
As the current implementation is broken and there is probably little SSL knowledge in the Python core team, I propose to "outsource" the problem:
Thanks! We can sure use some help here.
I've just started digging in the socketmodule.c for a different reason, and I propose to move all the SSL stuff to a separate file and module.
Then, wrappers could be written for the various SSL modules that wrap them into the new "Python SSL interface" API.
This is a good idea. The DB API works like this.
But we do need *an* expert, don't we? Maybe you can develop expertise as you go?
I'd be grateful to hear your opinions about this newbie proposal :-)
You don't sound much like a newbie. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum [guido@python.org] wrote:
I think that if OpenSSL is available, Python should build "out of the box" with SSL support. This is becomming more and more important with projects I'm working on, especially with SOAP and XML-RPC. This doesn't mean someone shouldn't be able to replace it, and we should always define an API, but... I think we need to work out of the box.
I don't have time to provide code right now, but I do know SSL and X.509 specifically inside and out and would be happy to provide support from a standards/crypto/certificate perspective. Chris -- | Christopher Petrilli | petrilli@amber.org

Good point. That's how the SSL support is configured now, and that's how it should continue to work. (Note that, alas, the DB-API never made it this far -- we still haven't been able to find the time to do the tedious work of moving the various database adapters in the core distribution. :-( ) --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum [guido@python.org] wrote:
Perhaps there is one of the existing modules (M2Crypto?) that can be integrated, assuming licensing issues can be resolved. Also, I think that perhaps high level abstractions should be introduced, though I'm not sure what they are now... that's just hand waving. The initial goal in my mind would be to have transparent (or nearly so) SSL session management, but the X.509 manipulation and general crypto interface could wait until later. While they are both useful, the SSL side is the really critical part.
Actually what this looks more like is not just SSL, but a "crypto" collection for Python, dependent on the excellent work in OpenSSL. I can start outlining some stuff if that would be a good start, though obviously if there's an existing library that could be integrated, that would be excellent. Chris -- | Christopher Petrilli | petrilli@amber.org

Christopher Petrilli wrote:
AMK has such a package: http://www.amk.ca/python/code/crypto.html which served as an exellent introduction to the world of crypto for me. -Michel

On Sat, Oct 27, 2001 at 07:02:42PM -0700, Michel Pelletier wrote:
It doesn't offer SSL, however. I've compiled a list of SSL libraries for Python: http://www.cs.fhm.edu/~ifw00065/pyssl/ The "Python OpenSSL wrappers" are BSD licensed and could probably serve as a good basis for a SSL library in Python itself. It's an early release, that I can crash easily if I want to ;-) Also, it would have to be modified to fit Python's coding standards (basically, the docstrings are all written in DocBook; these would have to be translated to normal text). But it's a working solution to start from. The other BSD licensed one is M2Crypto, which is around much longer, but requires SWIG to build. I think SSL support is not reason enough to require SWIG for Python builds. So this one is possibly out. The third one is LGPL licensed, so it's out immediately. Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Do you know the author?
It's definitely out to require SWIG to build Python from a distribution, but we may require SWIG to hack on this particular module; we could ship the SWIG output. Not ideal, but if otherwise this module is the best candidate, maybe we could live with this.
The third one is LGPL licensed, so it's out immediately.
Really? I believe the LGPL is not "viral" as the GPL. Also, there may be the possibility to shame the author into changing the license. Can you review it a bit more technically? --Guido van Rossum (home page: http://www.python.org/~guido/)

[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. 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. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

On Mon, Oct 29, 2001 at 09:36:41AM +0100, M.-A. Lemburg wrote:
True. But there's not much you can do about stupid governments, except not voting for them next time.
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? Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

True. But there's not much you can do about stupid governments, except not voting for them next time.
Doesn't seem to help in the US. :-(
Yes, that's how the current SSL support works -- you need to link in openssl. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Mon, Oct 29, 2001 at 08:06:28AM -0500, Guido van Rossum wrote:
So, as long as there are no actual cryptographic algorithms in the Python source tree, but only hooks for OpenSSL, there's no problem? If this is the case, then there would only be an issue for binary distributions of Python, which can be built easily in free countries :-) Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

That's what I believe the situation currently, for open source software. It wasn't always like this -- at some point, hooks were enough to need export permission. It may again be like this, if some uninformed US senators get their way...
If this is the case, then there would only be an issue for binary distributions of Python, which can be built easily in free countries :-)
Hm, but that's dangerous too -- someone could easily build an RPM that includes openssl without realizing it. --Guido van Rossum (home page: http://www.python.org/~guido/)

I wrote some proprietary code for a client, using (hacked) M2Crypto and openSSL, but using only fairly lightweight DES (not even DES3). In order to get an export license, I had to talk to the Commerce Dept and the NSA. That got the export license, but to get it into France, the client had to talk extensively to the French government. My guess is that anything beyond enabling https in core Python will make negotiating with the FSF look like a Mardi Gras party. - Gordon

"GH" == haering python <Gerhard> writes:
GH> On Mon, Oct 29, 2001 at 08:06:28AM -0500, Guido van Rossum GH> wrote:
GH> So, as long as there are no actual cryptographic algorithms in GH> the Python source tree, but only hooks for OpenSSL, there's no GH> problem? I don't think the export control regs work that way. Crypto-with-a-hole (that is, an API without the actual crypto implementation) is still considered crypto as far as I know. The regulations are pretty simple these days for Open Source projects. Just send a note to the BXA (Commerce Dept.) with the URL to the source. I wonder if it's wise to do this for Python, since it has an SSL interface (albeit a clunky one). Jeremy

On Tue, Oct 30, 2001 at 03:07:07PM -0500, Jeremy Hylton wrote:
Looks like it would (formally) be required, looking thru this text: http://www.bxa.doc.gov/Encryption/EncryptionRuleOct2K.html I better stop reading crypo law texts now >:-< Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

"JH" == Jeremy Hylton <jeremy@zope.com> writes:
JH> I don't think the export control regs work that way. JH> Crypto-with-a-hole (that is, an API without the actual crypto JH> implementation) is still considered crypto as far as I know. JH> The regulations are pretty simple these days for Open Source JH> projects. Just send a note to the BXA (Commerce Dept.) with JH> the URL to the source. JH> I wonder if it's wise to do this for Python, since it has an JH> SSL interface (albeit a clunky one). Another task for the PSF, eh? -Barry

Gerhard Häring wrote:
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.
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/

Which is of course exactly the goal of the existing socket.ssl support, primitive though it is. This was paid for in part by HP; their goal was to let urllib support the HTTPS protocol, nothing more, nothing less. And it does that well enough.
I think it would be a big mistake to start from scratch. Remember the GUI SIG? PS. One issue with adding more crypto to Python could be US export issues. It's possible that new export limitations for crypto software are made law by a congress that doesn't understand the issues, and then the US Python distribution could be in trouble (even though our site in the the Netherlands, we build the distributions here in the US). Back at CNRI, we couldn't release the SSL wrappers, which don't contain any crypto code but enable linking with it, before an extensive and expensive legal review, and then we had to wait until after a certain date, at which some of the crypto export restrictions were lifted. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Sun, Oct 28, 2001 at 07:20:30AM -0500, Guido van Rossum wrote:
Sorry for this fairly late response, but I've been slacking the python-dev mailbox for half a month (I just finished reading just over 600 mails, and boy, are my arms tired.) If we are really worried about having the SSL configure checks, let alone SSL hooks, we could minimize even that by providing a 'crypto' package that _replaces_ socket.py with one with SSL support. socket.py is a small dinky thing, after all, that imports most stuff from _socketmodule.so. The actual code would live in a separate module, and the entire thing could easily be made a separate patch -- so that if the US government goes medieval on us, we can easily seperate the SSL part from the main tarball and place it on www.python.org by itself. A burden, but less so than having five developers in prison ;-) On the other hand, I would much prefer an 'ssl' module with an interface similar to the socket module, and to hell with backward compatibility :) And I'm also curious what effect the recent court ruling regarding the DeCSS distribution will have; from what I read, it states that source code is a form of expression and thus falls under the first amendment of the American constitution. It goes on to say that """Indeed, the [US] Supreme Court has never upheld a prior restraint [on pure speech], even faced with the competing interest of national security or the Sixth Amendment right to a fair trial.'""" If I were even remotely religious, I would pray (and beg humbly on my knees) to god that this decision stands in higher courts and is respected by other judges in (to us) similar cases, and recognized by whatever law-designing forces the US government has. Sleepless-ramblings-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On Sat, Oct 27, 2001 at 09:43:58PM -0400, Christopher Petrilli wrote:
Ok. I understand completely "outsourcing" SSL is not an option. So we either build a completely new SSL module or try to integrate an existing one.
Perhaps there is one of the existing modules (M2Crypto?) that can be integrated, assuming licensing issues can be resolved.
Yup. To save you time finding them all, I've summarized them and put up a page about them (cf. my other post).
[...] The initial goal in my mind would be to have transparent (or nearly so) SSL session management, [...]
I'm not sure I understand what you mean by transparent session management. Perhaps that one important feature would be that SSL objects be interface compatible with socket objects as much as possible? So ugly hacks like FakeSocket in httplib and SSLFakeSocket in smtplib are no longer necessary. And, btw. one complaint about socketmodule.c I've heard is that it doesn't have a C API, it might be necessary to expose some of it with the help of a header file. Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

What would you need from a C API? Socket objects currently are pretty thin wrappers around file descriptors. I'm not against this (although defining and using an external C API for a Python extension module is a bit cumbersome due to the requirement for dynamic loading), but I'd like to see the requirements first. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Do you really think that this would be the right approach ? Sounds like code bloat to me... BTW, I'm still waiting for one of the PSF sponsors to create the mythical Sumo distribution of Python. Any news in that direction ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

It depends. This is definitely a frequently requested feature, and that's what I go by... Plus, I know that the various DB packages (mxODBC notwithstanding :-) are of, eh, varying quality.
I don't recall either of the sponsors promising, although I would say that ActivePython might be a good start. I remember one of the regular members promising this, but apparently his fork was larger than his mouth (as we say in Holland). --Guido van Rossum (home page: http://www.python.org/~guido/)

Sounds good to me.
As the current implementation is broken and there is probably little SSL knowledge in the Python core team, I propose to "outsource" the problem:
Thanks! We can sure use some help here.
I've just started digging in the socketmodule.c for a different reason, and I propose to move all the SSL stuff to a separate file and module.
Then, wrappers could be written for the various SSL modules that wrap them into the new "Python SSL interface" API.
This is a good idea. The DB API works like this.
But we do need *an* expert, don't we? Maybe you can develop expertise as you go?
I'd be grateful to hear your opinions about this newbie proposal :-)
You don't sound much like a newbie. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum [guido@python.org] wrote:
I think that if OpenSSL is available, Python should build "out of the box" with SSL support. This is becomming more and more important with projects I'm working on, especially with SOAP and XML-RPC. This doesn't mean someone shouldn't be able to replace it, and we should always define an API, but... I think we need to work out of the box.
I don't have time to provide code right now, but I do know SSL and X.509 specifically inside and out and would be happy to provide support from a standards/crypto/certificate perspective. Chris -- | Christopher Petrilli | petrilli@amber.org

Good point. That's how the SSL support is configured now, and that's how it should continue to work. (Note that, alas, the DB-API never made it this far -- we still haven't been able to find the time to do the tedious work of moving the various database adapters in the core distribution. :-( ) --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum [guido@python.org] wrote:
Perhaps there is one of the existing modules (M2Crypto?) that can be integrated, assuming licensing issues can be resolved. Also, I think that perhaps high level abstractions should be introduced, though I'm not sure what they are now... that's just hand waving. The initial goal in my mind would be to have transparent (or nearly so) SSL session management, but the X.509 manipulation and general crypto interface could wait until later. While they are both useful, the SSL side is the really critical part.
Actually what this looks more like is not just SSL, but a "crypto" collection for Python, dependent on the excellent work in OpenSSL. I can start outlining some stuff if that would be a good start, though obviously if there's an existing library that could be integrated, that would be excellent. Chris -- | Christopher Petrilli | petrilli@amber.org

Christopher Petrilli wrote:
AMK has such a package: http://www.amk.ca/python/code/crypto.html which served as an exellent introduction to the world of crypto for me. -Michel

On Sat, Oct 27, 2001 at 07:02:42PM -0700, Michel Pelletier wrote:
It doesn't offer SSL, however. I've compiled a list of SSL libraries for Python: http://www.cs.fhm.edu/~ifw00065/pyssl/ The "Python OpenSSL wrappers" are BSD licensed and could probably serve as a good basis for a SSL library in Python itself. It's an early release, that I can crash easily if I want to ;-) Also, it would have to be modified to fit Python's coding standards (basically, the docstrings are all written in DocBook; these would have to be translated to normal text). But it's a working solution to start from. The other BSD licensed one is M2Crypto, which is around much longer, but requires SWIG to build. I think SSL support is not reason enough to require SWIG for Python builds. So this one is possibly out. The third one is LGPL licensed, so it's out immediately. Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Do you know the author?
It's definitely out to require SWIG to build Python from a distribution, but we may require SWIG to hack on this particular module; we could ship the SWIG output. Not ideal, but if otherwise this module is the best candidate, maybe we could live with this.
The third one is LGPL licensed, so it's out immediately.
Really? I believe the LGPL is not "viral" as the GPL. Also, there may be the possibility to shame the author into changing the license. Can you review it a bit more technically? --Guido van Rossum (home page: http://www.python.org/~guido/)

[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. 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. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

On Mon, Oct 29, 2001 at 09:36:41AM +0100, M.-A. Lemburg wrote:
True. But there's not much you can do about stupid governments, except not voting for them next time.
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? Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

True. But there's not much you can do about stupid governments, except not voting for them next time.
Doesn't seem to help in the US. :-(
Yes, that's how the current SSL support works -- you need to link in openssl. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Mon, Oct 29, 2001 at 08:06:28AM -0500, Guido van Rossum wrote:
So, as long as there are no actual cryptographic algorithms in the Python source tree, but only hooks for OpenSSL, there's no problem? If this is the case, then there would only be an issue for binary distributions of Python, which can be built easily in free countries :-) Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

That's what I believe the situation currently, for open source software. It wasn't always like this -- at some point, hooks were enough to need export permission. It may again be like this, if some uninformed US senators get their way...
If this is the case, then there would only be an issue for binary distributions of Python, which can be built easily in free countries :-)
Hm, but that's dangerous too -- someone could easily build an RPM that includes openssl without realizing it. --Guido van Rossum (home page: http://www.python.org/~guido/)

I wrote some proprietary code for a client, using (hacked) M2Crypto and openSSL, but using only fairly lightweight DES (not even DES3). In order to get an export license, I had to talk to the Commerce Dept and the NSA. That got the export license, but to get it into France, the client had to talk extensively to the French government. My guess is that anything beyond enabling https in core Python will make negotiating with the FSF look like a Mardi Gras party. - Gordon

"GH" == haering python <Gerhard> writes:
GH> On Mon, Oct 29, 2001 at 08:06:28AM -0500, Guido van Rossum GH> wrote:
GH> So, as long as there are no actual cryptographic algorithms in GH> the Python source tree, but only hooks for OpenSSL, there's no GH> problem? I don't think the export control regs work that way. Crypto-with-a-hole (that is, an API without the actual crypto implementation) is still considered crypto as far as I know. The regulations are pretty simple these days for Open Source projects. Just send a note to the BXA (Commerce Dept.) with the URL to the source. I wonder if it's wise to do this for Python, since it has an SSL interface (albeit a clunky one). Jeremy

On Tue, Oct 30, 2001 at 03:07:07PM -0500, Jeremy Hylton wrote:
Looks like it would (formally) be required, looking thru this text: http://www.bxa.doc.gov/Encryption/EncryptionRuleOct2K.html I better stop reading crypo law texts now >:-< Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

"JH" == Jeremy Hylton <jeremy@zope.com> writes:
JH> I don't think the export control regs work that way. JH> Crypto-with-a-hole (that is, an API without the actual crypto JH> implementation) is still considered crypto as far as I know. JH> The regulations are pretty simple these days for Open Source JH> projects. Just send a note to the BXA (Commerce Dept.) with JH> the URL to the source. JH> I wonder if it's wise to do this for Python, since it has an JH> SSL interface (albeit a clunky one). Another task for the PSF, eh? -Barry

Gerhard Häring wrote:
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.
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/

Which is of course exactly the goal of the existing socket.ssl support, primitive though it is. This was paid for in part by HP; their goal was to let urllib support the HTTPS protocol, nothing more, nothing less. And it does that well enough.
I think it would be a big mistake to start from scratch. Remember the GUI SIG? PS. One issue with adding more crypto to Python could be US export issues. It's possible that new export limitations for crypto software are made law by a congress that doesn't understand the issues, and then the US Python distribution could be in trouble (even though our site in the the Netherlands, we build the distributions here in the US). Back at CNRI, we couldn't release the SSL wrappers, which don't contain any crypto code but enable linking with it, before an extensive and expensive legal review, and then we had to wait until after a certain date, at which some of the crypto export restrictions were lifted. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Sun, Oct 28, 2001 at 07:20:30AM -0500, Guido van Rossum wrote:
Sorry for this fairly late response, but I've been slacking the python-dev mailbox for half a month (I just finished reading just over 600 mails, and boy, are my arms tired.) If we are really worried about having the SSL configure checks, let alone SSL hooks, we could minimize even that by providing a 'crypto' package that _replaces_ socket.py with one with SSL support. socket.py is a small dinky thing, after all, that imports most stuff from _socketmodule.so. The actual code would live in a separate module, and the entire thing could easily be made a separate patch -- so that if the US government goes medieval on us, we can easily seperate the SSL part from the main tarball and place it on www.python.org by itself. A burden, but less so than having five developers in prison ;-) On the other hand, I would much prefer an 'ssl' module with an interface similar to the socket module, and to hell with backward compatibility :) And I'm also curious what effect the recent court ruling regarding the DeCSS distribution will have; from what I read, it states that source code is a form of expression and thus falls under the first amendment of the American constitution. It goes on to say that """Indeed, the [US] Supreme Court has never upheld a prior restraint [on pure speech], even faced with the competing interest of national security or the Sixth Amendment right to a fair trial.'""" If I were even remotely religious, I would pray (and beg humbly on my knees) to god that this decision stands in higher courts and is respected by other judges in (to us) similar cases, and recognized by whatever law-designing forces the US government has. Sleepless-ramblings-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On Sat, Oct 27, 2001 at 09:43:58PM -0400, Christopher Petrilli wrote:
Ok. I understand completely "outsourcing" SSL is not an option. So we either build a completely new SSL module or try to integrate an existing one.
Perhaps there is one of the existing modules (M2Crypto?) that can be integrated, assuming licensing issues can be resolved.
Yup. To save you time finding them all, I've summarized them and put up a page about them (cf. my other post).
[...] The initial goal in my mind would be to have transparent (or nearly so) SSL session management, [...]
I'm not sure I understand what you mean by transparent session management. Perhaps that one important feature would be that SSL objects be interface compatible with socket objects as much as possible? So ugly hacks like FakeSocket in httplib and SSLFakeSocket in smtplib are no longer necessary. And, btw. one complaint about socketmodule.c I've heard is that it doesn't have a C API, it might be necessary to expose some of it with the help of a header file. Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

What would you need from a C API? Socket objects currently are pretty thin wrappers around file descriptors. I'm not against this (although defining and using an external C API for a Python extension module is a bit cumbersome due to the requirement for dynamic loading), but I'd like to see the requirements first. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Do you really think that this would be the right approach ? Sounds like code bloat to me... BTW, I'm still waiting for one of the PSF sponsors to create the mythical Sumo distribution of Python. Any news in that direction ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

It depends. This is definitely a frequently requested feature, and that's what I go by... Plus, I know that the various DB packages (mxODBC notwithstanding :-) are of, eh, varying quality.
I don't recall either of the sponsors promising, although I would say that ActivePython might be a good start. I remember one of the regular members promising this, but apparently his fork was larger than his mouth (as we say in Holland). --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (9)
-
barry@zope.com
-
Christopher Petrilli
-
Gerhard Häring
-
Gordon McMillan
-
Guido van Rossum
-
Jeremy Hylton
-
M.-A. Lemburg
-
Michel Pelletier
-
Thomas Wouters