Mailing List Archive

On Tuesday 20 September 2005 06:09 am, Calum wrote:
> I prefer the idea that tracking one source (GLSAs) would provide me with
> all the information I needed to keep my Gentoo boxes secure, but if we
> were all to change to a new system, perhaps the kernel GLSAs should have
> overlapped with this new system until it was in, tested, and adopted?

While I think that kernels do need additional information to be supplied about
a potential security hole (kernel security problems often occur in a module
that many people may not use), I agree that kernel vulnerabilities should be
published as GLSAs.

I subscribe to the GLSA RSS feed, and scan that feed manually against my
installed software list. 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.

This document here:
http://www.gentoo.org/proj/en/portage/glsa-integration.xml
talks about including glsa support directly in portage, which I think is the
right idea. It mentions kerlnels as covered by glsa-check.

In the end, I will be happy with any tool (preferably emerge and/or equery)
that can check a running system's installed packages and tell me what GLSAs
apply to that system.

Regards,

- Brian

--
gentoo-security@gentoo.org mailing list

Is there a bug number that references this? The older 0.2.0 works OK.
Despite the big warning that this is experimental, the fact that it
works reasonably well makes it indispensable for those who are trying to
run reasonably secure systems - what other distro offers similar
functionality? One place/utility for this was a great idea!

I saw the kernel stuff and still think this approach is short sighted,
and potentially leaves users exposed.

BillK


On Tue, 2005-09-20 at 07:16 -0500, Brian G. Peterson wrote:
> On Tuesday 20 September 2005 06:09 am, Calum wrote:
> > I prefer the idea that tracking one source (GLSAs) would provide me with

--
gentoo-security@gentoo.org mailing list

On Tue, 20 Sep 2005 07:16:36 -0500
"Brian G. Peterson" <brian@braverock.com> wrote:

> On Tuesday 20 September 2005 06:09 am, Calum wrote:
> > I prefer the idea that tracking one source (GLSAs) would provide me
> > with all the information I needed to keep my Gentoo boxes secure,
> > but if we were all to change to a new system, perhaps the kernel
> > GLSAs should have overlapped with this new system until it was in,
> > tested, and adopted?
>
> While I think that kernels do need additional information to be
> supplied about a potential security hole (kernel security problems
> often occur in a module that many people may not use), I agree that
> kernel vulnerabilities should be published as GLSAs.
>
> I subscribe to the GLSA RSS feed, and scan that feed manually against
> my installed software list. 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.

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.

Brian G. Peterson wrote:

> I subscribe to the GLSA RSS feed, and scan that feed manually against my
> installed software list. 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.

I run glsa-check -l | grep '\[N\]' in a cron, and have the results
emailed to me at a central email address.

I thought this was a very good solution, until I found out that I'd been
missing kernel errata. :(

I think the new KISS system sounds brilliant - it's just the absence of
any notification about the loss of kernel GLSAs that is the problem.
--
gentoo-security@gentoo.org mailing list

Marius Mauch wrote:
> On Tue, 20 Sep 2005 07:16:36 -0500
> "Brian G. Peterson" <brian@braverock.com> wrote:
>
>>I subscribe to the GLSA RSS feed, and scan that feed manually against
>>my installed software list. 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.
>

I don't have any problems with the glsa-check program, I think you are
just forgetting to use the --test mode. I would have liked a way to get
the title of the program printed out along with the GLSA advisory #, so
I wrote a very simple shell script to do just that:

Steve

#! /bin/bash
# Script written by Steven Davis (sgdavis@bioneos.com)
# Created on: April 13, 2005
# Description: Very simple shell script that uses glsa-check
# in --test mode and then translates the GLSA # into an
# actual program title. It isn't perfect but it works,
# No warranty implied :)
#
for i in `glsa-check -t all`;
do
if [ -e /usr/portage/metadata/glsa/glsa-$i.xml ]
then
echo $i; cat /usr/portage/metadata/glsa/glsa-$i.xml | grep title;
fi
done
--
gentoo-security@gentoo.org mailing list

W.Kenworthy wrote:

>Is there a bug number that references this? The older 0.2.0 works OK.
>Despite the big warning that this is experimental, the fact that it
>works reasonably well makes it indispensable for those who are trying to
>run reasonably secure systems - what other distro offers similar
>functionality? One place/utility for this was a great idea!
>
>I saw the kernel stuff and still think this approach is short sighted,
>and potentially leaves users exposed.
>
>BillK
>
>
>
Does anyone have a link to the no kernel GLSA news?
FYI I use "glsa-check -t new" and it works great for me.

>On Tue, 2005-09-20 at 07:16 -0500, Brian G. Peterson wrote:
>
>
>>On Tuesday 20 September 2005 06:09 am, Calum wrote:
>>
>>
>>>I prefer the idea that tracking one source (GLSAs) would provide me with
>>>
>>>
>
>
>

--
gentoo-security@gentoo.org mailing list

on 2005-09-20 15:17 Steven G Davis wrote the following:
> I don't have any problems with the glsa-check program, I think you are
> just forgetting to use the --test mode. I would have liked a way to get
> the title of the program printed out along with the GLSA advisory #, so
> I wrote a very simple shell script to do just that:

I do
$ glsa-check -p `glsa-check -t all`

Works nicely.

Cheers
Tobias

--
GPG-Key 0xEF37FF28 - 1024/4096 DSA/ELG-E - 16.11.2001
Fingerprint: 3C4B 155F 2621 CEAF D3A6 0CCB 937C 9597 EF37 FF28

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.

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:
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.

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.

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.

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?

Thanks for asking. :)

Regards,

- Brian

--
gentoo-security@gentoo.org mailing list

Alec Warner wrote:

> Does anyone have a link to the no kernel GLSA news?

No link, I'm afraid. But here is an excerpt from the email I received:

"Thing is, we don't do Kernel GLSAs anymore : by the time all the kernel
sources in Portage get fixed, months had passed and the issue was
forgotten/exploited already.

It's in the process of being remplaced by an Kernel Interactive Security
Status system (called KISS) that will help assess the current
vulnerabilities of your running kernel and help you chose when to
upgrade, along with specific "vulnerability alerts" telling people that
new big vulnerabilities have been found and to look into KISS for
information on fixed kernels. Exploitable Local Root vulnerabilities
would certainly trigger such an alert.

For the moment, the best way to get informed is to monitor the "Kernel"
component of the "Gentoo Security" product. Now that summer time and
2005.1 are over, I expect that KISS will be opened soon."


This isn't finger pointing, or anything like that at all. Gentoo is the
best distro for me, and that's why I use it, and everyone working on it
does a great job. It's just that I relied on the GLSAs, and never heard
anything to say that they weren't doing kernel GLSAs any more.

Calum

--
gpg : FC64 140F@wwwkeys.eu.pgp.net
jabber: calum@im.wirefree.org
--
gentoo-security@gentoo.org mailing list

Not strictly correct - "glsa-check --list" does tell you if the system
is vulnerable: it highlights the entry in red, and sets [N] for the
entry. --test is just a shortcut that allows individual tests, or with
"all" lists only those that fail the test. --list|grep "\[N" is
actually better as it includes the description as well.

BillK


On Tue, 2005-09-20 at 08:53 -0500, Brian G. Peterson 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

...

> > 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.
>

--
gentoo-security@gentoo.org mailing list

I just use this one liner:

glsa-check --list 2> /dev/null | grep '\[N\]'

and manually merge the packages listed each morning when I get to
work. Takes no time at all.

On 9/20/05, W.Kenworthy <billk@iinet.net.au> wrote:
> Not strictly correct - "glsa-check --list" does tell you if the system
> is vulnerable: it highlights the entry in red, and sets [N] for the
> entry. --test is just a shortcut that allows individual tests, or with
> "all" lists only those that fail the test. --list|grep "\[N" is
> actually better as it includes the description as well.
>
> BillK
>
>
> On Tue, 2005-09-20 at 08:53 -0500, Brian G. Peterson 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
>
> ...
>
> > > 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.
> >
>
> --
> gentoo-security@gentoo.org mailing list
>
>

--
gentoo-security@gentoo.org mailing list

Brian G. Peterson wrote:

