|From:||Marius Mauch <firstname.lastname@example.org>|
|Subject:||Re: [gentoo-security] Kernels and GLSAs|
|Date:||Tue, 20 Sep 2005 14:57:32|
|In Reply to:||Re: [gentoo-security] Kernels and GLSAs by "Brian G. Peterson"
On Tue, 20 Sep 2005 08:53:18 -0500 "Brian G. Peterson" <brian@×××××××××.com> 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.