<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On December 28, 2015 at 3:43:02 AM, Hynek Schlawack (<a href="mailto:hs@ox.cx">hs@ox.cx</a>) wrote:</div> <div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div></div><div>Hi,<span class="Apple-converted-space"> </span><br><br>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.<span class="Apple-converted-space"> </span><br><br>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()`.<span class="Apple-converted-space"> </span><br><br># Questions<span class="Apple-converted-space"> </span><br><br>- Am I misunderstanding something completely and this can’t happen for practical reasons?<span class="Apple-converted-space"> </span><br>- Does cryptography have everything in place to achieve this at all?<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p>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</p><div><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>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).<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p>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.</p><p><br></p><p>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 :(</p><p><br></p><p>-Paul Kehrer (reaperhulk)</p></div></div></body></html>