[Python-Dev] Design and direction of the SSL module (was Re: frozenset C API?)

[Bill Janssen]

> One, what *is* the scope of your 
> amibition?  I feel silly for asking, because I am pretty sure that 
> somewhere in the beginning of this thread I missed either a proposal, a 
> PEP reference, or a ticket number, but I've poked around a little and I 
> can't seem to find it.  Can you provide a reference, or describe what it 
> is you're trying to do?

Sorry about that.  We kind of did this on the fly at the Python
sprint.

I was trying to fix two problems:  One, that the current socket.ssl
support didn't validate certificates, and two, that you couldn't do
server-side SSL with it.  I'm only interested in that aspect, and in
the simplest possible solution to those problems.  I don't want to
provide user validation callbacks, or arbitrary certificate decoding,
or general-purpose crypto, or support for building automatic CA
systems, or wrapping most of that great grab-bag of useful stuff
called OpenSSL.  Just fix the core issues with socket.ssl.

Along the way I've found a nasty little threading/malloc bug in the
existing code, and fixed that.  I've added real documentation for the
existing functionality.  I've gone around with you and Martin, mainly,
on what information to expose from the validated certificate, to
support authorization and accounting (the answer so far: "notAfter",
"subject", and "subjectAltName", if it's there).

> I'd really like to help make the stdlib SSL module to 
> be a really good, full-featured OpenSSL implementation for Python so we 
> can have it elsewhere.

Well, remember, it's just a socket-layer wrapper for TLS, it's not an
"OpenSSL implementation", by which I suppose you mean a full wrapper
for OpenSSL, much like PyOpenSSL is supposed to be.  For that purpose,
doesn't it make more sense to to extend/fix PyOpenSSL, rather than try
to grow the deliberately limited-purpose socket.ssl support into another
version of that?  Can't it be revived, if it is in fact moribund?

>     * Would it be possible to distribute as a separate library?  (I think 
> I remember Bill saying something about that already...)

Just to be clear that what you seem to want to work on and what I'm
working on seem to be two different things...  I plan to build a
back-port of the improved socket.ssl support as a standalone package
for 2.3 (because I need to use it on OS X 10.4).

> I'd say "why wouldn't you want to require either of those packages?" but 
> actually, I know why you wouldn't want to, and it's that they're bad. 

It's that they are too big and complicated to easily see how to fix.  But
that seems to be a side-effect of trying to wrap all of OpenSSL, which is
a big, evolving project.

> Wouldn't it be nice to know *why* the cert didn't validate?  To provide 

Yes, so I've put in a bit of work making sure the OpenSSL errors are
properly relayed back to the Python application.

> The entire idea of "extensions" is pretty direct about the fact that the 
> original implementor need not understand their profitable use :).

Not really.  Each extension is proposed, debated, and approved before
it's added to the spec for extensions.  My idea is that as support for
various extensions appear in OpenSSL, we can evaluate them and see if
they are worth supporting in Python.

> Specifically, properties of the 
> issuer define what properties the subject may have, in the verification 
> scheme for Vertex ( http://divmod.org/trac/wiki/DivmodVertex )

I didn't see a write-up of your scheme at that URL; can you point me
to a particular page in the Wiki which describes the use case?

I should point out that we're (actually, Greg Smith) also wrapping
another chunk of the OpenSSL library for hashing.  And last week I
suggested that we might wrap yet another chunk for doing cryptography.
This chunk-by-chunk approach might be a good way to go.  If a chunk
that did general X509 certificate munging did appear, I'd be happy
to change the SSL support to use it.

Bill