On 03/12/2017 03:55 AM, Rich Freeman wrote: > On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand <[email protected]> > wrote: >> On 03/11/2017 11:23 PM, Andrew Savchenko wrote: >>> >>> 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. >> > > Is there any reason that this can't be left to maintainer discretion? > The package is masked and clearly advertises its security issue. The > user can make an informed choice. Do we really need to force the > issue further? What is the benefit to Gentoo in doing so? >
In most cases lack of maintainer participation is likely the issue to begin with. The primary issue with a package mask of this nature is that it is more permanent than temporary in nature. To what extent would other package maintainers need to take it into consideration e.g wrt depgraph breakages (say this is a lower slotted version or last version that supports a specific arch). Granted that isn't much of an issue from the security point of view, but goes more over on QA - the primary reason it isn't explicit in the draft GLEP is that specific rules are difficult to write to cover all situations and as such needs either a lot of preparation to write or will cause issues down the line. The accountability aspects of things is therefore more important than the rules themselves. Quite frankly I thought I left enough of maintainer discretion when stating: * 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. -- 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
