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

[Tahoe-LAFS]

#2215: mitigate heartbleed vulnerability
-------------------------+-------------------------------------------------
     Reporter:  daira    |      Owner:  daira
         Type:  defect   |     Status:  assigned
     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 warner):

 BTW, current debian unstable (as well as testing aka "jessie") has OpenSSL
 1.0.1j on most platforms:

 https://packages.debian.org/search?keywords=openssl&searchon=names&suite=all&section=all

 debian stable (aka "wheezy") has something named "1.0.1e-2+deb7u13", which
 self-reports as 1.0.1e but includes some number of security fixes.

 If we used "2" and required an OpenSSL-reported version >= 1.0.1j, then
 build-from-source and dpkg would work fine on unstable, but build-from-
 source on stable would fail. We'd have full control of the error message,
 so we could provide pointers to either:

 * comment out / modify the version check to tolerate 1.0.1e
 * install a pyopenssl that includes a bundled OpenSSL-1.0.1j
 * install OpenSSL-1.0.1j from source (maybe to /usr/local) and somehow get
 pyopenssl to use it

 I'm hesitant to embed an OpenSSL in pyopenssl in our tahoe-hosted eggs
 unless that's what the upstream pyopenssl folks want to do, or to depend
 upon having such a combination. I'm slowly becoming more comfortable with
 the idea of breaking some platforms if it means we can have simple
 version-detection code. If there were a simple heroic for Heartbleed, I'm
 ok with that too.

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