Re: [gentoo-project] Re: [pre-glep] Security Project Structure

["M. J. Everitt" <m.j.everitt@iee.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4068 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]