report from Nuts and Bolts party 2014-04-14

Zooko Wilcox-OHearn zooko at
Tue Apr 15 16:13:01 UTC 2014

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Twice-Weekly Hack Hour, 2014-04-14

in attendance: Zooko (scribe), Daira

from now on Monday LAFS Hack is Nuts and Bolts and Thursday LAFS Hack
is Tesla Coils and Corpses!

today's agenda: release engineering (1.11.0)

We merged the patch for #1847.

We looked at a few new tickets to decide whether to put them in the
1.11.0 Milestone or not:

* #2217 (): yes
* #2220 (): no
* #1431 (): no, we're past feature-freeze
* #2218 (): no, depends on #1431
* #2208 (excluded from Debian because of no-source-code-included files): yes
* #2214 (DOS defect concerning forged shares): no. It is a bug, but it
doesn't seem to be a critical bug in terms of impact.
* #2213 (Make SFTP generate its own key): no; It is a feature-request.
* #1759 (cloud backend: debug command to dump a listing of objects in
a cloud container); no (new feature)
* #1906 (constant-time directory lookup): no, because it is awesome
science-fiction stuff that is probably impossible in lots of otherwise
perfectly normal-seeming universes ☺
* #1784 (add happiness count to check and repair reports): yes,
already fixed and in trunk
* #2149 ("tahoe start" emits an error message when tahoe is already
running): no; It is a feature. [Zooko is sad because git-annex↔LAFS
wants this. Oh well—let 1.12 come soon!] Opened
* #2210 ('sudo pip install .' fails if tests have been run):
undecided; Hopefully this is someone else's (pip's) problem.

* #2193 (pyOpenSSL 0.14 pulls in a bunch of new dependencies): yes
* #2215 (mitigate heartbleed vulnerability): yes (critical, ugh)
* #2217 (SandboxViolation:
511) {}): yes

pyOpenSSL packaging—argh! We considered shipping our own binaries of
pyOpenSSL with a version number that we made up, called "0.13.post1", and
making Tahoe-LAFS depend on "pyOpenSSL == 0.13.post1". We considered shipping
a fork of pyOpenSSL which has packaging-metadata name "flyOpenSSL" but still
still installs a "package" (which is the Python word for a .py file or a
directory containing .py files) named "OpenSSL". We considered shipping a
fork name "flyOpenSSL" that installs "package" (directory) named
"flyOpenSSL". At this point Zooko got really frustrated and suggested
rewriting everything in Rust in order to get away from the hideous mess that
is Python packaging.

Then we came up with a relatively reasonable-sounding proposal, which is
something that the pyOpenSSL devs could do:: 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 avoid putting the heartbleed vuln into 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 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 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.

So, we'll open a ticket suggesting this to the pyOpenSSL team. Zooko is not
going to hold his breath, though. Instead he's going to start rewriting
everything in Rust. ☹ Just kidding. I think.

Also, Daira added a comment to an earlier discussion, in order to affirm the
pyOpenSSL/ developers and let them know that we don't think
they are dumb:

* #2212 (tahoe renew)
* #1377 ("tahoe start" claims to have started when it didn't (due to
port number conflict)): no; We don't have a patch for it.
* #2147 (web.port can conflict): no; See above.
* #2135 (Add --print-uri option to "tahoe backup" to dump resulting
backup URI): maybe; It is a new feature, but it has a patch. however
the tests currently fail. it can be included if the tests are fixed,
but is not a high priority.
* 2122 (Update jQuery to address CVE-2011-4969): yes, because we need
to fix #2208 anyway for 1.11
* 2202 (ERROR: UnrecoverableFileError(no recoverable versions)): needs
further investigation, and does not have a fix (if it is a valid bug)
(the related #2203 also does not have a fix)
* 2204 ( no; It applies
only to the leasedb branch.
* 680 (Fix for mutable files with FTP): no; No patch.

We discussed how we'd like to support I2P more by getting their
patches merged into trunk, after the 1.11 release. Fix for mutable
files with FTP "tahoe start"
claims to have started when it didn't (due to port number conflict) cloud backend:
debug command to dump a listing of objects in a cloud container add happiness
count to check and repair reports Ugly shadowing of
directory lookup Update jQuery to
address CVE-2011-4969 Add --print-uri
option to "tahoe backup" to dump resulting backup URI web.port can conflict "tahoe start"
emits an error message when tahoe is already running ERROR:
UnrecoverableFileError(no recoverable versions) 'sudo pip install
.' fails if tests have been run tahoe renew Make SFTP generate
its own key SandboxViolation:
511) {}


Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
Freedom matters.

More information about the tahoe-dev mailing list