From Fedora Project Wiki

< User:Toshio

Revision as of 19:28, 8 May 2009 by Toshio (talk | contribs) (Add draft category)

What is Pre-review?

FESCo approved a releng request that there be a way for getting some packages into cvs before review in order to work on building the packages in a temporary tag and get them building against each other before they get reviewed and built into a dist tag. The proposal included having the packages pre-reviewed for legal issues and not-from-source included.

This specific instance was for approximately 10 new java packages needed for a maven upgrade but if this is successful it could be used for other new packages that need to be added as a set as well.

How might it be implemented?

1) Package gets a review bug in bugzilla 2) Someone reviews the package for a minimal set of Guideline compliance aimed at finding anything wrong that we wouldn't want to enter the buildsystem. 3) Packages are checked into cvs in such a way that they can only be built for their special tag. 4) Packages are built to a special tag, tweaked, until ready for review. 5) Packages go through normal review 6) Packages can be built for dist-f12

What needs to be done?

We need to define the Guidelines that need to be checked for the pre-review step. We want to make sure that Fedora is not doing anything illegal and not putting the buildsystem/integrity of packages in danger.

Questions on what we're aiming for

To be answered by someone on the java team responsible for the maven update:

  • Are all the packages going to be rebuilt in the master tag or will some packages be moved over from the side tag? We need to be more strict about some things if there's bootstrapping issues (moving directly from the side tag) involved as well.

Proposed Guidelines to Check

Legal

We want to do a check for legal issues so we aren't distributing code that we don't have a right to. So everything in these Guidelines should be checked:

Preventing Malicious Source

We don't want to be building pieces of build toolchain with other pieces of toolchain that could have malicious code embedded in them. We can't be perfect about this but some checks can be done:

Making sure the SourceURL is canonical (via google, checking other distributions, etc) helps to verify that we're grabbing our source tarballs from the correct location. We also need to verify the tarball included matches what's in the source URL:

From Source

We want to make sure that the packages are being built from source. Building with packages that are not from source makes it extremely hard to verify what is actually inside the compiled code. So there's a chance that we're including malicious code without being aware of it.

No System Libraries

Including several upstream projects inside of a package can inadvertantly mix conflicting licenses together (for instance, Apache License and GPLv2), include proprietary code that we cannot ship, include code with security flaws that we are not tracking, and other issues that could cause legal or security issues.