[gentoo-kernel] Gentoo Kernel Policies

[John Mylchreest <johnm@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 732 bytes --]

Please read over the attached drafts.
If you feel it is missing something, is poorly phrased, is excessive, or
anything else please comment to the list.

If no one objects or has changes, I will put these on the project site
and update the page so please make sure anyone not on there who wants to
be on there has got in touch with their details!

The more important of the two is the security policy.

Regards.

-- 
John Mylchreest

Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 0xEAB9E721              
Key fingerprint: 0670 E5E4 F461 806B 860A  2245 A40E 72EB EAB9 E721
Web:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEAB9E721



[-- Attachment #1.2: Kernel Policy: Security --]
[-- Type: text/plain, Size: 2804 bytes --]

                        Gentoo  Kernel  Team
                          Security  Policy

Background
----------
Security is of the up-most importance in any computing project, and we at Gentoo
feel no different. Because of the very nature of the packages maintained
underneath the kernel teams areas of responsibility we felt it necessary to
document the procedure which should be followed to maintain this high standard.

Update Procedure
----------------
Upon being made aware of a new security vulnerability which has not already
been patched in our packages by the security team/liaison it is important that
fixes are immediately pushed into the tree, once properly tested.
The procedure to do this is straight forward, and should be adhered to at all
times.

1: Verify which sources are effected.
2: Generate a patch to fix the exploit against effected sources.
3: If some/all of the effected sources use genpatches-base then commit the patch
   into the genpatches tree, and roll a new release.
4: For each effected package:
   4.1: Update GPV if necessary. If not, add the security patch to UNIPATCH_LIST
        and store in ${FILESDIR}/${KV_MAJOR}/${KV_MINOR}/${KV_PATCH}/ or on
        the gentoo distfiles mirrors. Please ensure you credit the neccessary
        people when doing this.
   4.2: Revision bump the most recent ebuild for each arch in keywords and 
        flatten them to stable. (unless they are release candidates)
   4.3: For those packages which have a replacement version available remove
        the ebuild from the tree.

   For example with development-sources:
   
   Package Before	Keywords Now								Package Now
   2.6.5			x86 sparc alpha ia64 ppc arm s390 amd64		2.6.5-r1
   2.6.6			x86 sparc ppc arm amd64						2.6.6-r1
   2.6.7			x86 sparc ppc amd64 alpha					2.6.7-r1
   2.6.8.1			x86 ia64 ppc amd64							2.6.8.1-r1
   2.6.9			x86 amd64 ia64								2.6.9-r1
   2.6.10-rc1		~x86 ~ia64 ~ppc ~amd64						removed
   2.6.10-rc2		~x86 ~ia64 ~ppc ~amd64						2.6.10_rc2-r1
   
   4.4: packages tested, and then committed using repoman stating clearly in the
        changelog that they fix security vulnerability: XXXX - <linktodesc>
        
If any kernel sources are unjustifiably outdated (for example, version 2.6.5 
was the last sources which work on s390 is justified) an email should be sent to
-core and kernel@ asking for immediate attention or it will be masked.
If after 2 weeks it hasn't been updated, it will be masked.
If the problem isn't rectified within a further month, the package is dropped 
from the tree for being unmaintained.
When masking, a mail should be sent to kernel@ and -dev/-core to notify of why 
and clearly stating that it has a month to get a maintainer or it will be 
removed.

[-- Attachment #1.3: Kernel Policy: Upgrades --]
[-- Type: text/plain, Size: 1392 bytes --]

                        Gentoo  Kernel  Team
                           Upgrade Policy

Background
----------
Gentoo Linux is more than a hobby, or a poject. To many people it is an integral
part of their business. Gentoo is well known for being a metadistribution, and
because of this much of its appeal is derived from portage. 
An absolute requirement when upgrading packages is to ensure the integrity of 
the portage tree once you have added your work.
This policy is set out to ensure that we do not accidentally break architectures
which are supported by our sources by lack of testing.

Update Procedure
----------------

1: Ensure the ebuild you are working on only has the architectures in KEYWORDS
   which you have verified. DO NOT carry these across from existing ebuilds.
2: Make sure that you only introduce new sources/patchsets into the testing
   profile, and not into stable. Only mark sources stable once they have proven
   themselves as such and have no gentoo specific bugs on bugzilla.
4: Check you have documented your changes from the previous version which
   are not part of the upstream changes.
5: Check that your newly updated ebuild doesnt orphan any other ebuilds in the
   package. If it does, remove the older ebuild from CVS.
6: Ensure all files are added to the tree, and you have run repoman scan.
7: Commit in the normal way.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]