geremy condra <debat...@gmail.com> added the comment: On Tue, Sep 21, 2010 at 11:29 AM, Marc-Andre Lemburg <rep...@bugs.python.org> wrote: > > Marc-Andre Lemburg <m...@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 ---------- _______________________________________ 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