Hi Kristian,

On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote:
> A draft of a Pre-GLEP for the Security project is available for reading
> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
> 
> The GLEP follows a line of GLEPs for special projects that have
> tree-wide access in order to ensure proper accountability (c.f GLEP 48
> for QA and still non-produced GLEP for ComRel (I've started working on
> this and will be presenting this one later as current ComRel Lead))
> 
> Comments, patches, threats, etc welcome

First of all, thank you for this Pre-GLEP, since we really need some
public and established policy for the Security project.

1. From this proposal it looks like the Security Project Lead
obtains a lot of power and a lot of responsibility, maybe too much
for a single person to handle.

While the Deputy may be assigned, this still gives all power to
single hands. Maybe it will be better to establish something like
the Security Project Council (SPC)? E.g. three project members may
be elected to this SPC, so that all serious decisions will require
some team agreement from at least 2 SPC members. This way the
Deputy will not be needed as well.

2. "If a vulnerability is unlikely to be fixed by upstream or the
package's maintainer it might require a package mask." — I'd like
to see this expanded to more detail, because it is possible to mask
for removal and to simply mask without scheduled removal.

Sometimes an application is desirable even if it is vulnerable,
e.g. if there are no alternatives. Sometimes a vulnerability is
minor or affect a very rare use case. Sometimes users need a
specific software version for their workflow and they don't really
care about security — this affects many scientific packages being
used at isolated HPC setups.

My point is that users must be informed about security problem, but
they still should have a choice. So it should be either a rule
"mask without removal" or clear guidelines when to remove a
package and when to not.

Best regards,
Andrew Savchenko

Attachment: pgpg_bm2zlxSw.pgp
Description: PGP signature

Reply via email to