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.
>> could require all the CVE's that are ciritical to be fixed yum
>> update fedora-secure-system would then only pull security updates
> 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
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
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