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