This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author debatem1
Recipients daniel.urban, debatem1, dmalcolm, eric.araujo, exarkun, georg.brandl, giampaolo.rodola, gregory.p.smith, heikki, jsamuel, lemburg, loewis, lorph, mcrute, pitrou, vstinner
Date 2010-09-21.18:01:06
SpamBayes Score 5.551115e-17
Marked as misclassified No
Message-id <AANLkTikgWSm6iN6NoLk01J_jiFeOsV=EFh_yvcyOkLO+@mail.gmail.com>
In-reply-to <4C98EC73.4050207@egenix.com>
Content
On Tue, Sep 21, 2010 at 10:33 AM, Marc-Andre Lemburg
<report@bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal@egenix.com> added the comment:
>
> 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.

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
History
Date User Action Args
2010-09-21 18:01:08debatem1setrecipients: + debatem1, lemburg, loewis, georg.brandl, gregory.p.smith, exarkun, pitrou, vstinner, giampaolo.rodola, lorph, heikki, eric.araujo, dmalcolm, daniel.urban, mcrute, jsamuel
2010-09-21 18:01:06debatem1linkissue8998 messages
2010-09-21 18:01:06debatem1create