Eli Carter wrote:
Nigel Metheringham wrote:
On Tue, 2005-02-01 at 16:02 +0100, Arjan van de Ven wrote:
On Tue, 2005-02-01 at 09:50 -0500, Jeff Spaleta wrote:
I look forward to building pathological packages that have a requires on a CVE name provides.
fedora-secure-system
could require all the CVE's that are ciritical to be fixed yum update fedora-secure-system would then only pull security updates down....
This sort of requires a way to handle packages that you don't install - for example package flurble needs an empty package not-flurble (which conflicts with flurble) so that when CAN-9999-999 is issued for flurble, which then means fedora-secure-system now requires CAN-9999-999, a new empty not-flurble can also provide the CVE name.
...
This makes my head hurt.
How about fedora-secure-system have Conflicts: flurble <= <vulnerable version> # CAN-9999-999
If a package is known to be vulnerable, it conflicts with a secure system.
Wouldn't that accomplish what you want? It will install in the absence of flurble, but if a vulnerable version is installed, it will (should?) cause an upgrade.
Hmm.... And if there is no upgrade available, maybe a remove... In fact, I kind of like that idea. Update fedora-secure-system immediately upon disclosure of a problem, even in absense of a fix. Sysadmins can decide to uninstall or remain insecure based on whatever their constraints are.
Package metadata is not sufficiently reliable to be trusted to automagically insturment
package choices based on security tags.
Who *exactly* determines the reliability of the tags that are in Conflict:?
On my systems, that answer is: Me and me alone.
73 de Jeff
