[gentoo-project] Re: [pre-glep] Security Project Structure

[Kristian Fiskerstrand <k_f@gentoo.org>]

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

On 12/4/18 9:55 PM, Kristian Fiskerstrand wrote:

> security_project-structure.rst
> 
> Abstract ========
> 
> This GLEP outlines the abilities and purpose of the Gentoo Security
> Project.
> 
> Motivation ==========
> 
> The Gentoo Security Project is the public liaison between Gentoo or
> external users and Gentoo developers in any security-related field.
> The project's mission is to ensure that each known threat in software
> packaged in the stable ebuild repository (stable tree) is fixed in a
> timely manner, thus ensuring that users in the stable version of
> Gentoo receive quality and secure software.
> 
> After considerable events regarding security in Gentoo Linux, like
> SPARC[#SPARC_REMOV]_ and HPPA [#HPPA_REMOV]_ removal from the
> "supported" security architectures, it has become quite obvious that
> the current policy regarding "supported" and "not  supported"
> architectures is not capable of address the most important security
> factor, which is to ensure that end-users are protected from 
> malicious/vulnerable packages in the stable tree.
> 
> This is so because the Gentoo Security Project does not have a proper
> control nor is empowered to ensure that packages inside the stable
> branch of Gentoo Linux official ebuild repository are secure and can
> be fixed in a timely manner. Especially if a threat is published or
> disclosed by the security groups in which Gentoo Security Project has
> participation.
> 
> The current policy of having a "supported" list of architectures does
> not work directly towards the objective of the Security project,
> instead, it only allows the project to recognize some architectures
> as "not supported" and don't be obligated to release a GLSA for that
> specific architecture when an issue arises.


I personally don't agree with part of this section; security is
relative, and if it is stated to not be supported there are no security
assumptions. If anything the removal of these arches as security
supported demonstrates an active decisions not to support them, and
signals to users of these arches that they can't depend on security
information from Gentoo. Stable generally means a stable tree of
dependencies, without security assumptions, if this is e.g used in a
closed lab that likely doesn't impact much.

So comments welcome

> 
> 
> Specification =============
> 
> The Security Project's purpose is to ensure users in the stable
> category of Gentoo 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

Since the security project is moving into tree wide territory here, the
following used to contain a section similar to GLEP 48 on council
approval of leads, but that was removed in a later revision, so we
welcome comments on the topic. Comments welcome.

> ---------------------
> 
> * The Security Project is required to have at least one 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's term expires one year after
> the voting is concluded. If the time expires the current Project Lead
> retains the position until the security team can have another
> election. In the case of Lead's definitive absence, the Security 
> Project must start the election process in a timely manner. * The
> Security Project Lead can choose one member as a Deputy in case of
> only one Lead. 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 -------------------


For some reason, the following section on removal from the project
received significant interest and as such became quite specific.

> Removal from Project --------------------
No futher immediate comments, please see initial email

EOF

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]