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