Summary from last weeks FESCo meeting

[Michael Schwendt]

On Wed, 31 May 2006 20:49:52 +0200, Thorsten Leemhuis wrote:

> Am Mittwoch, den 31.05.2006, 20:31 +0200 schrieb Michael Schwendt:
> > On Wed, 31 May 2006 19:36:38 +0200, Thorsten Leemhuis wrote:
> > 
> > >   * scop> | nirik, I assume that buildsys checks md5sums from the
> > > "sources" file for everything in lookaside cache 
> > >   * that wrong -> the sums are not checked (that has problems when
> > > upstream servers are down or rearrange their layout or ...) and we have
> > > modified tarballs (mp3 stuff removed)
> > 
> > scop is right. The buildsys runs "make srpm" which in turn fetches the
> > md5 sums from the "sources" file and only succeeds in downloading
> > tarballs from the lookaside cache if they match the md5 sums. You
> > cannot simply replace a tarball in the lookaside cache, because when
> > its md5 sum differs, you need to update also the "sources" file.
> 
> Ohh, sorry, yes, that was a bit misleading. The problem simply is: who
> checks that the md5 sums stored in CVS are fine / those from upstream?
> Nobody. I can upload a new version of package "foo" at any time and
> include a rootkit in the tarball I upload. No one would notice.

*sigh* I see you've put that old topic onto your plate. Have fun with it! ;)

No, really, it's has to do with "level of trust". You cannot open the
gates (for almost everyone to enter) and at the same time lock them. In
the past I've pointed this out several times both internally and in the
public. The system where stock contributors sponsor the membership and
access of new contributors is not bullet-proof. Even if we required all
sponsors to verify each and every CVS commit and upload done by their
sponsored contributors, weaknesses would remain. Because for instance, you
could argue that the sometimes huge tarballs are not checked painstakingly
by any packager prior to using them in a package. Or software, which
targets only a marginal group, possibly is not checked by any upstream
community at all. [The single upstream developer might become hostile
eventually. :)] Some contributors are both upstream and packager at the
same time. The chain is as weak as its weakest link. You may be able to
protect key areas, key infrastructure, and key packages with special
access privilege requirements. But you cannot protect everything from the
ground up without putting up too many hurdles which would reduce
productivity. Further, it is a bold venture for anyone to work on
acquiring access through sponsorship with the uncertainty whether really
nobody is watching at the time it is tried to do something nasty.