On 03/11/2017 11:23 PM, Andrew Savchenko wrote: > 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. >
The thinking here is that the project lead is the responsible party. Any ambiguity can still be escalated to the Gentoo Council, but someone needs to be responsible from the side of the Gentoo Security Project. > 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. At some point, of a package does not belong in the main tree due to security vulnerabilities, they can still be kept in an overlay by a respective project without it impacting other users. I'm not convinced that impacts the overall user experience of other Gentoo users. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
signature.asc
Description: OpenPGP digital signature
