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
1 On 04/12/18 22:30, Aaron Bauman wrote:
2 > On Tue, Dec 04, 2018 at 05:05:55PM -0500, Michael Orlitzky wrote:
3 >> On 12/4/18 4:05 PM, Kristian Fiskerstrand wrote:
4 >>> I personally don't agree with part of this section; security is
5 >>> relative, and if it is stated to not be supported there are no security
6 >>> assumptions. If anything the removal of these arches as security
7 >>> supported demonstrates an active decisions not to support them, and
8 >>> signals to users of these arches that they can't depend on security
9 >>> information from Gentoo. Stable generally means a stable tree of
10 >>> dependencies, without security assumptions, if this is e.g used in a
11 >>> closed lab that likely doesn't impact much.
12 >>>
13 >> This is technically correct, but: how many users even know what a
14 >> security-supported arch is? I would guess zero, to a decimal point or
15 >> two. Where would I encounter that information in my daily life?
16 >>
17 >> If I pick up any software system that's run by professionals and that
18 >> has a dedicated security team, my out-of-the-box assumption is that
19 >> there aren't any known, glaring, and totally fixable security
20 >> vulnerabilities being quietly handed to me.
21 >>
22 >> Having a stable arch that isn't security-supported is a meta-fail... we
23 >> have a system that fails open by giving people something that looks like
24 >> it should be safe and then (when it bites them) saying "but you didn't
25 >> read the fine print!" It should be the other way around: they should
26 >> have to read the fine print before they can use those arches.
27 >>
28 > +1
29 >
30 > Wonderfully put and I couldn't agree more!
31 >
32 I accept that this is probably (to many) a ridiculous proposal, but is it
33 time to reconsider our arch profile definitions of "stable", "developer"
34 and "experimental" so that security policy is reflected in this? Something
35 like a "gold","silver", "bronze", "copper" system perhaps, with criteria
36 similar to the following:
37 - Gold - fully security audited, solid dependency tree
38 - Silver - best effort security audited, solid dependency tree
39 - Bronze - something akin to 'Developer' currently (dependency tracked but
40 not solid)
41 - Copper - entirely experimental
42
43 For me, as a concerned user, I'm prepared to take some risks on security,
44 as most of my systems are behind some form of firewall, and are mostly not
45 exposed to the wild internet. I would prefer that the packages I use are
46 "stable" ie. don't have known bugs, and their dependencies all check out
47 too. So I would qualify as a 'Silver' user.
48
49 I buy the argument that there are plenty of Gentoo users who
50 want/need/expect a 'Gold' service, and I think the security team are mostly
51 able to satisfy this requirement, even if arch teams are not (and I would
52 argue that it is simply the case that stabilisation can be 'passed' by any
53 maintainer for amd64/x86 arches that makes this feasible).
54
55 For arches with a depleted 'team' to do testing and stabilisation (and
56 indeed support) there should remain scope for that arch to be able to move
57 up or down (with council approval) easily and quickly, especially if there
58 should be a resurgence in interest from prospective devs/users. This would
59 automatically fulfil the manpower requirement, and the possibility of
60 reaching 'Gold' standard would become feasible.
61
62 I think there is merit also, in the distinction between 'dev' and 'exp'
63 profiles - and this is the reason I propose a 'Copper' status for arches
64 which really are truly experimental or problematic. Again, if there should
65 be an interested group willing to take on a change of status, this should
66 be encouraged and facilitated where possible.
67
68 I apologise in advance that this is somewhat tangential to the topic of
69 Security policy, but I feel that we shouldn't lose the basic meaning of
70 'stable' that we are using currently, without some form of tangible
71 replacement. Also, we shouldn't have users jumping through too many hoops,
72 to get a relatively known-good setup regardless of Arch.
73
74 </my 2 dollars>
75
76 veremitz/Michael.

Attachments

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