On Wed, 7 Feb 2007 17:12:34 +0100, Dominik 'Rathann' Mierzejewski wrote: > > it is not so much about somebody stealing your account, it's about somebody > > going through the process to create their _own_ account. Once that has been > > done ( and we keep wanting to LOWER the barrier for this!! ), if there are no > > barriers in place, that person can now run roughshod all over all the > > packages, making any changes they want, building anything they want, causing > > automated pushes to push out whatever they built, leading to people grabbing > > packages and getting rooted, > > That won't happen THAT easily. Isn't the sign-and-push process manual? > Aren't the people who handle it supposed to check what they sign? A few random plausibility checks come to my mind. But checking some >50 builds per day for all sorts of security breaches would be a lot of work. Most likely "Impossible Mission" even for a team of people, considering how long ordinary reviews take. Just think about where you would start examining build-job results (src.rpm, binary rpms, buildsys logs) and what files inside a src.rpm you would trust, if at all. How many packagers trust upstream tarballs? The community (of packagers and users) should follow the cvs commits as much as possible. In particular, packagers ought to observe the changes in build requirements they depend on. Sponsors ought to monitor their new contributors commits (how long? one year? two years? seven years?). A mistake I don't want to make is to discuss possible attack vectors. Packages in the needsign queue are not signed automatically and are not published automatically. But a successful build job enters the needsign queue and is available to all subsequent build jobs automatically. This turns the needsign queue into a two-sided sword. Who examines successful build jobs *before* they are released and before submitting an own build job? How many packagers check the official build logs painstakingly? And if packages from the needsign queue are published [quickly], who examines them before installing them, but after they may have "infected" other build results already? Co-maintainership could increase security. But hoping that a small team of people can guarantee ultimate security via global post-build checks, is Utopian. -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
