If an emerge called by glsa-check fails for any reason (mask, block, compile failure, etc), glsa-check does not continue to the next affected GLSA. If this is being called by a cronjob (which is often the case), this leads to subsequent security issues not being fixed. Ultimately, when glsa-check is ran manually, the problem is discovered with the early GLSA. There is no reason to leave the other vulnerabilities open.
There is no reason to rely on an "experimental" feature of glsa-check for the security of your box. Let'me reassign the bug to its maintainer, with "enhancement" status. Honestly, i would really advise you to manually run your upgrades. Calling a so complex root job by cron is not safe... What would happen if one important package of a server is upgraded while the new version requires a new configuration syntax which is not compatible with the previous (currently installed) one? Think about revdep-rebuild too...
This is a very simple behavior tweak that would greatly improve security for those too busy to shell into a dozen boxes every time there is a new advisory. It is the user's discretion on whether to take the risks associated with automated updates (which other distributions can also perform). Software should not be designed to intentionally make things difficult; an optional flag with the appropriate caveats in the man page is sufficient. (In reply to comment #1) > There is no reason to rely on an "experimental" feature of glsa-check for the > security of your box. Let'me reassign the bug to its maintainer, with > "enhancement" status. > > Honestly, i would really advise you to manually run your upgrades. Calling a so > complex root job by cron is not safe... What would happen if one important > package of a server is upgraded while the new version requires a new > configuration syntax which is not compatible with the previous (currently > installed) one? Think about revdep-rebuild too... >
You can easily do this by using glsa-check inside a loop: for x in $(glsa-check --test new); do glsa-check --fix $x; done I'm not a big fan of letting glsa-check progress further after an error as a) we'd have to track all failed upgrades and list them later so people are aware of them and b) even if we track them the actual error messages would be lost, so solving the problem is amde more difficult.
