respond to OpenSSL ASN.1 parsing bug

[davidsarah]

​http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/086585.html

• review source of pyOpenSSL to see what calls it makes to OpenSSL, check ​assertion that SSL/TLS is not affected.
• what is the impact on Tahoe, if any?
• if needed write advisory, put on website and post to tahoe-dev
• understand how pyOpenSSL links to OpenSSL, and whether we should change pyOpenSSL and bump Tahoe's dependency on it.

[warner]

​http://www.openssl.org/news/secadv_20120419.txt claims that the bug doesn't affect the SSL/TLS code (because that code uses the in-memory ASN1 parsers, rather than the BIO/FILE parsers). The only time Foolscap passes *in* a certificate is when setting up a Tub (i.e. reading back the .pem file that was written out by an earlier invocation), in which case the data was generated locally.

So my first hunch is that we're ok. If the openssl problem turns out to be vulnerable to receipt of corrupt certificates over the wire (as opposed to from local disk), then we'd be in trouble.

[davidsarah]

​http://www.openssl.org/news/secadv_20120419.txt says "Applications only using the PEM routines are not affected.", so we may not be affected even when reading back the .pem file.

[zooko]

I'm assuming that this isn't "Priority: Critical", if only because so much time has passed, and the (uncertain) comments from warner and davidsarah made it sound like it was unlikely to be a problem for us. Of course, it would still be good to make sure!

[exarkun]

According to the announcement the issue was fixed in 1.0.1a, 1.0.0i or 0.9.8v. These OpenSSL versions are all much older than what anyone should be using with Tahoe-LAFS in 2020.