flake8

It doesn't look like the version of Python 2 in Ubuntu Trusty has hmac.compare_digest. Do you plan to keep (security) support for the version of Python there until the OS is EOL'd next year?

That's pretty upsetting... yeah, I guess we'll probably wait. I assume trusty is a significant portion of your users?

Yeah. It's about 10% of our users so waiting until April of next year would help us a lot.

On a related note, we're currently rethinking how we distribute Certbot. If you're interested, I'm happy to write up the approaches we're considering to see if we're on the same page for how long we'd need/want to support different versions of Python, OpenSSL, etc.

Yup, for 10% of your users we'll wait.

And yeah, since you're probably our most significant downstream, and we're your finickiest upstream I think it'd make sense for @reaperhulk and I to at least be aware of what you're thinking.

Yeah please don't hesitate to reach out @bmw. In this case I thought (completely wrongly and I'm not sure how I came to this conclusion) that Ubuntu had backported compare_digest into their Trusty 2.7.5.

Given the volume of Trusty users we have even outside of certbot we'll need to maintain support for the foreseeable future.

We may also be your downstream that tries to run on the most ancient OSes.

Thanks for keeping Trusty support. It avoids us having to write code specifically for the platform to transition them to Python 3.

As for our new packaging plan, we haven't decided exactly what we're doing yet, but I can tell you how what we're thinking would mean for what we'd ideally like to see from cryptography. If you want to get into the weeds, I followed the suggestion from someone at PyCon and shared it in detail with a post to the distutils-sig mailing list.

This may change, but the relevant highlights of what we're thinking right now are:

• Only support Python 3. We probably will drop Python 2 support in the next year.
• We will continue to use version of Python 3 provided by the OS package manager except on RHEL based distros. For us, this mainly means we'd want to keep support for the version of Python 3 in each version of Debian and Ubuntu until the distro release is EOL'd.
• We will continue to pull our Python dependencies from PyPI so any new Python dependencies (as long as they don't have non-Python dependencies) should be no problem at all.
• Thanks to your Linux wheels, OpenSSL support is largely a nonissue, however, about 3% of our users are on ARM. This is mainly Raspbian, so keeping support for the version of OpenSSL in Debian's releases would be nice.

Related to that last note though, Certbot currently shells out to openssl as a workaround for pyca/pyopenssl#306. Any interest in getting support for that feature added to cryptography or pyopenssl? This would allow us to remove our dependency on openssl.

@bmw I'd be interested in adding OCSP support to cryptography, yes. Does the API need to validate the signatures on the responses or just parse the data into a form you can use to validate it yourself?

Awesome. Thanks @reaperhulk.

I think we'd prefer the former, but the latter is all we really need.

One aspect of the OCSP feature we would like to see is the ability to get the raw OCSP response. We need this for certbot/certbot#956 which one of my coworkers has almost finished implementing.

@bmw Does this sound like roughly what you'd expect?

Certbot constructs an OCSP request with cryptography's APIs, serializes it, and then makes an http request with whatever library is desirable (be it async or otherwise). The response is a raw DER encoded OCSPResponse, which can be passed to cryptography for parsing as well as written to disk (after being verified that it is valid) to provide as a stapled response.

Yeah that sounds great!

passing by, thumbing up for OCSP support through cryptography api

I just noticed that OCSP support was added in 2.4. Thank you so much for adding this.

@bmw you're welcome, sorry about forgetting to tell the certbot team that we had released it!

Not a problem! Being one of our more important dependencies, I should probably subscribe to updates about the work you all are doing anyway.