Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-security
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-security@g.o
From: Marius Mauch <genone@g.o>
Subject: Re: Kernels and GLSAs
Date: Tue, 20 Sep 2005 16:47:46 +0200
On Tue, 20 Sep 2005 08:53:18 -0500
"Brian G. Peterson" <brian@...> wrote:

> On Tuesday 20 September 2005 07:44 am, Marius Mauch wrote:
> > > Brian Peterson wrote:
> > > The glsa-check tool is basically useless
> > > (as of gentoolkit-0.2.1_pre7), as it shows all GLSAs rather than
> > > just GLSAs for tools that correspond to packages installed on the
> > > system it is run on.
> >
> > Can you explain this a bit more? glsa-check hasn't actually changed
> > for a long time. Also make sure you don't confuse the --list option
> > with the --test option.
> 
> Sure. 
> 
> glsa-check --test
> 
> run by itself, does nothing except give a command summary.
> 
> glsa-check --list 
> 
> lists *all* unapplied GLSAs, regardless of whether the package is
> installed on the running system.
> 
> So, you need to --test each and every GLSA to see if it applies to
> your system.
> 
> glsa-test --test all
> 
> gives a list of GLSAs that apply to a running system, but then
> provides no details about these GLSAs in the list. 
> 
> My take on this as a system administrator who manages many production
> servers running gentoo is that I should be able to run some command,
> perhaps 'glsa-check --test all' that would give me the output of
> --list for each GLSA that 'glsa-check --test' reports.  This would
> allow me to run glsa-check in a cron job and have the output sent to
> me, so that I have enough information to know decide if I need to do
> something on a running production server.

As a system administrator you should know how to combine both to get
what you want:

glsa-check --list $(glsa-check --test new)

> You can't 'glsa-check --pretend --fix all', as this isn't a valid
> combination of commands.  'glsa-check --pretend all' gives a huge
> list that you need to sort through to find the GLSAs that it thinks
> need applying. Running:

Well, pretend and fix are very different operations.

> glsa-check --pretend all | grep -B 1 -A 4 "following updates"
> produces an almost usable result of only the GLSAs that need to be
> applied with the package name that they apply to.  I think that by
> default --pretend should *only* list GLSAs that need applying.

Maybe, but internal that's much more complicated (as "all" is simply
expanded to all GLSAs, and pretend on a single GLSA should show some
info even if there is nothing todo). Guess the easiest would be to add
a new target "affected", would just have to see how bad it is for
performance.

> I think that having a sensible default of 'all' for the package list
> of --test would make a lot of sense, although this is minor.

Maybe, but generally "new" is a much better default than "all".

> From a standpoint of making glsa-check a useful tool, integration to
> emerge is going to be the clear 'solution' to this problem, but
> glsa-check as it exists today requires too many manual steps to make
> it very useful for the proactive monitoring of running systems,
> especially when you have more than a single system to keep track of.

Use bash to your advantage ;)

> For the easiest short-term solution, the output of --test and
> --pretend would tell us what the GLSA summary is (like --list), and
> only for GLSAs that need to be applied, so that we can assess whether
> we should apply the patch or not.  Make sense?

Well, the reason why --test doesn't list the summaries is that you can
use different operations on it's output, like --dump, --list or
--pretend (or something completely unrelated). It's designed to be
flexible and to be used in scripts and not to be the most convinient
thing in the world. Hope that clears things up a little.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
Attachment:
pgpfwrgCNyp0W.pgp (PGP signature)
References:
Kernels and GLSAs
-- Calum
Re: Kernels and GLSAs
-- Brian G. Peterson
Re: Kernels and GLSAs
-- Marius Mauch
Re: Kernels and GLSAs
-- Brian G. Peterson
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Kernels and GLSAs
Next by thread:
Re: Kernels and GLSAs
Previous by date:
Re: Kernels and GLSAs
Next by date:
Re: Kernels and GLSAs


Updated Jun 17, 2009

Summary: Archive of the gentoo-security mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.