[Openvas-discuss] ID/OID scheme for OpenVAS NASL scripts?
labeneator at gmail.com
Mon Jan 7 12:46:04 CET 2008
On Jan 3, 2008 11:47 PM, Bernhard Herzog <bh at intevation.de> wrote:
> On Thursday 03 January 2008 12:00, Jan-Oliver Wagner wrote:
> > If not, is the above example to way to go?
> Sounds good in principle. I wonder, though, whether there should be
> additional intermediate levels of OIDs and a way to simply map the old
> plugin ID to an OID during a transition phase:
> ...25623.1 = OpenVAS.NASL
> ...25623.1.1 = OpenVAS.NASL.legacy
> ...256220.127.116.11 = OpenVAS.NASL.legacy.123 (old nessus ID 123 as OID)
> ...25623.1.2 = OpenVAS.NASL.libraries
> ...25623.1.3 = OpenVAS.NASL.DSA
> ...25623.2 = OpenVAS.SomeOtherPluginSpace
> This would leave the OID space a little cleaner if we ever need OIDs for
> purposes such as LDAP attributes.
> Maybe we should create the ID based on the OID in the suggested manner
with a few enhancements..:)
Legacy : ...25618.104.22.168 = OpenVAS.NASL.legacy.123 (old nessus ID 123
New IDs: ...25622.214.171.124 = OpenVAS.OSVDB.123 (OSVDB vulnerability 123)
...256126.96.36.199 = OpenVAS.CVE.123 (CVE vulnerability 123)
And also reserve an OID branch to SNMP (Appliances use)
> > Also doable, maybe less overall efford than to change int to str for ID.
> > Open question is what to do with the old ID, just try to have no
> > among the various contributores via some simple rules? Leave empty?
My 2 cents.. Leave it empty. <deprecated>
> I'd say we switch to using OIDs. script_id(1157) would be equivalent to
> script_oid("188.8.131.52.4.1.256184.108.40.2067") using the legacy OIDs from above.
> Bernhard Herzog Intevation GmbH, Osnabrück
> Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/
> Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> Openvas-discuss mailing list
> Openvas-discuss at wald.intevation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openvas-discuss