I think we talked at cross-purposes, Jeff.

My talk was on a very high level and with "VuXML ... is NOT a database" I meant
there is no content available describing security issues - nobody maintains a
data collection which we can use for the whole RPM world! It is my
understanding you already talked about the implementation - way too fast for me
:-) So please shift down gear and let me explain the two options regarding my
last posting.

n3npq@mac.com wrote on 2007-05Q-28 00:39:
> On May 27, 2007, at 6:23 PM, Thomas Lotterer wrote:
> 
>> Yes, if you stick with *specific* databases.

With "*specific* database" I meant an approach where someone creates a
vulnerability data collection for your yet to be implemented "rpm
-securityquery" code. This is somewhat easy to implement on the RPM side and
requires to query only one data source - let it be remote or local after
downloading a copy of the whole thing or excerpts, that's an implementation
issue. However, because the data collection must carry very exact name-EVR (oh,
not again that issue ;-) information, someone must take on the burden of
maintaining it. And because of the required preciseness of name-EVR it is
unlikely that diverse distros can share that information. Also, it is likely
that only the distro itself will take care and if he is lazy about issuing new
data then the "rpm -securityquery" becomes largely inaccurate and useless.

>> No or only a starting point otherwise.
>
That "otherwise" was my idea of allowing maintenance of a single vulnerability
data collection which is fed by multiple distros. Even if there is no agreement
between them, multiple those data collections may exist and compete with each
other, giving the "rpm -securityquery" user a choice. However, such a commonly
used data source will face the challenge of inaccuracy because it can list
name-V at best and must leave out ER which is up to the distro. The more I
think about it this approach is nonsense because even the name is not
necessarily the same across distros. Anyway, to complete the paragraph, if that
would have been an option then the distros would need to maintain an amendment
database to override the generic database with their specific stuff like "we
have a fix" and "we are not affected".

Very disappointing for me is that data collections specific to a distro cause
lots of duplicate work but a generic data collections seems to be impossible to
achieve. My head's smoking :-| Maybe the package name is not a good reference
point to discuss upstream vulnerabilities. A better key must be found,
something tied to upstream. Like the name of the affected tarball. Ah. The
binary RPM has no idea from which tarball it has been built. Dejavu. I give up
for today.

Killjoy is my karma. 

-- 
http://thomas.lotterer.net