> > For RHEL, if we can add \n at the end in this query, it works,
> > rpm -qa --qf '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig}\n'
>
> > Sure, no problem on my side. I will fix the parser for the OVAL plugins
> > accordingly.
> yes, I'd say: go ahead.
> Chandra, Thomas, can you make your changes accrodingly so that we
> can get out openvas-plugins today?
We are working on gather-package-list.nasl to add \n and also reworking our
scripts to point to gather-package-list.nasl
There's ss_ssh_func.inc which is same as ssh_func.inc except few changes
that I had made to ssh_func.inc. Can we again, retain just one file here?
We'll move this to ssh_func.inc?
> > The regular expression is failing because of large string and it doesn't
> > seem to grep appropriately.
> >
> > I think, we should all move to gather-package-list.nasl, move everything
> > into this. I just glanced through, nothing seems to break by adding '\n'
at
> > the end of rpm -qa queries. So, we'll add \n to gather-package-list.nasl
> > and move all our scripts to point to this.
>
> While we are at it, would it make sense to leave the parsing as well to
> gather-package-list.nasl?
>
> That way, we wouldn't end up with a huge string in the KB that could be in
any
> of the different formats (depending on the distribution) but with
structured
> information about the packages in the KB. This would enable us to check
for
> package versions etc. using the functions already available for the KB
> instead of writing dozens of new functions in NASL.
>
> I'm not sure how much work it would take, but IMHO it would be well worth
the
> effort and make writing LSCs both easier and more efficient.
> Sounds promising.
> But I would like to first do the new release.
Chandra.
_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
