geremy condra wrote:
> 
> geremy condra <debatem1@gmail.com> added the comment:
> 
> On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg
> <report@bugs.python.org> wrote:
>>
>> Marc-Andre Lemburg <mal@egenix.com> added the comment:
>>
>> Antoine Pitrou wrote:
>>>
>>> Antoine Pitrou <pitrou@free.fr> added the comment:
>>>
>>>> pyOpenSSL is stable, in production use and
>>>> has a decent API. The ssl module is good enough for HTTPS client
>>>> use. pyOpenSSL provides a robust server side implementation with
>>>> all the required certificate and context handling needed for this.
>>>>
>>>> We could tell people to use the ssl module for clients and
>>>> pyOpenSSL for the server side and perhaps integrate the OpenSSL
>>>> package into the ssl namespace.
>>>
>>> In this case, this should be decided early, so that I know if I should
>>> continue caring about the ssl module or not. I'm not interested in
>>> maintaining potentially obsolete code.
>>
>> I'll ask Jean-Paul and AB Strakt if they are up to contributing
>> the pyOpenSSL code to the Python stdlib based on a contributor
>> agreement. This would enable us to relicense the code under
>> the PSF license even if the original code's license is not
>> changed.
>>
>> Once that's a done deal, we can then consider moving in the above
>> direction.
> 
> I'm not sure I understand the relevance of pyopenssl here- it's pretty
> clearly focused on SSL/TLS rather than on crypto. Maybe someone can
> clarify?

Yes, but it provides a decent platform for adding other crypto APIs
as well and then we could have these as C APIs rather than wrappers
using ctypes.

There's already a patch available from Keyphrene adding all those bits:
http://www.keyphrene.com/products/pyOpenSSL-extended/index.php?lng=en

The patch would need to be updated for the new pyOpenSSL version,
but that's certainly within range. And we'd need to get their permission
to relicense as well.