radical suggestion for fc4 release
Jeff Johnson
n3npq at nc.rr.com
Tue Feb 1 16:41:26 UTC 2005
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
More information about the fedora-devel-list
mailing list