Gentoo Archives: gentoo-project

From: Kristian Fiskerstrand <k_f@g.o>
To: gentoo-project@l.g.o, Michael Orlitzky <mjo@g.o>
Subject: Re: [gentoo-project] Re: [pre-glep] Security Project Structure
Date: Tue, 04 Dec 2018 22:17:20
Message-Id: 6e4144f5-e69a-96ea-4ce7-717d1f85376b@gentoo.org
In Reply to: Re: [gentoo-project] Re: [pre-glep] Security Project Structure by Michael Orlitzky
1 On 12/4/18 11:05 PM, Michael Orlitzky wrote:
2 > On 12/4/18 4:05 PM, Kristian Fiskerstrand wrote:
3 >>
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 >
14 > This is technically correct, but: how many users even know what a
15 > security-supported arch is? I would guess zero, to a decimal point or
16 > two. Where would I encounter that information in my daily life?
17 >
18 > If I pick up any software system that's run by professionals and that
19 > has a dedicated security team, my out-of-the-box assumption is that
20 > there aren't any known, glaring, and totally fixable security
21 > vulnerabilities being quietly handed to me.
22 >
23 > Having a stable arch that isn't security-supported is a meta-fail... we
24 > have a system that fails open by giving people something that looks like
25 > it should be safe and then (when it bites them) saying "but you didn't
26 > read the fine print!" It should be the other way around: they should
27 > have to read the fine print before they can use those arches.
28
29 Well, in terms of CVEs the documentation matters quite a bit, the
30 question isn't necessarily what any user would do ... but what a
31 reasonable user would do.. and a reasonable user would consider the
32 documented practices of a project.
33
34 --
35 Kristian Fiskerstrand
36 OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
37 fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Attachments

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

Replies