[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Machine-readable form for debian security advisories



On Thu, 12 Aug 2004 03:38 pm, Lupe Christoph wrote:
> On Thursday, 2004-08-12 at 14:26:44 +1000, Joshua Goodall wrote:
> > Therefore I see a need for a machine readable DSA format. I know
> > there's a defined format to the current header, but I'd like to
> > expand on that.
> >
> > It will look something like:
>
> Please do not invent yet anoither format if you can avoid it. You
> don't mention VuXML (http://www.vuxml.org/), so I suppose you did not
> know it. Please have a look there.

As I understand it, VuXML has a slightly different semantic. It 
expresses that specified binary package versions will have a certain 
vulnerability and implies they should be deinstalled or upgraded to 
some version for which the vulnerability does not exist. The DSA series 
always gives "less than" information and states you must upgrade to the 
version listed.

VuXML also lacks metadata fields for specifying architecture limitations 
or restriction to different distributions of the system. They are 
required because the Debian security team generally backports fixes and 
thereby creates their own branch of the package. VuXML only 
distinguishes distributions using the <system> element, which is a 
sibling of the <package> element. That structure is correct for the 
*BSDs but not for Debian.

e.g. I will probably use an extension of the vocabulary:

--- vuxml-model-11.mod.orig     2004-04-03 01:29:56.000000000 +1000
+++ vuxml-model-11.mod  2004-08-12 17:21:11.000000000 +1000
@@ -57,6 +57,8 @@
 <!ENTITY % vuxml.system.qname "%vuxml.pfx;system" >
 <!ENTITY % vuxml.name.qname "%vuxml.pfx;name" >
 <!ENTITY % vuxml.range.qname "%vuxml.pfx;range" >
+<!ENTITY % vuxml.distribution.qname "%vuxml.pfx;distribution" >
+<!ENTITY % vuxml.architecture.qname "%vuxml.pfx;architecture" >
 <!ENTITY % vuxml.lt.qname "%vuxml.pfx;lt" >
 <!ENTITY % vuxml.le.qname "%vuxml.pfx;le" >
 <!ENTITY % vuxml.gt.qname "%vuxml.pfx;gt" >
@@ -197,6 +199,8 @@
 
 <!ELEMENT %vuxml.package.qname;
         ( ( %vuxml.name.qname; )+,
+          ( %vuxml.distribution.qname; )?,
+          ( %vuxml.architecture.qname; )+,
           ( %vuxml.range.qname; )+ )
 >
 <!ATTLIST %vuxml.package.qname; %vuxml.Common.attrib; >

(untested, but you get the idea)

to produce

<affects>
  <package>
    <distribution>stable</distribution>
    <architecture>i386</architecture>
    <architecture>arm</architecture>
    <architecture>ia64</architecture>
    <architecture>hppa</architecture>
    <architecture>m68k</architecture>
    <architecture>mips</architecture>
    <architecture>mipsel</architecture>
    <architecture>s390</architecture>
    <architecture>sparc</architecture>
    <name>libpng2</name>
    <range><lt>1.0.12-3.woody.7</lt></range>
  </package>

or

  <package>
    <distribution>stable</distribution>
    <architecture>any</architecture>
    <name>libpng2-dev</name>
    <range><lt>1.0.12-3.woody.7</lt></range>
  </package>

etc.

These nits aside, I can probably use VuXML for my project, even if it 
means extending the DTD. Thanks for pointing it out!

-- 
Joshua Goodall <joshua@myinternet.com.au>
Solutions Architect / Principal Security Architect
myinternet Limited.

Attachment: pgpqh1YU3EsZz.pgp
Description: signature


Reply to: