[Openvas-devel] Gentoo ebuilds for openvas
jfs at computer.org
Thu Nov 8 19:10:39 CET 2007
2007/11/2, Jan-Oliver Wagner <jan-oliver.wagner at intevation.de>:
> On Freitag, 2. November 2007, Javier Fernández-Sanguino Peña wrote:
> > On Fri, Nov 02, 2007 at 09:39:37AM +0100, Jan-Oliver Wagner wrote:
> > > I wonder why it is one big file.
> > Because many of the tests are shared.
> > > In the future, will there be separate files, one for each DSA?
> > Probably not, it will be a per-year DSA file.
> this would be a pitty. If new DSAs are not made available as
> OVAL right when they appear, various advantages are lost.
Ok guys, http://www.debian.org/security/oval/ is now available. Even
though this is a per-year XML file the file for the current year gets
updated *as*soon* as a new DSA is published a the website.
> Well, OpenVAS could react to any DSA with applying
> DSA2OVAL and then OVAL2NASL, but the later published
> annual summary might differ in ernumertations or naming.
Notice that the dsa2oval scripts available in the website can be used
to generate a single XML per release (with a few, if any, changes).
Differing in enumerations is not an issue, the reason why the files
are per year is similar to why http://people.redhat.com/mjc/oval/ is
per month: to try to share common tests and reduce the size of OVAL
Sharing tests means that the OVAL agent can more easily test multiple
OVAL definitions (as he already "knows" the result of a given test).
For example, if you have 100 definitions that apply only to Debian
'4.0' you can have a single test (referenced by each definition) of
'$DEBIAN_RELEASE == 4.0' instead of having 100 tests of
'$DEBIAN_RELEASE == 4.0'
I would like to know what people (specially OpenVAS developers) think
of this. I might be tempted to change the scripts so both per-year and
per-month XML files are provided, if necessary.
More information about the Openvas-devel