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. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
