geremy condra <debat...@gmail.com> added the comment: On Tue, Sep 21, 2010 at 10:33 AM, Marc-Andre Lemburg <rep...@bugs.python.org> wrote: > > Marc-Andre Lemburg <m...@egenix.com> added the comment: > > geremy condra wrote: >> >> geremy condra <debat...@gmail.com> added the comment: >> >> On Tue, Sep 21, 2010 at 4:04 AM, Marc-Andre Lemburg >> <rep...@bugs.python.org> wrote: >>> >>> Marc-Andre Lemburg <m...@egenix.com> added the comment: >>> >>> Antoine Pitrou wrote: >>>> >>>> Antoine Pitrou <pit...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue8998> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
