Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 606136 - Support differentiating GLSA notifications that have an upgrade path from those that don't in GLSA checking tools
Summary: Support differentiating GLSA notifications that have an upgrade path from tho...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Portage team
Depends on: 463952
  Show dependency tree
Reported: 2017-01-18 00:54 UTC by Mart Raudsepp
Modified: 2019-08-19 05:51 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Mart Raudsepp gentoo-dev 2017-01-18 00:54:30 UTC
Once gentoolkit and portage use an unified module (probably portage.glsa), we can start adding features without constant copy-pasting stuff to both places or add features to the frontends :)
To that effect, here's a request to all the tools, which may or may not be nicer to do for the different frontends (glsa-check/portage sets/future emaint module) by adding some common helping code in the glsa module:

Have the possibility to differentiate affected packages based on whether they have an upgrade path or not. Then the tools would have separation too, e.g @security-upgrade set and @security-vulnerable set.
This would allow to first check for upgrades that can be done (have an unaffected version in the given SLOT "visible" thanks to being on ~arch or the systems architecture having stabled it already), and then optionally worry about what to do about known vulnerabilities that don't have a clean upgrade path yet.
Currently this would be useful for security unsupported architectures, e.g some user with a slower machine running ~arch (for sake of example, lets say a low core, low clock, low memory Aarch64 ~arm64) could prioritize security upgrades first, thanks to GLSA being available thanks to security supported architectures having stabled it already, but not get bothered for cases where it isn't visible yet (in this example, a stable arm64 machine, as it has that for @system, but lagging behind on a best-effort basis as of right now). Then once these upgrades are done, the user can consider checking what security vulnerabilities are known that don't have an upgrade path thanks to the other option (@security-vulnerable in case of portage set example), and act accordingly - let portage save a package.accept_keywords config protect, disable relevant service, uninstall the vulnerability or whatever is found best.

Later on the same kind of code could be used to implement my proposal, to use this on a more wide scale, if it were ever concretely accepted; or even if it isn't, the alternative is to trim the security supported architectures to a minimum, in which case this feature would become useful for all the architectures that lose the official status. Proposal thread first post in URL field.