|GLEP : Security Project's purpose and abilities|
|Author||Kristian Fiskerstrand <firstname.lastname@example.org>|
This GLEP outlines the purpose, responsibilities and abilities of the Gentoo Security Project.
This GLEP aims to document the processes of the Security Project and enpowering the project to operate on a wide scale across the Gentoo tree, within the structure provided by this GLEP.
The Security Project's purpose is to ensure users are provided with applications that to the best of the knowledge of the Gentoo Developers are free of vulnerabilities. In order to achieve this purpose, the Security Project require certain abilities and responsibilities as outlined in this GLEP in order to ensure the best interests of all users.
Security Project Lead
* The Security Project is required to have a Security Project Lead * The Security Project Lead is chosen at least yearly by private or public election among the members of the Security Project. * The Security Project Lead is required to be confirmed by the Council. * The Security Project Lead's term expires one year after confirmation, and during any period that the position is vacant the Council may appoint an interim lead. * The Security Project Lead can choose one member as a Deputy. The Deputy has all of its powers directly delegated from the Security Project Lead and thus the Deputy's actions and decisions should be considered equal to those of the Security Project Lead. * The Deputy is directly responsible to the Security Project Lead and its actions reflects upon the Security Project Lead.
Joining the Project
* All members wanting to join the Project needs to be approved by the Security Project Lead (or if a Deputy is appointed; the Deputy). * The applicant must demonstrate a thorough understanding of the duties he or she would like to perform. * The applicant must have successfully completed the Gentoo Developer quiz. * By accepting the applicant the Security Project Lead will accept the responsibility to direct them as part of the team and will be held responsible for any action the Project Member takes on behalf of the Security Project. * The Security Project Lead can remove a member from the Security Project whenever reasonable.
Security package version/revision bumps and package masks
* The Security Project does not want to override the maintainer's autonomy, but if inactive might be required to fix a security vulnerability by means of version bump or application of a patch in a revision bump. * If a vulnerability is unlikely to be fixed by upstream or the package's maintainer it might require a package mask. Such mask should never break the stable dependency tree. * A package mask should only be applied if the security vulnerability identified warrants a GLSA c.f the Vulnerability Treatment Policy (VTP) and the elapsed time has exceeded tree times the target delay specified in the VTP. * These actions, performed on behalf of the Security Project, should only be used if the Project finds it is in the best interest of users and fellow developers to have the issue addressed as soon as possible. Such action needs to be approved by the Security Project Lead (or if a Deputy is appointed; the Deputy)
Additional Security Project bugzilla notes
* The Security Project is exempt from the guideline of waiting 30 days for stabilization of a new package version. * Bugs indicating a security vulnerability can be reassigned as a bug handled by the Gentoo Security Project. * Bugs in the Gentoo Security category shall not be closed without the consent of a Gentoo Security Member.
Subscription to security lists and acting on behalf of Gentoo
Auditing and public reporting of issues in the name of Gentoo
Upstream reporting of expected security bugs should only be done using the @gentoo.org email address if done by a member of the Security Auditing Project or the issue has been privately reported and accepted as a security vulnerability in accordance with the procedures set forth by the Security Project (at the time of writing found in the GLSA Coordinator Guide section 2.4 Auditing).
Security Project Members should always keep information learned through access to embargoed lists confidential. Access to other Gentoo Developers should only be granted on a need to know basis, and Gentoo Developers gaining access to such embargoed lists are required to keep the information confidential.
Requests to gain access to embargoed lists in the name of Gentoo should only be done with the approval of the Security Project Lead (or if a Deputy is appointed; the Deputy). The Security Project Lead is responsible for maintaining a list of who has access to various embargoed lists and ensure proper updates in access in accordance with developments of the Security Project both in terms of active participation to ensure that the Security Project can act on the information provided on these lists in a responsible manner and ensuring a member no longer active in the Security Project has access in the name of Gentoo.
CVE Numbering Authority (CNA) status
The Security Project shall maintain tools and processes in a manner that is compatible with becoming a CVE Numbering Authority
Documentation of process
The Project shall have procedures in place to document its process and regularly update the documentation including the Vulnerability Treatment Policies.
The Security Project shall maintain a list of security supported architectures. The list of supported architectures shall be maintained in the VTP, and changes to the list of supported architectures shall be announced to the gentoo-project mailing list.
This GLEP describes the Gentoo Security Project purpose, role and abilities.
Not applicable for this GLEP.
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/