[tahoe-lafs-trac-stream] [tahoe-lafs] #2055: Building tahoe safely is non-trivial

[tahoe-lafs]

#2055: Building tahoe safely is non-trivial
-------------------------+-----------------------------------
     Reporter:  leif     |      Owner:  daira
         Type:  defect   |     Status:  new
     Priority:  normal   |  Milestone:  undecided
    Component:  unknown  |    Version:  1.10.0
   Resolution:           |   Keywords:  install security eggs
Launchpad Bug:           |
-------------------------+-----------------------------------

Comment (by leif):

 Replying to [comment:6 markberger]:
 > Maybe something like [https://pypi.python.org/pypi/peep peep] would
 solve this? Peep is just a wrapper around pip that will verify tarballs
 against a hash you give it. If any of the hashes mismatch, peep will abort
 the installation.

 I had not heard of peep before, but after skimming over its mere 224 lines
 of code just now I think I like it! One thing that isn't clear to me
 though is the process by which a user or developer is supposed to become
 aware of new versions of libraries and decide to use them.

 Replying to [comment:7 zooko]:
 > Is there a sufficiently convenient way to ask your operating system to
 deny networking to a given subprocess while still allowing it for your
 other processes? That would be useful not only for building Tahoe-LAFS,
 but any other package that you wanted to build. It is important to note
 that this would not be an attempt to prevent a malicious process from
 communicating, it would only be preventing an honest but imprudent process
 from downloading packages.

 That depends on your definition of sufficiently convenient :)

 There are LD_PRELOAD tools (such as
 {{{usewithtor}}}/{{{torsocks}}}/{{{tsocks}}}) which catch most things and
 redirect them to a socks proxy but they aren't 100% reliable. Some
 programs (even non-malicious ones) might make connections in ways those
 tools don't catch. Also, they're another binary dependency.

 Linux's netfilter firewall can do everything, but we obviously don't want
 to require Linux or root access to build tahoe. ,,But if anyone is
 interested, you can have per-user firewall rules which I believe are as
 reliable as the rest of Linux's privilege separation. On modern Debian or
 Ubuntu systems, you can use the iptables frontend
 [https://en.wikipedia.org/wiki/Uncomplicated_Firewall ufw]. It is as easy
 as "{{{sudo apt-get install ufw}}}", adding a line like "{{{-A ufw-before-
 output -m owner --uid-owner offline-user -j REJECT}}}" somewhere before
 the last line in "{{{/etc/ufw/before.rules}}}", running "{{{sudo ufw
 disable; sudo ufw enable}}}", and su'ing to the "offline-user" user.
 Another way to use ufw is to edit {{{/etc/default/ufw}}} and change
 DEFAULT_OUTPUT_POLICY from ACCEPT to REJECT, and then add rules to
 {{{before.rules}}} allowing a certain user to connect, and then running
 tor or another proxy or VPN as that user. Then you can use your proxy or
 VPN to restrict what kinds of connections are allowed.,,

 I'm not really in favor of making the official build process use firewall
 or LD_PRELOAD tricks, though, as there are of course much better ways to
 do an offline build.

 Today I learned that pip has a {{{--no-download}}} option! So, the short-
 term thing I'd like to see, and which I might try to do myself on my
 branch in the near future is to migrate the build process to use
 virtualenv (which includes pip, and weighs in at 2MB compressed) and
 include that in the repository instead of the [https://github.com/tahoe-
 lafs/tahoe-lafs/blob/master/setuptools-0.6c16dev4.egg/zetuptoolz.txt
 zetuptoolz] fork of setuptools from 2010 which is in there now. The next
 step is to either use peep or make sure that when the deps are not already
 present pip can only ever learn about HTTPS URLs to download them.

 The longer-term thing I'd like to see is deterministic builds (#2057)! In
 my ideal world everyone would be able to build identical debs, tarballs,
 exes, and dmgs. Of course, part of that involves specifying precise
 versions of all dependencies. Another part is building in a VM (gitian
 automates that) which would certainly make it easier to be confident that
 the build process can't get online. I haven't looked very closely at
 gitian yet, but I'm under the impression that it will be quite a bit of
 work to get to that point.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2055#comment:8>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage