[gentoo-dev] [RFC] Beyond GLSAs: improving Gentoo Security user experience

[Michał Górny]

Hello, everyone.

TL;DR: I think we should work towards delivering a complete list of
vulnerable packages and ability to rebuild on that (not only these that
traditionally involved GLSAs), and possibly also information
on vulnerabilities that are not fixed reasonably quickly.


Background
==========

The Gentoo Security process right now seems to be focused on developers.
We get Security bugs and CC package maintainers, we bump packages
and fast stabilize if necessary, we clean vulnerable versions up.
The process is good but in my opinion it's often missing the last step
-- actually delivering the fixes to our users.

Of course, it is a strong recommendation that people should keep their
system up-to-date by frequently running deep @world upgrades. However, I
think we all realize that not all people do that. In fact, our own Infra
doesn't do that and I have to say that right now our own servers are
probably running dozens of vulnerable packages.

While we could argue that people shouldn't do that (and we've been doing
this for years now), so far we haven't managed any great success at it.
Not to mention all the corner cases where you either can't upgrade or
you're simply silently forced by Portage to stay on an older version. So
it's time to explore the alternatives.

A quick grep shows that around 20% of Security bugs are getting GLSAs
('glsa+' vs 'noglsa' whiteboard). This means that in roughly 80% cases
GLSA-based infrastructure (e.g. glsa-check) can't reliably inform users
of vulnerable packages and/or trigger upgrades.

The other side of the problem is that the GLSA process seems to be
rather focused on fixed vulnerabilities. However, we do not seem to
release GLSAs before a fixed version is available, even if there is
no fix in sight and there is a suggested mitigation (that we can't apply
ourselves).


The problems
============

All this considered, I'd like to formulate two problems with the current
process:

1. Users are not explicitly informed and not provided with explicit
upgrade mechanism for vulnerabilities that are not considered GLSA-
worthy.

2. Users are not informed of important vulnerabilities that do not have
a proper fix at hand.


Potential solutions for Problem 1.
==================================

I think the problem should be considered in two parts: the developer
input part and the delivery part.

As for the delivery part, one option would be to reuse the GLSA format.
Loosen the specification a little, and start publishing GLSAs without
specific details, possibly just some short summary and package matchers.
However, this would result in the GLSA repository growing significantly
-- not sure if we consider this a problem.

An alternative I can think of would be to use a flat file for this. This
is e.g. what NetBSD does (it keeps the verbose advisories and full list
of vulnerabilities separate). In fact, I suppose we could roughly use
package.mask-alike format to avoid inventing new formats.

As for the input part, I think we should try to avoid imposing much
additional work on Security team members. Ideally, we'd be able to make
this a 'one click' solution reusing the existing data (i.e. Security
bugs). However, I don't think this is entirely possible right now.

Something like having GLSAMaker pre-fill a template based on 'Package
list' field of a Security bug could be a good start. Alternatively, we
could look into doing the reverse -- giving all involved developers
minimal access to GLSAMaker, and having it initially file Security bugs
based on structured input.


Potential solutions to Problem 2.
=================================

Here I don't think we need much of a technical solution. Rather,
I think that Security team should be able to release GLSAs in these
cases to inform users of the situation.


Comments
========

WDYT?