radical suggestion for fc4 release

Jeff Johnson n3npq at nc.rr.com
Tue Feb 1 15:47:51 UTC 2005

Jeremy Katz wrote:

>On Tue, 2005-02-01 at 09:28 +0000, Mark J Cox wrote:
>>>Changelog entries that refer to specific bug numbers or CAN numbers can 
>>>be quite helpful in this regard.
>>What would be incredibly useful is to move (to being a Provides) the CVE 
>>names for issues that we're including a backported fix for.  Where we've 
>>moved to an upstream version that contains fixes those CVE names are less 
>>important as they can be deduced by a simple NV check.
>This really feels like the wrong place to put this information.  Then,
>if we're not vulnerable for whatever reason, the provides isn't there
>and people think that it is.  So, now we have to do an update to add a
>provides.  And even if we say that newer versions don't need it, people
>will want it because doing a two-step process of "check version, check
>CAN" means they'll only do one step ;)   

Unlike, say
    Provides: shared-library
    Provides: kernel-abi = 2.6
     Provide: LSB
a CAN or CVE marker usually has a patch to package sources.

Since a patch forces a rebuild, adding the Provides: is no additional 
work. Yes,
retrofiiting the scheme will involve arbitrary additions to existing 
but that can't be helped.

What still would be lacking is a hard, well defined, test that, indeed, 
that the
Provides: is accurate.

 In other words, there is the risk of false comfort if onl the Provides:
is checked, any package might supply a false Provides:. So the package
or header signature check is a necessary part of verifying a CAN or CVE 

Distributing the exploit with the Provides: would be one way to insure 
that the
CAN or CVE Provides: could be tested widely (but distributing exploits 
has other issues
of course ;-)

>This just feels like metadata that doesn't belong in the package to
I'd say that a CAN/CVE marker belongs in a package because it is indicating
that the package includeds the appropriate and approved patch.

Any other scheme to attach meta-metadata with a package will be harder 
to vet and maintain.

73 de Jeff

More information about the fedora-devel-list mailing list