On Fri, Jun 18, 2010 at 4:53 AM, Antoine Pitrou <report@bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
>> Well, like I say, I'm willing to contribute what time and ability
>> allow. Are you thinking of adding a comprehensive wrapper to the ssl
>> module?
>
> Hmm, no, I was just providing an existing datapoint to help us deciding
> on a crypto API.  AFAICT this issue hasn't much to do with the ssl
> module, except perhaps for (positive or negative) inspiration ;-)
> (and except that it will also - most likely - interface with OpenSSL)

The question in my mind then is whether anybody willing to contribute
time knows enough about the CryptoAPI, or NSS, or what-have-you, to
help craft an API that makes the waterfall model look manageable. If
not, I would suggest that we focus on defining and building a
lower-level interface along the lines of the PEP noted earlier,
integrating that with evpy, and getting it in shape to go into the
stdlib. At that point, if demand arises for an even lower level API,
we already have the wrapping functions for a lot of the calls into
OpenSSL or whatever, and we can build on those in the aforementioned
evolutionary fashion. If somebody does, then perhaps a four-tiered
model makes more sense, with the bottom one being the raw wrappers
around the various libs, the second from the bottom being
compatibility shims, and the top two matching the other proposal.
Having said that, it's not something I could take on alone.

Geremy Condra