[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Preventing government subversion in Debian, verification of binary package uploads

On Sat, 2013-08-24 at 14:51 +0200, Erich Schubert wrote:
> Hello all,
> Prism, NSA, Guardian etc. - I assume all of you have been following
> these reports, and otherwise you definitely should start reading the
> news.
> One thing that apparently has been happening a lot these days are
> secret court orders in the U.S. For example Google apparently was
> forced to install some NSA devices, and given some compensation for
> this. But they are not allowed to talk about it.
> I am wondering how we can prevent a similar thing to happen to Debian.
> We're big, so we are probably an interesting target for them. There
> are quite a few developers in the U.S. and UK that could probably be
> served such a secret court order and be forced to modify their
> packages. For example, upload a new kernel that has a built-in
> backdoor for the NSA.

Installing backdoor code on millions of systems is not a good way to
keep a secret.  (Stuxnet was carefully targetted at Natanz, but it still
spread and could be analysed by third parties.)  What we see happening
at the moment is service providers being force to put taps and backdoors
in their own facilities where they can usually be kept secret.

So I don't think we're particularly at risk of being caught up in this.
Nevertheless I do appreciate the value of repeatable, verifiable builds
- and not just for security.

> Now given that we have open source, there is a good chance that a
> "sourceful" modification will not go undetected. But we also have
> binary package uploads. And build daemons can't really fix this
> either, because their admins might then be given such an order.

By the way, I got into the habit of uploading only arch:all binaries for
linux, because upstream bandwidth from home is crap.  You might want to
treat an arch:amd64 upload of linux from me as suspicious.


Ben Hutchings
Never put off till tomorrow what you can avoid all together.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: