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
