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.

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.


Thanks,

Dominic Chen

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

Reply via email to