With some GLSAs, glsa-check from gentoolkit-0.2.0_pre10 (portage-2.0.51_rc9) suggests masked versions of packages as a fix. For example: # glsa-check -p 200408-27 Checking GLSA 200408-27 The following updates will be performed for this GLSA: net-im/gaim-1.0.1 (0.63-r1) # emerge -p gaim net-im/gaim-1.0.0 [0.63-r1] --- # glsa-check -p 200410-04 Checking GLSA 200410-04 The following updates will be performed for this GLSA: dev-php/mod_php-5.0.1 (4.3.8) dev-php/php-5.0.0-r1 (4.3.8) # emerge -p mod_php dev-php/mod_php-4.3.9 [4.3.8] dev-php/php-4.3.9 [4.3.8] --- However, for other packages it selects the least unaffected package as expected: # glsa-check -p 200410-02 Checking GLSA 200410-02 The following updates will be performed for this GLSA: media-libs/netpbm-10.11.5-r3 (9.12-r4) # emerge -p netpbm media-libs/netpbm-10.20 [9.12-r4] If that would help, I have a system with 31 affected unapplied GLSAs and may be able to gather some stats on them and respective packages.
My glsa-check also works that way from gentoolkit pre10. Anyone got a solution? After I upgraded to portage 2.0.51 suddenly NO version of glsa-check is working as intended. :( pre8_r1 has the unicode bug and pre10 has this masked packages bug. *bummer*
*** Bug 73537 has been marked as a duplicate of this bug. ***
*** Bug 72917 has been marked as a duplicate of this bug. ***
Bah, I'm stupid. pkgcmp doesn't like strings so the relevant loop went on and glsa-check always used the last version in the list it got from portage.
*** Bug 67494 has been marked as a duplicate of this bug. ***
in 0.2.0_rc1
wouldn't be more reasonable (at least on a production server) to use the next unaffected version instead of te latest for fixing security issues? ex: suppose php-4.3.8 is affected by a security bug and php-4.3.8-r1 fix that, but as there is also php-4.3.9 unmasked in the portage tree, glsa-check will fix the issue installing php-4.3.9 with the risk to break some dependencies (or the eventual introduction of new unknown bugs) instead of installing php-4.3.8-r1 which would imho be safer...
Good point... The thing is glsa-check just shows the version that will get installed if you run the command in the GLSA instructions, which currently look this way : emerge --ask --oneshot --verbose ">=app-portage/mirrorselect-0.89" Currently this installs the most recent version matching security. I think that instructions given in GLSAs, the glsa-check -f results and what glsa-check -t proposes must be coherent. So unless a new option is added to emerge (something like "--minimal") to have it upgrade to the nearest unaffected version and the GLSAs make use of that, I don't think this behaviour should be changed.
sorry if this is a stupid question, but couldn't this be done using emerge --ask --oneshot --verbose "=app-portage/mirrorselect-0.89" instead of emerge --ask --oneshot --verbose ">=app-portage/mirrorselect-0.89" ? maybe adding a "--minimal" option to glsa-check instead to emerge?
Specific versions get removed from the tree. So the command would fail as soon as the specific upgrade version is removed. And we can't update and reissue all GLSAs each time the "nearest secure" version changes...
From what I've seen glsa-check selects versions on its own from those that are available and that match those allowed by glsa. emerge is used only to do the actual merging of specified version (line 238 as in gentoolkit-0.2.0_pre10-r1): exitcode = os.system("emerge ="+pkg). It was this version selection mechanism that caused this bug: glsa would merge even masked versions of packages that directly called emerge would not select. I'm just waiting to test the new version and it's likely it will again be usable :)
The observed behavior was a bug, glsa-check is supposed to select the lowest unaffected version that's higher than the current installed version.
