Prerequisites

-For this reason, the security team separates Gentoo architectures into t= wo +For this reason, the Security Team separates Gentoo architectures into t= wo groups, supported and unsupported:

Kernels =20

-Currently kernels are not covered by the GLSA release process. +Kernels are not covered by the GLSA release process. Vulnerabilities must still be reported and will be fixed, but=20 -no GLSA will be issued when everything is solved. +no GLSA will be issued when everything is solved.

=20 -This policy should be changed when new tools are added to cover -security vulnerabilities affecting the different kernel sources. +The kernel-check +utility is being developed to provide Kernel security information. +This policy should be updated accordingly when it is ready. =20 @@ -148,13 +136,13 @@ newer (~ARCH) ebuild, but the older (stable) packages are not affected, = or when the package has never had any stable ebuilds in the tree. In this case the vulnerability must still be reported and will be fixed,= but=20 -no GLSA will be issued when everything is solved. +no GLSA will be issued when everything is solved.

=20 This policy might be changed when our tools support more complex upgrade paths and if a sufficient number of GLSA coordinators join -the security team. +the Security Team. =20 @@ -174,7 +162,7 @@ security@gentoo.org). Major security lists should have official scouts assigned to them which should ensure that all vulnerabilities announced on these lists get a -security bugzilla entry. +security Bugzilla entry.

=20 @@ -185,24 +173,24 @@ =20

Confidential vulnerabilities (for example coming from developer's direct -communication or restricted vendor-sec lists) should follow a specific -procedure. They should not appear as a public -bugzilla entry, but only in security-restricted media like a private -bugzilla section or the GLSAMaker tool. They should get -corrected using private communication channels between the GLSA coordina= tor -and the package maintainer. +communication or restricted lists) must follow a specific procedure. +They should not appear as a public bugzilla entry, but only in=20 +security-restricted media like a private bugzilla section or the GLSAMak= er tool. +They should get corrected using private communication channels between t= he GLSA +coordinator and the package maintainer.

=20 Communication for confidential vulnerabilities should be properly encryp= ted. -They should be sent to specific security team members and encrypted with -their GPG key. The list of the security team members is available at=20 +They should be sent to specific Security Team members and encrypted with +their GPG key. The list of the Security Team members is available at=20 security.gentoo.org, thei= r key IDs can be looked up on the Gentoo Linux Developers List and their keys can be retrieved from the subkeys.pgp.net keyserv= er. +The use of IRC and other unencrypted messaging methods is discouraged. =20 @@ -312,7 +300,7 @@ =20

Here is the table of the resulting severity levels. They should be set -to the bugzilla severity level of the same name: +to the Bugzilla severity level of the same name:

=20