----- Forwarded message from Zooko O'Whielacronx -----
Date: Sat, 31 Aug 2013 14:12:07 +0000
From: Zooko O'Whielacronx
To: tahoe-dev
Subject: [tahoe-dev] reproducible builds for Tahoe-LAFS: where do we start?
Folks:
Here's some recent news:
http://m.washingtonpost.com/world/national-security/us-spy-agencies-mounted-...
That article says that the U.S. espionage agencies have
surreptitiously installed sophisticated malware on tens of thousands
of remote machines, and have plans to increase that number into the
millions.
It is important to remember that while the U.S. espionage
establishment is the one that is currently having its activities and
plans exposed, it is not the only one of its kind. It is safe to
assume that there are many other organizations with similar
capabilities engaged in similar activities. It is also likely that
some of those groups are engaged not in warfare but in industrial
espionage or other kinds of theft or sabotage.
In this modern world, it would be very useful if you could check
whether the binaries that you are running are the same as the binaries
that other people are running that were ostensibly built from the same
source code.
That way, implanted malware would be more likely to be exposed. This
is the idea of "reproducible builds", as championed by Tor ¹, Bitcoin
², and Debian ³ . LWN.net recently had a nice overview article about
this: ⁴.
Now: how do we start? We have a trac ticket:
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2057# reproducible builds
But I don't understand what the next step on the path to really
protecting users. The situation we're considering here is that a user
is installing Tahoe-LAFS, for example by running "sudo apt-get install
tahoe-lafs" on Debian, and the computer that was used to build the
tahoe-lafs Debian package had malware running on it, that inserted a
backdoor into the tahoe-lafs Debian package. How can we help users to
defend against that?
There are lots of other packagers which provide installable versions
of Tahoe-LAFS to their users. For example, the "pkgsrc/NetBSD" system
⁵, whose Tahoe-LAFS package is maintained by Greg Troxel, who reads
this mailing list.
If you click on the big friendly blue "Download Tahoe-LAFS" button on
the front page of https://Tahoe-LAFS.org, it takes you to a menu of
packages provided by different free-and-open-source operating systems.
One thing that worries me about this issue is that it is one of those
things were different open source projects can reasonably assume that
it is Someone Else's Problem to fix this. I've often seen this: when
there is an issue that spans multiple open source projects, that it is
hard to make progress on that issue, since every open source project
has a theory of how it ought to be fixed by some other open source
project taking responsibility for it.
So what can we do to push on this issue now?
Regards,
Zooko
¹ https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-...
² https://en.bitcoin.it/wiki/Release_process
³ https://wiki.debian.org/ReproducibleBuilds
⁴ http://lwn.net/Articles/564263/
⁵ ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/filesystems/tahoe-lafs/README.html
_______________________________________________
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
