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