[Python-Dev] Future of SSL

[Guido van Rossum]

> 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.

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.

> > (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. :-( )
> 
> 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.

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/)