radical suggestion for fc4 release

[Eli Carter]

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.

Thoughts?

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------



------------------------------------------------------------------------
Confidentiality Notice:   This e-mail transmission may contain
confidential and/or privileged information that is intended only for the
individual or entity named in the e-mail address. If you are not the
intended recipient, you are hereby notified that any disclosure,
copying, distribution or reliance upon the contents of this e-mail
message is strictly prohibited. If you have received this e-mail
transmission in error, please reply to the sender, so that proper
delivery can be arranged, and please delete the message from your
computer.  Thank you.
Tektronix Texas, LLC formerly Inet Technologies, Inc.
------------------------------------------------------------------------