Re: [gentoo-project] RFC: Making GLSAs useful for security

[Mart Raudsepp]

Ühel kenal päeval, N, 15.12.2016 kell 16:43, kirjutas Yury German:
> The problem with that is that a GLSA check will fail at that point,
> we can not also include the fix are (security project) in the fix
> section as we do not know what version will be final on
> stabilization. For example, if you look in Bug Tracker the bugs can
> go stable but to stabilize them will take a very long time. Sometimes
> it takes as long to stabilize them that a new version is out before
> the original is stabilized. (Just a note, not blaming the arches
> groups here, it is simple the way it is).  What about the times that
> during stabilization a dependency is found and it takes a month or
> two to fix it? The GLSA goes out, it now tells the users to update to
> a version that does not exist.
>
> It does sound good, but not practical as it will introduce confusion
> for the users especially those that do not constantly maintain their
> system and only update the security patches. 

My proposal addresses this by introducing a new glsa-check identifier,
so one is for actionable issues, another for informative.
We can bikeshed if the one people are used to use ('affected') would be
including only actionable, all known vulnerabilities in its report, or
perhaps a mix with some agreed grace period based on security severity.
I mean we can do such bikeshed AFTER it has been agreed to change the
general approach of GLSA release timing, if that gets agreed to, no
point yet to drown the thread with that yet.
Also we could still agree to push out a GLSA only after the first
architecture has stabled it, provided it is written and the first
stabling happens fast enough.

I have not thought about the optics for the GLSA releases to other
mediums, which get picked up by various other parties.


> Those users that have a practice of updating (world update) on a
> schedule (Weekly / Monthly) would receive the patches if the stable
> version is in the tree.

Those updating periodically are vulnerable for a longer time right now
on architectures that stable fast, which is the majority of what our
userbase is on imho (amd64). E.g fix to a remotely triggered
vulnerability is provided on Tuesday, amd64 stables on Wednesday, ppc64
as the last architecture stables on Saturday (for sake of example, they
have only weekend manpower), and this monthly upgrading sysadmin checks
for GLSA issues every Friday - because with the status quo we didn't
push out a GLSA that got drafted on Tuesday for amd64 users, this
sysadmin will end up keeping his systems vulnerable for a week longer
than he could have if we didn't artificially delay the glsa report.
Even if that sysadmin responsibly checks GLSAs daily, we still keep his
systems artificially vulnerable in this example for 2 days longer than
necessary.
And that's why I'm saying just reducing what is security supported due
to some architectures taking too long to stabilize is NOT a good enough
solution, unless we define "too long, you aren't security supported
anymore" as "you take over 1 day longer to stabilize than amd64" or
something and end up with only amd64/alpha (and maybe x86) as security
supported as it happens to be right now with response speed. Hence this
alternative proposal.


Mart

> >
> > On Dec 15, 2016, at 2:05 PM, Paweł Hajdan, Jr. <phajdan.jr@gentoo.o
> > rg> wrote:
> >
> > On 13/12/2016 21:36, Mart Raudsepp wrote:
> > >
> > > Solution proposal:
> > >
> > > Push out a GLSA as soon as the relevant fix is available in the
> > > tree in
> > > any form (usually when the security bug moves from [ebuild] to
> > > [stable]
> > > state), so the fixed_in (unaffected) atoms have become known.
> >
> > Sounds good.
> >
> > Given the GLSA process itself introduces delays, and it seems to
> > start
> > only after [stable], sending it earlier and in a simpler way is a
> > nice
> > simplification of the process.
> >
> > Paweł
> >
>
>