The distinction between applied and unapplied GLSAs isn't that useful, since fixing a GLSA is equivalent to an emerge (so those who regularly emerge -uDNav world won't have many GLSAs listed as "applied"). Fortunately, the contents of CHECKFILE (/var/cache/edb/glsa) only affect display and the "new" list (todolist in /usr/bin/glsa-check). There is, however, a comment ("# maybe this should be todolist instead") which overlooks the fact that using todolist instead of checklist won't save much time, but will potentially ignore some security updates. This means that, for now, glsa-check --list affected works properly, except for displaying applied-but-affected GLSAs in white instead of red. There's a trivial fix to make them show up as [A][N] which gets the colour right (of course, that would only make sense if "N" was changed to "V"), but I think it'd be more useful to drop the distinction between applied and unapplied GLSAs. To reproduce: 1. Install GLSA 200801-09 before it was updated (see bug 204362 comment 36, which probably won't show up correctly). 2. emerge --sync 3. glsa-check --list affected Alternatively, if the GLSA was already updated, you can simulate it with "emerge =libXfont-1.3.1". (I did 1b. "emerge libXfont" and 1c, "emerge =libXfont-1.3.1", but we can assume that's a noop.) # @na>> glsa-check --list affected [A] means this GLSA was already applied, [U] means the system is not affected and [N] indicates that the system might be affected. 200801-09 [A] X.Org X server and Xfont library: Multiple vulnerabilities ( x11-libs/libXfont x11-base/xorg-server )
Well, the main reason for the "applied" state is that a security issue can be fixed manually by the admin without updating the package (e.g. by disabling features in the configuration), and the admin doesn't want to have the GLSA in the "affected" set all the time (this is already changed in svn). The other minor reason is a small performance increase, but that's probably not significant anymore on modern machines. Your problem is that in this particular case a new GLSA should have been issued instead of "fixing" the existing one.
(In reply to comment #1) > Your problem is that in this particular case a new GLSA should have been issued > instead of "fixing" the existing one. Is there some way this can be handled by evaluating the revision (as in, remember which revision of a GLSA was applied, and then use it). There are several ways we update GLSAs: * Package moves, typos -- should not be important when users have marked a GLSA applied. * Changing affected versions -- this also is a problem now, right? Did the GLSA "install" fail for the old revision of the GLSA, where one package was not present? Should it?
(In reply to comment #2) > Is there some way this can be handled by evaluating the revision (as in, > remember which revision of a GLSA was applied, and then use it). If you mean the cvs revision, then no. The <revised> tag might work in theory, but would be rather ugly to use (a numeric, mandatory revision could work though, but that doesn't exist right now) > * Changing affected versions -- this also is a problem now, right? Depends on the exact change: if it's expanding the list of affected version then yes, if it's reducing it no. > Did the GLSA "install" fail for the old revision of the GLSA, where one > package was not present? Should it? It should have at least generated an error (I'm not on a Gentoo system atm, so can't test).
(In reply to comment #3) > The <revised> tag might work in theory, > but would be rather ugly to use (a numeric, mandatory revision could work > though, but that doesn't exist right now) <revised>January 09, 2008: 01</revised> The last digits of that tag is a number that always gets increased on updates. > > Did the GLSA "install" fail for the old revision of the GLSA, where one > > package was not present? Should it? > It should have at least generated an error (I'm not on a Gentoo system atm, so > can't test). Why was the GLSA marked "applied" then?
(In reply to comment #1) > Well, the main reason for the "applied" state is that a security issue can be > fixed manually by the admin without updating the package (e.g. by disabling > features in the configuration), and the admin doesn't want to have the GLSA in > the "affected" set all the time (this is already changed in svn). Then it should be "ignored" and it should not get set automatically - there are plenty of ways to apply (--fix) a GLSA and still be vulnerable; a significant one is bug 106677. Other ones include installing a vulnerable package, which does not necessarily have to be intentional: a user installs foo off a CD by default, but updates to fix a security hole. After removing bar, foo is no longer necessary, but user goes on to install baz (from the CD) which depends on foo. Or user fixes hole in apache 1.3, and upgrades to a vulnerable apache 2. > Your problem is that in this particular case a new GLSA should have been issued > instead of "fixing" the existing one. 1. In security, correctness is more important than efficiency (nobody uses DES). 2. Security is everybody's problem. (In reply to comment #2) > Is there some way this can be handled by evaluating the revision (as in, > remember which revision of a GLSA was applied, and then use it). There is no guarantee that having applied a GLSA in the past means that it is still fixed now. > * Package moves, typos -- should not be important when users have marked a GLSA applied. Equally, the user can unapply the GLSA and still see that the system is not affected. > * Changing affected versions -- this also is a problem now, right? Are GLSAs supposed to be update-once-and-never-change things? > Did the GLSA "install" fail for the old revision of the GLSA, where one package > was not present? Should it? No. And not really: If there is one GLSA for foo and bar, and I've only installed foo, it should still update foo. The *check* should fail, since the GLSA refers to a nonexistent package, which is a blatant error (this would also cover bug 52500).
> (In reply to comment #2) > > * Changing affected versions -- this also is a problem now, right? > > Are GLSAs supposed to be update-once-and-never-change things? No, they can change. Think of package moves, new unaffected versions, typos. > > Did the GLSA "install" fail for the old revision of the GLSA, where one package > > was not present? Should it? > > No. And not really: If there is one GLSA for foo and bar, and I've only > installed foo, it should still update foo. Why was the GLSA marked fixed then? At which step? > The *check* should fail, since the GLSA refers to a nonexistent package, which > is a blatant error (this would also cover bug 52500). I guess bug 52500 is over the scope here, since issues like removed packages are hard to handle.
glsa-check is included with >=sys-apps/portage-2.3.72 (bug 463952).
