[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2215: mitigate heartbleed vulnerability

[Tahoe-LAFS]

#2215: mitigate heartbleed vulnerability
-------------------------+-------------------------------------------------
     Reporter:  daira    |      Owner:  zooko
         Type:  defect   |     Status:  new
     Priority:           |  Milestone:  1.11.0
  critical               |    Version:  1.10.0
    Component:  code     |   Keywords:  security integrity confidentiality
   Resolution:           |  capleak pyopenssl cffi packaging review-needed
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by zooko):

 Replying to [comment:9 zooko]:
 > There is a proposal in this email for a way to convey the information
 that a particular package has the heartbleed fix: [//pipermail/tahoe-
 dev/2014-April/008988.html]. However, it requires cooperation from the
 pyOpenSSL devs.

 Here is the core of the proposal:

 Here's an idea that could make a cleaner way for both Tahoe-LAFS and also
 other code that uses pyOpenSSL to deal with this:

 The pyOpenSSL maintainers could make new releases of pyOpenSSL, named
 "0.14.1" and (for people like us who can't upgrade to the cffi-based build
 system yet) "0.13.1". The ".1"'s in these version numbers are being used
 as a ''signal'', visible within the Python packaging metadata, that this
 particular package was built by someone who is aware of heartbleed and
 they intended to remove the heartbleed vuln from this package. Then Tahoe-
 LAFS (and Foolscap, and Twisted, etc.) can depend on "pyOpenSSL == 0.13.1,
 >= 0.14.1", to indicate their desire to listen to this signal.

 Then the pyOpenSSL setup.py can help the builder of the package send the
 correct signal, by checking the version number of OpenSSL and refusing to
 build if it is one of the version numbers that had (in the upstream
 OpenSSL release) the heartbleed vuln.

 Now, Debian and Ubuntu ship OpenSSL libraries which have a patch to fix
 the vuln but which still report the original upstream OpenSSL version
 numbers. No problem! When they build pyOpenSSL v0.13.1 and v0.14.1
 packages, they will patch out that check that pyOpenSSL's setup.py does
 (or perhaps pyOpenSSL will offer a "--affirm-heartbleed-fix-is-present"
 build-time option for this), in order for them to correctly send the
 signal that their !Debian/Ubuntu "python-openssl 0.13.1" or "python-
 openssl 0.14.1" package does ''not'' have the vuln.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2215#comment:10>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage