User:K f/GLEP:Security

From Gentoo Wiki
Jump to:navigation Jump to:search


GLEP : Security Project's purpose and abilities
Type Standards Track
Status Draft
Author Kristian Fiskerstrand <k_f@gentoo.org>
Editor
Replaces
Replaced by (none)
Requires
Post History

Status

Draft GLEP

Abstract

This GLEP outlines the purpose, responsibilities and abilities of the Gentoo Security Project.

Motivation

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.

Specification

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[1] section 2.4 Auditing).

Embargoed lists

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[2]

Documentation of process

The Project shall have procedures in place to document its process and regularly update the documentation including the Vulnerability Treatment Policies[3].

Supported architectures

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.

References

  1. ↑ https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide
  2. ↑ https://cve.mitre.org/cve/cna.html
  3. ↑ https://www.gentoo.org/support/security/vulnerability-treatment-policy.html

Rationale

This GLEP describes the Gentoo Security Project purpose, role and abilities.

Backwards Compatibility

Not applicable for this GLEP.

Copyright

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/

Retrieved from "https://wiki.gentoo.org/index.php?title=User:K_f/GLEP:Security&oldid=936717"