[responding to myself because MailRoute had hiccups when Paul sent his response and I never got it.]
I’m glad I’ve met unequivocal support so far. [Paul]: > There's no reason why we can't do this technically. My past opposition has > mostly been philosophical (if we do this we inextricably tie pyOpenSSL to > cryptography), but perhaps I should just embrace it. We have everything we > need to do it right now (x509 objects, RSA/EC/DSA objects), although it does > require consuming some private classes/methods. Here's some untested code to > show how we could do it: > https://github.com/reaperhulk/pyopenssl/commit/65d0658af74c892ca261d051ed50e37519eaff98 To be honest I wasn’t aware you had any opposition. :) I think it’s fair to assume that cryptography is here to stay and I don’t intend to break/remove the “old ways”. Knowing that it’s technically possible is *great news*. > Personally, I don't have a problem with features landing in pyOpenSSL. Yes, > they're frequently duplicating features in cryptography, but until > cryptography is actually a full replacement I don't feel comfortable telling > people to use both APIs. Once pyOpenSSL's use case vanishes outside of > "legacy compatibility shim" then I would support being more aggressive about > rejecting new features. Of course, reviewing/landing feature PRs is hard work > and I don't have a good answer for how to deal with that. Person-hours are a > precious commodity :( Yes. And I figure that this step would simplify a lot of things. It would also reduce the PR ping pong between the two projects. The nice thing is that we can add that support for each class separately. *** [glyph]: > In the meanwhile though, I think that from_cryptography/to_cryptography are a > good idea, and should contain a clear explanation of this plan: in other > words, everyone using pyOpenSSL should start rewriting their applications to > use the 'cryptography' objects as much as possible. That’s exactly my point. It not only reduces work-load and adds features: it also starts the transition. > Right now, things are in a bit of a muddled state; pyOpenSSL is still the > only package available to do many things (in particular: TLS) but pull > requests are being refused on the grounds that Cryptography has superseded > it, when there still isn't a clear interop strategy. These methods > (especially if properly documented) could really improve this situation. AFAIK, there hasn’t been a PR refused for this reason so far but there have always been awkward nudges in that direction. *** As for planning: I think the best way forward is to release 16.0.0 AFAIK and then start the work on this. I will point the owners of x509-related tickets/PRs to this thread before we really start. Opinions? —h
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
