[Oval-devel] Python OVAL generator tool 0.2

[Javier Fernández-Sanguino Peña]

On Tue, Jun 05, 2007 at 11:52:40AM +0200, Javier Fernández-Sanguino Peña wrote:
> 
>   New version of Python OVAL generator tool is uploaded to subversion trunk.

I've updated my local SVN copy. It still is not able to parse the entire www
CVS tree. For example, if I run it against the 2000 subdirectory I get this:

$ python parse-dsa-oval.py  -d ~/debian/www/webwml/english/security/2002/
ERROR:root:Bpackages differ [1] in 149[2.2] for sparc and m68k
ERROR:root:Bpackages differ [2] in 149[2.2] for sparc and i386
ERROR:root:Bpackages differ [3] in 149[2.2] for sparc and alpha
Traceback (most recent call last):
  File "parse-dsa-oval.py", line 89, in ?
    printdsas(dsaref)
  File "parse-dsa-oval.py", line 33, in printdsas
    ovalDefinitions = oval.definition.generator.createOVALDefinitions (dsaref)
  File "..../generator.py", line 201, in createOVALDefinitions
    definitions.appendChild (createDefinition(dsa, dsare))
  File "..../generator.py", line 170, in createDefinition
    platformCriteria.appendChild (createPlatformDefinition(platform, data,
dsa)) 
 File "..../generator.py", line 117, in createPlatformDefinition
    archDependCriteria.appendChild (supportedPlatformCriteria)
UnboundLocalError: local variable 'supportedPlatformCriteria' referenced
before assignment


> TODO:
> 1. Select rigth way for mutiplatform dsa files. Now script generate one
> definition per dsa file. I add aditional criteria level for platform test
> like:
(...)
>   But, maybe we need generate individual definition for each platform?

I would change 'Software section' to 'Release section' as the information
there is a Debian release (3.1, 4.0). 

As for different definitions per platform I don't think its required.

> 2. How can handle cases when various architectures have various affected
> packages or packages version? We can do:

Can you please provide me with a DSA example. The package versions should be
the same for different architectures although some DSA's apply to only one
architecture even though there might be another DSA with the same CVE
reference that applies to a different arch.

>   - always write full crtiterions test for each architecture (big resulted
> definitions)

No.

>   - write full crtiterions test for each architecture only if at least one
> package or version differ

That might be a compromise.

>   - check every combinations of package + version + architecture and
> generate various definitions (hard to implement)

How are you currently storing the information for DSAs? I don't think it
would be that complicated to implement something like a hash reference:
DSA->Architecture->Package->Version so that the program would (for a given
DSA):

foreach architecture i (1 -> 10)
    if this architecture has not been inspected:
        find all architectures for which the package version is the same 
          output a criteria: ( OR ( archi, archi+1,... ) AND (package, version)
          mark this architecture as "inspected"
    fi
end loop

Thus, if the package version of all architectures match you have this:

            <criteria comment='Architecture dependent section' operation='AND'>
              <criteria comment='Supported architectures section' operation='OR'>
                <criterion comment='ARCHA architecture'>
                <criterion comment='ARCHB architecture'>
                <criterion comment='ARCHC architecture'>
              </criteria>
              <criteria comment='Packages section' operation='OR'>
                <criterion comment='PACKAGE version &lt; Y'> 
              </criteria>

But you can also have:

         <criteria comment='Architecture' operation='OR'>
            <criteria comment='Architecture dependent section' operation='AND'>
              <criteria comment='Supported architectures section' operation='OR'>
                <criterion comment='ARCHA architecture'>
                <criterion comment='ARCHB architecture'>
              </criteria>
              <criteria comment='Packages section' operation='OR'>
                <criterion comment='PACKAGE_Y version &lt; Y'> 
              </criteria>
            <criteria comment='Architecture dependent section' operation='AND'>
              <criteria comment='Supported architectures section' operation='OR'>
                <criterion comment='ARCHC architecture'>
              </criteria>
              <criteria comment='Packages section' operation='OR'>
                <criterion comment='PACKAGE_X version &lt; X'> 
              </criteria>
             </criteria>
        </criteria>

> 3. Generate tests, objects and state for architectures, platforms and
> packages. Have many and many questions because of perl script not implement
> this.

I believe you have to create a list of tests, objects and state and add them a
unique identifier. Whenever you have to add a new test, parse the list and
add if it's not there.  

Once all the definitions have been printed, go through the list and print 
the tests and states.

Does this make sense?

If you want we can approach RedHat to see what *their* automatic tool looks
like and maybe borrow ideas/code from it.

Regards

Javier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/oval-devel/attachments/20070606/8e70428a/attachment.pgp