Gentoo Archives: gentoo-project

From: "M. J. Everitt" <m.j.everitt@×××.org>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: [pre-glep] Security Project Structure
Date: Wed, 05 Dec 2018 09:12:11
Message-Id: b2ba6acb-2166-c0ee-dedf-887ec8567d6e@iee.org
In Reply to: Re: [gentoo-project] Re: [pre-glep] Security Project Structure by Aaron Bauman
On 04/12/18 22:30, Aaron Bauman wrote:
> On Tue, Dec 04, 2018 at 05:05:55PM -0500, Michael Orlitzky wrote: >> On 12/4/18 4:05 PM, Kristian Fiskerstrand wrote: >>> 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. >>> >> This is technically correct, but: how many users even know what a >> security-supported arch is? I would guess zero, to a decimal point or >> two. Where would I encounter that information in my daily life? >> >> If I pick up any software system that's run by professionals and that >> has a dedicated security team, my out-of-the-box assumption is that >> there aren't any known, glaring, and totally fixable security >> vulnerabilities being quietly handed to me. >> >> Having a stable arch that isn't security-supported is a meta-fail... we >> have a system that fails open by giving people something that looks like >> it should be safe and then (when it bites them) saying "but you didn't >> read the fine print!" It should be the other way around: they should >> have to read the fine print before they can use those arches. >> > +1 > > Wonderfully put and I couldn't agree more! >
I accept that this is probably (to many) a ridiculous proposal, but is it time to reconsider our arch profile definitions of "stable", "developer" and "experimental" so that security policy is reflected in this? Something like a "gold","silver", "bronze", "copper" system perhaps, with criteria similar to the following: - Gold - fully security audited, solid dependency tree - Silver - best effort security audited, solid dependency tree - Bronze - something akin to 'Developer' currently (dependency tracked but not solid) - Copper - entirely experimental For me, as a concerned user, I'm prepared to take some risks on security, as most of my systems are behind some form of firewall, and are mostly not exposed to the wild internet. I would prefer that the packages I use are "stable" ie. don't have known bugs, and their dependencies all check out too. So I would qualify as a 'Silver' user. I buy the argument that there are plenty of Gentoo users who want/need/expect a 'Gold' service, and I think the security team are mostly able to satisfy this requirement, even if arch teams are not (and I would argue that it is simply the case that stabilisation can be 'passed' by any maintainer for amd64/x86 arches that makes this feasible). For arches with a depleted 'team' to do testing and stabilisation (and indeed support) there should remain scope for that arch to be able to move up or down (with council approval) easily and quickly, especially if there should be a resurgence in interest from prospective devs/users. This would automatically fulfil the manpower requirement, and the possibility of reaching 'Gold' standard would become feasible. I think there is merit also, in the distinction between 'dev' and 'exp' profiles - and this is the reason I propose a 'Copper' status for arches which really are truly experimental or problematic. Again, if there should be an interested group willing to take on a change of status, this should be encouraged and facilitated where possible. I apologise in advance that this is somewhat tangential to the topic of Security policy, but I feel that we shouldn't lose the basic meaning of 'stable' that we are using currently, without some form of tangible replacement. Also, we shouldn't have users jumping through too many hoops, to get a relatively known-good setup regardless of Arch. </my 2 dollars> veremitz/Michael.

Attachments

File name MIME type
signature.asc application/pgp-signature