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

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition



On 2/13/14, Jakub Wilk <jwilk@debian.org> wrote:
> * Jacob Appelbaum <jacob@appelbaum.net>, 2014-02-13, 18:36:
>>How many uploaded binaries might include malware?
>
> *shrug* It's not like it's difficult to hide malicious code in source
> packages.
>

It is much harder for you to hide source code changes as a third party
than binary changes.

Many projects have code review processes with people who read each
commit and reason about the contents of each code change. Very few
public projects have a similar process for reverse engineering
binaries or understanding the output of a compiler for releases. Those
few projects generally aim for deterministic or reproducible builds -
this still has the problem of missing a solid understanding of the
output, by the way.

> How many configure scripts that we never rebuild from source contains
> trojans?

There are several serious problems involved in this topic. One expects
that we at least have processes for finding malicious configure
scripts, as we find buffer overflows in C programs or as we find
portability problems in assembler code - no such (Debian) process
currently exists for inspecting binaries that are uploaded by
developers. Perhaps I'm mistaken? Perhaps there is a project for
actively inspecting and reverse engineering binaries that are uploaded
by developers?

A key problem here is not the badly behaving developer - it is the
developer that is compromised and unwittingly becomes party to harming
others. Minimizing this exposure is an important goal and worth
consideration.

All the best,
Jacob


Reply to: