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
or
Provides: kernel-abi = 2.6
or
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
packages,
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
Provides:
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
>me...
>
>
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