[issue8998] add crypto routines to stdlib

[geremy condra]

geremy condra <debatem1 at gmail.com> added the comment:

On Tue, Sep 21, 2010 at 10:33 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> geremy condra wrote:
>>
>> geremy condra <debatem1 at gmail.com> added the comment:
>>
>> On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg
>> <report at bugs.python.org> wrote:
>>>
>>> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>>>
>>> Antoine Pitrou wrote:
>>>>
>>>> Antoine Pitrou <pitrou at 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.

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.

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

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________