Am Dienstag, 9. September 2008 17:24:30 schrieb Jan-Oliver Wagner: > > If I'm not mistaken, we might need to rethink the > > approach on this script. As it stands, this script > > overwrites the "ssh/login/rpms" kb item that is > > set by gather-package-list.nasl > > hm, the new script overwrites the KB in any case, even if not used? > However, checking it is easily done and not noticed. > > Michael: better fix this soon.
I think there is only little potential for conflict as it is unlikely that both scripts will run during the same scan run. The only "script" that uses gather-package-list-sigkeyid.nasl is the OVAL integration; my rationale behind creating a modified .nasl was that I was not sure if all plugins that required gather-package-list.nasl would be able to handle the additional item of information retrieved by the modified rpm query. This modification was strictly a measure to avoid breaking compatibility with plugins already in existence; once we have established that all plugins can handle the additional information, we can safely include this capability into gather-package.list.nasl. > > We should either change gather-package.list.nasl > > to include the desired capability, or have this > > gather-package-list-sigkeyid.nasl set a different > > set of kb variables to avoid conflicts. As I explained, this will happen sooner rather than later with OVAL support maturing in the near future. > Probably it is best to make it configurable to retrieve > signatures at it blows up the KB for the NASL-based tests > unecessarily. I don't think KB size is a big issue in this case, since a great amount of KB space is currently being wasted by simply dumping the result of the remote package query in one single KB entry. I think it would really make sense to put the package information into the KB in a more structured way, preferably distribution-independent. This would make the information retrieved a lot more useful, especially for other plugins. > Maybe a global setting "support oval" ? > Or more explicit "Retrieve package signatures into KB" > as an preferences option of gather-package.list.nasl (off by default) ? That would certainly be a possibility if KB size is a big concern; another option would be to only retrieve the package signatures from system where we know we can use them, namely RHEL3, 4 and 5. But on the whole I'm very much in favor of a more structured approach to information gathering that would avoid issues like this in the future. Regards, Michael _______________________________________________ Openvas-devel mailing list Openvas-devel@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
