On December 28, 2015 at 3:43:02 AM, Hynek Schlawack (h...@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)
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