> On Tuesday 20 September 2005 06:09 am, Calum wrote:
>
>>I prefer the idea that tracking one source (GLSAs) would provide me with
>>all the information I needed to keep my Gentoo boxes secure, but if we
>>were all to change to a new system, perhaps the kernel GLSAs should have
>>overlapped with this new system until it was in, tested, and adopted?
>
> While I think that kernels do need additional information to be supplied about
> a potential security hole (kernel security problems often occur in a module
> that many people may not use), I agree that kernel vulnerabilities should be
> published as GLSAs.

We used to do GLSAs about kernel issues but then we faced major
problems. The main one was that we issue GLSAs when vulnerabilities are
fixed in the tree, to tell people to upgrade to a fixed package. But if
we wait until all kernel sources are fixed in Portage, the GLSA wasn't
out for months after the vulnerability was disclosed. Secondary problems
were due to the fact that kernel issues were piling up in the meantime,
so when you do issue a GLSA, it didn't cover the recent vulnerabilities
but just told about some that were fixed months ago. So we kept on
pushing back the GLSA release date... It just wasn't a solution.

We tried to produce GLSA with shorter release time (like ignore the
sources that weren't security-reactive) but that meant like a kernel
GLSA per week because Local DoS issues are found all the time. You just
couldn't upgrade the kernel and reboot every time a GLSA like this would
go out. We needed a system that would help you make the right decisions
of when to upgrade your kernel (and which kernel to use) rather than
encourage people to reboot as much as Windows users.

About glsa-check integration, it's not a solution either. glsa-check
checks currently installed packages, not the running kernel. If you
removed the affected sources package, it would tell you you aren't
affected, while you were. If you follow the glsa-check instructions and
emerge the "fixed" sources, it would tell you you're affected until you
remove the affected sources package, and doesn't care if you really
compiled a kernel with the fixed sources...

So we realized kernel security is an ongoing process that needs ongoing
security information rather than point releases. The KISS system is
up-to-date with vulnerabilities rather than with fixes, meaning you get
to know which vulnerabilities affect you with your currently-running
kernel. Then you can make an informed decision of when you should
upgrade (when enough vulnerabilities you care about have been fixed),
and to what sources version you should upgrade. The system lets you
ignore the things that don't matter to you (personal workstations do not
care much about Local DoS vulnerabilities).

This ongoing kernel security information, along with kernel security
alerts when really big things are discovered (Local Root that would work
on most configurations, for example) was for us the best solution. KISS
is almost ready for BETA release, meaning you should be able to access
it very soon for testing.

Also KISS was no secret, it's in the Security project objectives for
year 2005, as published on this list at the beginning of the year.

Thanks for your attention.

--
Thierry Carrez (Koon)
Operational Manager, Gentoo Linux Security
--
gentoo-security@gentoo.org mailing list

On Tue, 20 Sep 2005 08:53:18 -0500
"Brian G. Peterson" <brian@braverock.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.

On Tuesday 20 September 2005 16:44, Thierry Carrez wrote:
> We used to do GLSAs about kernel issues but then we faced major
> problems. The main one was that we issue GLSAs when vulnerabilities are
> fixed in the tree, to tell people to upgrade to a fixed package. But if
> we wait until all kernel sources are fixed in Portage, the GLSA wasn't
> out for months after the vulnerability was disclosed. Secondary problems
> were due to the fact that kernel issues were piling up in the meantime,
> so when you do issue a GLSA, it didn't cover the recent vulnerabilities
> but just told about some that were fixed months ago. So we kept on
> pushing back the GLSA release date... It just wasn't a solution.

This is indeed a problem. But the user expects a single point of information
about vulnerabilities from a distribution - and he's absolutely right to do
so. KISS is fine, but only as additional source. Please don't see the
following as flaming, but: So for some reason we can't fix kernel issues in
time or at least not on all architectures - then it's probably better to send
out a GLSA that we drop these architectures security-wise or that we have
problems with fixing kernel vulnerabilities, noting them and ask people to
stop using distinct kernels or Gentoo at all in the worst case as long as we
cannot react in acceptabe time.


Carsten

Carsten Lohrke wrote:

> This is indeed a problem. But the user expects a single point of information
> about vulnerabilities from a distribution - and he's absolutely right to do
> so.

No, the user expects a single information channel. If we release Kernel
alerts (GLKAs) in the same media as GLSAs (gentoo-announce, forums and
RSS feed) he will get both. We can even name them "GLSAs" if that makes
you feel better. They just won't have the same contents and won't be
used by the same tools (see my explanation about glsa-check dealing with
installed packages rather than with currently used kernel).

> KISS is fine, but only as additional source. Please don't see the
> following as flaming, but: So for some reason we can't fix kernel issues in
> time or at least not on all architectures - then it's probably better to send
> out a GLSA that we drop these architectures security-wise or that we have
> problems with fixing kernel vulnerabilities, noting them and ask people to
> stop using distinct kernels or Gentoo at all in the worst case as long as we
> cannot react in acceptabe time.

Thing is, we can't fix all kernel issues in time for *any* source. By
listing vulnerabilities rather than fixes, we :

1- give accurate information about kernel security status to our users,
better than any distribution
2- show which sources get fixed and which don't, creating emulation
between kernel source maintainers
3- leave the choice to the user as to when he wants to upgrade his
kernel, rather than force him to upgrade every week for some Local DoS
that doesn't even affect him.

We tried the old system, it just doesn't work. It may be a manpower or
an organization thing, so you're free to come and take kernel security
into your own hands if you feel you can do better than us. Kernel
security is even more difficult to handle than Portage security : you
will see that you don't get much user support (they don't enter bugs
about kernel vulnerabilities at all) and will have to deal with
reluctant kernel maintainers (they batch patches to keep the work
manageable, and rightly so).

How do other distributions fix this ? Debian doesn't do much kernel
DSAs, Ubuntu/RedHat issue a kernel per month and have a dedicated (paid)
one-source kernel security team. We chose to keep Gentoo choices
(multiple sources with security information on them), innovate and
propose more information to our users.

Just wait and see how it works rather than saying it's insufficient.

--
Koon
--
gentoo-security@gentoo.org mailing list

On Tuesday 20 September 2005 18:15, Thierry Carrez wrote:
> Carsten Lohrke wrote:
> > This is indeed a problem. But the user expects a single point of
> > information about vulnerabilities from a distribution - and he's
> > absolutely right to do so.
>
> No, the user expects a single information channel. If we release Kernel
> alerts (GLKAs) in the same media as GLSAs (gentoo-announce, forums and
> RSS feed) he will get both. We can even name them "GLSAs" if that makes
> you feel better. They just won't have the same contents and won't be
> used by the same tools (see my explanation about glsa-check dealing with
> installed packages rather than with currently used kernel).

I think you got me wrong here, I meant absolutely the same as you. The point
is I never saw any GLKA and no GLSA regarding kernel issues for quite a while
and while I do not follow the kernel development closely and kiss.gentoo.org
results in 404 since some time, I'm pretty sure there is quite a number of
open vulnerabilities - at least in the latest stable 2.4.x kernel.

> Thing is, we can't fix all kernel issues in time for *any* source. By
> listing vulnerabilities rather than fixes, we :

What's the reason? The kernel is of course a bit more critical than Does the
kernel herd need more time fixing and testing, do the arch herds need more
time testing, lack of man power?


Carsten

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thierry Carrez wrote:
> Brian G. Peterson wrote:
>
>
>>On Tuesday 20 September 2005 06:09 am, Calum wrote:
>>
>>
> This ongoing kernel security information, along with kernel security
> alerts when really big things are discovered (Local Root that would work
> on most configurations, for example) was for us the best solution. KISS
> is almost ready for BETA release, meaning you should be able to access
> it very soon for testing.
>
> Also KISS was no secret, it's in the Security project objectives for
> year 2005, as published on this list at the beginning of the year.
>
> Thanks for your attention.
>
<snip snip>

I am in support of whatever you decide, but I would expect there to be
documentation somewhere stating current policy ( that being that kernel
security bugs are not made into GLSA's ). Knowing this I can work
around it and find other ways to keep my kernel updated. However no one
wants to be under the false pretense that GLSA's cover all security
problems and then get nailed by a kernel security issue.

I don't see anything about the security seciton of gentoo's website
detailing that kernel security issues aren't in GLSA's and I think it
would be helpful to include that. It may even be helpful to add it to
the post_inst of gentoolkit/glsa-check's manpage. Right now if I read
the security handbook or the GLSA documentation I am misinformed.

If you are indeed switching to a system that works better I think many
would enjoy an upgrade of docs, or issuing GLSA's until you have KISS
running, or just documentation that says kernel security bugs are not
covered by GLSA's.

If you want a bug filed, I can do that as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQzDfHGzglR5RwbyYAQL5+w/+LTaohDpFWqguv98wkMXEl+ZwsQZNeSJt
WOV+X9HAqa+l/dvU0noCd0CvjKBCiYsmbzXHBiGvAmu3HYrdUGCejSC9pnVLRLlC
JkNRklehGGEzKBXNgPYrMnlq0ybF8UjFcTgkXIycG9ucJbCwD0hyotwRI1kGe3sM
Tuq1TqBjeZGNPfCymREqv6Pn9OlDWNVzXSQ9xnin0/xscVvQbUw8dAx4AgoTL4Jo
ltzNU89KMyeEALgy4W0ctE4v/tIbrPY+Ye/Ypd8AYO6JW5LBnik2njc3KArybzsp
2BOhBKMPC4mh3BLr2IP3kJzavtEOjvME/9DkqSuuDB09SexaGmiZSnCFkRG5XSs7
GQPVzsFxfW2c913FZ0I4Nij3jwK7PcGxOCUHhAirLd1VHizoFYBcHJxK1ldACUR0
dtSuc/2yAg1bMBkHvJhDS4MDEdIchqmvBsCD9YxjpZ+vulMdUDigP1jokiuqlLRp
y2rBGXfFJxCVywjvmJ67V45Rxh83QG75TaIP7LAb19pJH71lVbt1RqmvikIZuFHv
Te5cJ6HW5egWrjIMLKCp9ZpZrXpRCZXHxVoNwqUcI1QI+uTbKuBh/4DLsKFPjAvU
hWgvuIOxIaH3E2fHNoaaUbO90qeq8pmRFkUNHAc3TPIA6zcYwS/mne8PvFvq12rJ
8TPPR7XO2L0=
=hxQ6
-----END PGP SIGNATURE-----
--
gentoo-security@gentoo.org mailing list

Calum writes:
|
| Brian G. Peterson wrote:
|
| > I subscribe to the GLSA RSS feed, and scan that feed manually against my
| > installed software list. 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.
|
| I run glsa-check -l | grep '\[N\]' in a cron, and have the results
| emailed to me at a central email address.

Time for me to make a fool of myself ;). Ive been running


| emerge -uD world -pv


to look for updates and I was a little surprised at the following....



| # emerge -uD world -pv
|
| These are the packages that I would merge, in order:
|
| Calculating world dependencies ...done!
| [ebuild U ] sys-devel/libperl-5.8.7 [5.8.6-r1] +berkdb -debug +gdbm -ithreads 9,608 kB
| [ebuild U ] dev-lang/perl-5.8.7-r1 [5.8.6-r5] +berkdb -build -debug -doc +gdbm -ithreads -minimal -perlsuid 0 kB
|
| Total size of downloads: 9,608 kB


Which doesnt list.......


| # glsa-check -l |& grep '\[N\]'
| [N] indicates that the system might be affected.
| 200507-16 [N] dhcpcd: Denial of Service vulnerability ( net-misc/dhcpcd )


but if I check the package by directly it does need an update (and
quite badly it seems)...


| # emerge -pv dhcpcd
|
| These are the packages that I would merge, in order:
|
| Calculating dependencies ...done!
| [ebuild U ] net-misc/dhcpcd-2.0.0 [1.3.22_p4-r5] -build -debug -static 119 kB
|
| Total size of downloads: 119 kB



Huh? Have I just foolishly assumed that emerge world checks all packages?
Is there some 'better' way to list all packages that need updates
both security and normal (and I missed it)?

I thought it might just have been me (running ppc64), but I notice my
friends intel box has exactly the same problem, right down to the same
version of dhcpcd.

Ok, I just checked the security handbook and it only mentions
glsa-check. Ok, its probably my bad... but shouldnt emerge world
merge security updates too?


cheers,
cam


--
/ `Rev Dr' cam at darkqueen.org Roleplaying, virtual goth \
< http://darkqueen.org Poly, *nix, Python, C/C++, genetics, ATM >
\ [+61 3] 9809 1523[h] skeptic, Evil GM(tm). Sysadmin for hire /
---------- Random Quote ----------
Excellent day for drinking heavily. Spike the office water cooler.
--
gentoo-security@gentoo.org mailing list

Cameron Blackwood wrote:
> Huh? Have I just foolishly assumed that emerge world checks all packages?
> Is there some 'better' way to list all packages that need updates
> both security and normal (and I missed it)?
>
> I thought it might just have been me (running ppc64), but I notice my
> friends intel box has exactly the same problem, right down to the same
> version of dhcpcd.
>
> Ok, I just checked the security handbook and it only mentions
> glsa-check. Ok, its probably my bad... but shouldnt emerge world
> merge security updates too?

"world" is only the contents of /var/lib/portage/world and their (deep
if using --deep) dependencies. Integration of glsa-check in the form of
"emerge --security" or some such is planned. An "all" target is also
planned.

--
Jason Stubbs
--
gentoo-security@gentoo.org mailing list

On Thu, Sep 22, 2005 at 11:39:55AM +1000, Cameron Blackwood wrote:
> Time for me to make a fool of myself ;). Ive been running
>
>
> | emerge -uD world -pv
>
>
> to look for updates and I was a little surprised at the following....
>
> | # emerge -uD world -pv
> |
> | These are the packages that I would merge, in order:
> |
> | Calculating world dependencies ...done!
> | [ebuild U ] sys-devel/libperl-5.8.7 [5.8.6-r1] +berkdb -debug +gdbm -ithreads 9,608 kB
> | [ebuild U ] dev-lang/perl-5.8.7-r1 [5.8.6-r5] +berkdb -build -debug -doc +gdbm -ithreads -minimal -perlsuid 0 kB
> |
> | Total size of downloads: 9,608 kB
>
>
> Which doesnt list.......
>
>
> | # glsa-check -l |& grep '\[N\]'
> | [N] indicates that the system might be affected.
> | 200507-16 [N] dhcpcd: Denial of Service vulnerability ( net-misc/dhcpcd )
>
>
> Huh? Have I just foolishly assumed that emerge world checks all packages?
> Is there some 'better' way to list all packages that need updates
> both security and normal (and I missed it)?

dhcpcd was recently (couple months back) removed from "system". If you
installed your system before then, dhcpcd would not have been recorded
in the world file since it was part of system, which is included in
the packages checked when you do emerge -uD world.

After it has been removed from system, unless you added it to world
yourself, none of the emerge -uD world operations would have updated
dhcpcd, and so dhcpcd, never passing through emerge since its removal
from system, never was added to the world file. So now emerge -uD
world doesn't know it is on your system.

W

--
News headline:
The man who fell into an upholstery machine was fully recovered.
Sortir en Pantoufles: up 41 days, 5:18
--
gentoo-security@gentoo.org mailing list

Jason Stubbs writes:
|
| "world" is only the contents of /var/lib/portage/world and their (deep
| if using --deep) dependencies. Integration of glsa-check in the form of
| "emerge --security" or some such is planned. An "all" target is also
| planned.


Thanks for the reply... its 100% my bad. :)

But i did open a bugzilla issue suggesting that it be explicitly
mentioned in the 'keeping up todate' section of the security doc.

Im sure its a mistake that other people are making too and if you
know about it, its easy enough to add to a nightly cron. :)


| Jason Stubbs
cheers and thanks,
cam

--
/ `Rev Dr' cam at darkqueen.org Roleplaying, virtual goth \
< http://darkqueen.org Poly, *nix, Python, C/C++, genetics, ATM >
\ [+61 3] 9809 1523[h] skeptic, Evil GM(tm). Sysadmin for hire /
---------- Random Quote ----------
Nostalgia isn't what it used to be.
--
gentoo-security@gentoo.org mailing list

> > Ok, I just checked the security handbook and it only mentions
> > glsa-check. Ok, its probably my bad... but shouldnt emerge world
> > merge security updates too?
>
> "world" is only the contents of /var/lib/portage/world and their (deep
> if using --deep) dependencies. Integration of glsa-check in the form of
> "emerge --security" or some such is planned. An "all" target is also
> planned.

Running "emerge -pv depclean" should show any packages not covered by
"world" right?

The "all" target sounds like a great idea :)

Cheers,

Brad

--
gentoo-security@gentoo.org mailing list

Brad Plant wrote:
>>>Ok, I just checked the security handbook and it only mentions
>>>glsa-check. Ok, its probably my bad... but shouldnt emerge world
>>>merge security updates too?
>>
>>"world" is only the contents of /var/lib/portage/world and their (deep
>>if using --deep) dependencies. Integration of glsa-check in the form of
>>"emerge --security" or some such is planned. An "all" target is also
>>planned.
>
> Running "emerge -pv depclean" should show any packages not covered by
> "world" right?

Unfortunately, that is *too* correct. Unfortunate in that both
--depclean and --update only consider USE flags defined in make.conf and
package.use (and embedded in .tbz2s when using binaries). This means
that if package "foo" depends on package "bar" due to USE flag "baz"
being enabled at install time and "baz" is subsequently disabled, "bar"
becomes an orphaned package as far as the graph goes - even though it is
still required.

What does this mean in terms of security? The "only install what you
need" rule is twice as important. Until portage is a little smarter, I
would consider a "healthy" system to be one where `emerge -uDNvp world`
shows no differing USE flags and both `emerge -p --depclean` and
`revdep-rebuild -p` show no packages.

--
Jason Stubbs
--
gentoo-security@gentoo.org mailing list

Jason Stubbs writes:
|
| Unfortunately, that is *too* correct. Unfortunate in that both
| --depclean and --update only consider USE flags defined in make.conf and
| package.use (and embedded in .tbz2s when using binaries). This means
| that if package "foo" depends on package "bar" due to USE flag "baz"
| being enabled at install time and "baz" is subsequently disabled, "bar"
| becomes an orphaned package as far as the graph goes - even though it is
| still required.
|
| What does this mean in terms of security? The "only install what you
| need" rule is twice as important. Until portage is a little smarter, I
| would consider a "healthy" system to be one where `emerge -uDNvp world`
| shows no differing USE flags and both `emerge -p --depclean` and
| `revdep-rebuild -p` show no packages.
|


eeek! depclean wants to remove portmap and screen and all this other
stuff I need. Ah, because it isnt in /var/lib/portage/world I
guess... it seems Ive overestimated emerge's work.


Ok, so just to get this _totally_ clear, I should:


* manally place package names I need in /var/lib/portage/world

* check my install with
emerge sync
emerge -uDNpv world
revdep-rebuild -p
glsa-check -l |& grep '\[N\]'

* update any packages listed by those last 3 commands


Maybe Im just too lazy, but there must be a set of 'best' commands
to update/check a system documented/written down somewhere? Hopefully
in a possibly automated way. If there isnt, then lets try and cobble
one together. :)


Ah, the simple days when I'd get a list of packages I wanted to keep,
remove them from an rpm -qa and then keep trying to remove every
package left until there was no change (and depend on dependancy
trees to keep stuff that I need). :)


cheers,
cam


--
/ `Rev Dr' cam at darkqueen.org Roleplaying, virtual goth \
< http://darkqueen.org Poly, *nix, Python, C/C++, genetics, ATM >
\ [+61 3] 9809 1523[h] skeptic, Evil GM(tm). Sysadmin for hire /
---------- Random Quote ----------
Rev. Jim: What does an amber light mean?
Bobby: Slow down.
Rev. Jim: What... does... an... amber... light... mean?
Bobby: Slow down.
Rev. Jim: What.... does.... an.... amber.... light....
--
gentoo-security@gentoo.org mailing list