Hynek, You’re correct, I accidentally switched the two projects in my first sentence. I agree that the plans look fine to me, although I’m not sure how much time I’ll have to contribute at all.
Thanks, Dominic > On Jan 6, 2016, at 5:10 AM, Hynek Schlawack <h...@ox.cx> wrote: > > Hello Dominic, > >> Am 05.01.2016 um 06:11 schrieb Dominic Chen <ddc...@andrew.cmu.edu>: >> >> To add on to the existing discussion, I agree with deprecating cryptography >> in favor of pyopenssl, although personally I’d prefer to see pyopenssl >> continue providing an updated low-level OpenSSL interface. > > I assume that’s a typo? We intend to add cryptography constructors to > pyOpenSSL’s x509 classes; not deprecate cryptography. > >> As a bit of background, I originally started using pyopenssl when I was >> writing a research tool to parse a bunch of cryptography-related file >> formats (e.g. PEM/DER encoded X509, PKCS12, PKCS7, etc), and dump them into >> a SQL database for easy searching and filtering. I settled on pyopenssl >> after trying a number of other Python cryptography libraries, and >> discovering that they lacked support for features like elliptic curve >> cryptography, all of PCKS7/12, etc. >> >> But after discovering that pyopenssl was somewhat deprecated in favor of >> cryptography, I ended up switching to cryptography, since it appeared to >> better maintained, and I believe I encountered some bugs. However, I was >> annoyed to find out that cryptography only provided a higher-level >> interface, and there was a lack of feature parity between the two projects. >> >> This was a couple of months ago, so I don’t remember the exact details, but >> I recall that at the time, there was limited CRL parsing support, no parsing >> of unsupported OID’s in certificates, and no support for PKCS7. >> Additionally, the checks for standards compliance were frustrating to deal >> with, because I was only interested in parsing and dumping a bunch of >> certificates, not whether they were standards compliant, or whether the >> library would pars known OID’s into objects. Additionally, I also >> encountered some more bugs as well, which I believe are now fixed. >> >> As a result, I ended up implementing my own wrapper interface around both >> libraries. > > Thank you for your perspective for that’s what I hoped for. > > Would you: > > 1. agree that our plans are neutral to your situation? > 2. support us on making cryptography’s x509 layer more useful? One of the > key problems is that nobody maintaining pyOpenSSL actually fully understands > pyOpenSSL. Using new (but existing) APIs we understand seems like a path > forward that causes least pain to everyone involved. > > ? > > Regards, > Hynek > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev@python.org > https://mail.python.org/mailman/listinfo/cryptography-dev
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
