Process Change: Package Reviews with Flags

[Michael Schwendt]

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.