Recently I told glsa-check to fix the recent vulnerability in apache-1.3 and detached the screen. To my surprise, later I've found out, that it has emerged me apache-2. It seems that glsa-check doesn't respect slots when fixing (I suppose it doesn't do that also when it performs the tests, but I didn't check that).
hmm, works correctly here :-/ We're talking about 200405-22, right ?
That's the one. The version of gentoolkit I use is 0.2.0_pre8. I use only apache-1, not apache-2... maybe you have apache-2 emerged and that somehow hid the bug? No idea what made it not work correctly here... and unfortunately I don't have much time to dig into the source right now.
*** Bug 57133 has been marked as a duplicate of this bug. ***
Can you test it with >=0.2.0_pre10?
best would be the just released 0.2.0_rc1
I would, but I can't seem to find a way to trick portage into thinking that apache-1.3.29 is merged. --inject says it's deprecated and editing /etc/make.profile/package.provided has no visible effect. Is it broken or am I not using it right? Granted, I could really emerge an old apache just to test this bug, but I'd rather not. And I'm not into digging GLSAs for another advisory exposing this problem.
The automake vulnerability also had multislot. What glsa-check did for me, was each time I ran it, it picked a slot containing a "vulnerable" version and updated it, in-slot, to a version selected by glsa-check (not the latest unmasked revision, not the latest version ?!?!?) It was going to re-emerge the same version into every slot! I finally just ran emerge -C '<automake-1.9' which may break some things, but I'll redownload them as things complain and hopefully the security fixes will have been backported.
*** Bug 88483 has been marked as a duplicate of this bug. ***
hmm, almost forgot about this. automake was IIRC due to a buggy/old GLSA. This should be working in the current version.
