On Tue, Sep 21, 2010 at 11:29 AM, Marc-Andre Lemburg
<report@bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal@egenix.com> added the comment:
>
> geremy condra wrote:
>>
>>>>> 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.
>>
>> The intention all along has been that we use the C API, and in fact
>> I'm pretty far along on writing that. Assuming there won't be an issue
>> with porting pyopenssl to python3, this seems like a pretty good idea
>> to me though.
>
> Ah, sorry, I must have missed that turn in the discussion :-)
>
> The pyOpenSSL port to Python3 is closing in on completion. Jean-Paul
> is planning for an alpha release next month.

Do you know if he's looking for help with that? There's been some talk of
a porting sprint here and I'd be happy to put that at the top of the list.

>>> 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.
>>
>> Bits and pieces of this look useful but it also looks like I'd be
>> rewriting a lot of it to move away from the RSA_* routines, etc. I
>> suspect it would take more time to get it into line than to just
>> cherrypick out of it.
>
> If you are writing new code for this anyway, it may be better to
> avoid the license question of the Keyphrene patch and just use
> their code as reference.

Yeah, I think that makes the most sense.

Geremy Condra