[Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL

[Paul Kehrer]

On December 28, 2015 at 3:43:02 AM, Hynek Schlawack (hs at ox.cx) wrote:
Hi, 

we have quite a bit of pull requests on pyOpenSSL that revolve around improving the state of x509 objects in general as far as I understand it. 

Since I already got reprimanded by Alex G for merging one because cryptography has routines for that, I wonder if we should close them all as WONTFIX and instead add methods akin to `PKey.from_cryptography()`, `key_instance.to_cryptography()`. 

# Questions 

- Am I misunderstanding something completely and this can’t happen for practical reasons? 
- Does cryptography have everything in place to achieve this at all? 
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


I welcome any feedback. The current pyOpenSSL situation which is mostly a swamp of guilt is becoming unbearable to me. When I took over maintainership I made it clear that I see myself mostly as a repo janitor and Bad Ideas Deflector™. Sadly that’s not working out at all. Getting rid of the burden of actually moving forward a whole sub-system might alleviate that a bit I guess (this is not meant as an ultimatum, I have no idea if it’d help). 
This is definitely a problem and I don't want you to get burned out due to guilt. Please don't hesitate to reach out (as you've done here) whenever you need/want some assistance in moving things forward.



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 :(



-Paul Kehrer (reaperhulk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20151228/a669dd4e/attachment.html>