On Thu, 01 Jun 2006 09:25:11 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 01.06.2006, 08:13 +0200 schrieb Thorsten Leemhuis: > > Am Mittwoch, den 31.05.2006, 22:38 +0200 schrieb Michael Schwendt: > > > 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. > > Just a quick howto in case if people don't know how easy it is: > > 1. create a package, prepare it for review > 2. get it reviewed and yourself sponsored > 3. import it and build > 4. checkout some popular packages, upload new tarballs with a slightly > different names and a root-kit in it. Modify the "Source0" accordingly > 5. commit the changes, hit "CTRL-C" at the right point of time so the > commit-message is not send to commits-list > 6. wait until the maintainer fixes something else in the package an > rebuilds it without noticing the changes done to CVS in between All fine, step-by-step instructions for any weird person out there, who might want to try this for a bit of "fame". I can only repeat, you are not the first one to express a paranoid view without proposing a feasible solution. Theoretically, it is possible with ACLs to tighten the access to "some popular packages" in CVS. And it would also be possible to lock down the buildsys in a similar way. Though, this would make it more complicated for a security team. Hey, isn't this fun? A security team which we need to trust as they should be able to touch many if not all packages without jumping over extra hurdles. Package maintainers ought to make sure they cvs tag only those files in their working copy which they agree with. The majority of package maintainers probably never runs "cvs up", but only commits and tags from within a local working copy anyway. Others don't even use plain cvs too often and cvs-import.sh full src.rpms, which can overwrite/revert changes accidentally, too. "cvs log" does catch all commit activity, doesn't it? So, packagers, start using it if you want to contribute a bit more safety. > There are slightly variants that even might work better. E.g. > > - have a popular package in Extras and do it with that directly (that > the easiest solution) > - instead of "6.": build the modified packages yourself -- chances are > quite low that somebody will notice it > - instead of "6.": file a bug against the package you modified with a > spec-file patch that fixes something in the package without requiring a > new version -- the maintainer might apply it and request a rebuild (that > is done with the modified tarball you imported to cvs earlier) In a more shiny world, popular packages ought to be maintained and monitored by multiple people. The more popular, the more maintainers (and the more monitoring from within the community, e.g. people who cvs co a package when they see a new build or who examine cvs log and cvs diff). Don't get me wrong. I'm not opposed to any thoughts about this. But even if a mighty ACL implementation were available (also in the buildsys), it would not be me who could guarantee that over time nobody would acquire the necessary access privileges to do something nasty eventually. Look, there are people already today who would not need to go through steps 1-6 at all if they wanted to replace a binary (!) package in the repository. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
