Am Mittwoch, den 31.05.2006, 22:38 +0200 schrieb 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! ;) Well, I'm guilty with bringing up some topics where others think they are not worth debatting. But this time it was someone else who started the this topic with the words "as someone pointed out, you can just upload a new .tar.gz to the lookaside with your evil changes in them... no one is likely to catch that." ;-) But to be fair: Yes, I think it is a problem. IMHO it's currently way to easy to bring in something nasty to Fedora Extras. And it might be a big problem as soon as someone does something nasty because users will automatically download it with yum. In other words: I really fear the news entry "Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected until somebody noticed an removed the package." Is that really what we want? I don't want that. > 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. You have some points here. But what do you suggest? Leave everything as it is? CU thl -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
