Hmmm...
Well, two problems - there's the variable naming conflict,
and repeated data gathering done by different scripts.
To avoid all of this, I would recommend that
a) OpenVAS have a single data gatherer
b) Any family of local checks added to OpenVAS
should (must?) have the data dathering commands
added to the OpenVAS data gatherer.
I think someone on the OpenVAS team needs to take charge
of a single data gathering script, and as various
local check families are added to OpenVAS, support for
the package retrievals are added to that single script.
Anyone else that wants to have their own proprietary
families of scripts can choose to implement their
own data gathering functions, but when a family of
scripts is added to OpenVAS, the queries needed to
do that (be it dpkg, rpm -qa, or whatever) ought to
be in a single data gatherer.
I am willing to work on moving Gentoo scripts over to
a single data gatherer (currently, Gentoo isn't up
to date - Michel - are you still providing GPLed
support for Gentoo, and if so, do you wish to continue
to do so?), and hopefully thereby remove ssh_get_info.nasl
out of the loop (or the very least, remove within it
any code made redundant by another data gatherer).
Michael, re signature checks for RHEL line, I see no
reason why this should't be put directly into the
this same data gatherer. It won't break anything
at this point in OpenVAS to do so.
Chandra, could you check out pkg-lib-rpm.inc and
see if that helps you at all with resolving your
regex problems? I've just checked this in - it is
the helper library we've been using on all distros
that support RPMs (RedHat, Fedora, Mandrake, SuSE,
Trustix, TurboLinux)
Thomas
Chandrashekhar B wrote:
> We initially had secpod_ssh_sys_info.nasl and all our scripts were written
> with this. Later on, when we tried to integrate with ssh_get_info.nasl, it
> turned out that some regular expressions were not working on the results of
> "rpm -qa" and hence we introduced the newline char. As of now, only Gentoo
> advisory checks are using ssh_get_info.nasl, if they do not break with \n
> addition, it should work. We can move to using ssh_get_info.nasl or Gentoo
> checks can be moved to use secpod_ssh_sys_info.nasl.
>
> Thanks,
> Chandra.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Michael
> Wiegand
> Sent: Wednesday, September 10, 2008 12:47 PM
> To: openvas-devel@wald.intevation.org
> Subject: Re: [Openvas-devel][Openvas-commits] r1298 - in
> trunk/openvas-plugins: . scripts
>
> Am Mittwoch, 10. September 2008 02:30:46 schrieb Thomas Reinke:
>> If both scripts are in the feed, both scripts are automatically run
>> on any open ssh port. If both can login, then both will retrieve
>> information, and whichever one is run second will clobber the kb
>> entries made by the first one.
>>
>> Whether or not there are scripts dependent on this new script is
>> irrelevant. The fact that they are both in the feed at the same
>> time makes for unpredictable results, unless kb variable names
>> are changed.
>
> I have now checked the scripts that do access ssh/login/rpms. It turn out
> that
> there are only three of them in the feed, and they all access ssh/login/rpms
>
> in the same way: cups_CB-A08-0045.nasl, kerberos_CB-A08-0044.nasl and
> samba_CB-A08-0085.nasl.
>
> As far as I can tell from reading the NASL, those scripts will ignore any
> additional information. I would appreciate it if someone could confirm my
> observation, but I do think there is little potential for conflict.
>
> If this is the case, I think we could safely include the new feature into
> gather-package-list.nasl. As a precautionary measure, we could limit
> collection of signatures to RHEL3-5 as I proposed yesterday; since the three
>
> scripts mentioned aboved only access ssh/login/rpms if the detect a SuSE or
> Fedora system, this should eliminate any potential for conflict.
>
> I also discovered that there are two other scripts collecting
> ssh/login/rpms:
> ssh_get_info.nasl and secpod_ssh_sys_info.nasl. The changes in
> secpod_ssh_sys_info.nasl might also break the three scripts mentioned above,
>
> since they introduced a newline character in the rpm query results. As I
> said
> before, I am no NASL expert, but you might want to take a look at that.
>
>> Ok...I understand the intent, it's just the execution failed to
>> accomplish that what was desired.
>
> Agreed. I guess I might have been a little too enthusiastic to get OVAL
> support into the trunk. ;)
>
> Let me know what you think.
>
> Regards,
>
> Michael
_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
