[Openvas-devel] [Openvas-discuss] Discontinuing openvas-plugins tarball?

Ullrich-IT-Consult hans.ullrich at loop.de
Thu Apr 23 11:16:58 CEST 2009

Am Donnerstag 23 April 2009 schrieb Michael Wiegand:
> Hello,
Hi Michael and Jan,
> Jan and I have been thinking about discontinuing the release of
> openvas-plugins tarballs and distributing the plugins only through the
> existing Feed Services.
> The background is that using both the tarball and the openvas-nvt-sync
> script does under certain conditions lead to a race condition in the
> plugin cache which causes openvasd to use an outdated cached version of
> a plugin even though the plugin has changed in the feed. We have tried
> to compensate for this by making adjustments in the synchronization
> script, but this has the side effect of disproportionately increasing
> the time and bandwidth needed to synchronize with the feed.
> I would like your opinions regarding the following issues:
> - What would be the consequences of discontinuing the tarball release?
>   There should not be installations which use only the tarball and never
>   sync, should there?

I think, there were be no consquences at all. The only thing, that copmes in 
my mind, would be a possibility to transport the tarball to factories, which 
might have (for waht reasons ever) , no access to the internet. In this case 
it would be nice, to have a possibility to add new plugins or add plugins at 

> - What mechanisms should be available for users who cannot sync using
>   rsync due to restrictions on firewall or proxy level?

I think, most users should have access to the internet with http, and as far 
as I know, rsync offers an option, to use http (if I remember correctly). In 
other case, there comes the word "tunneling" in my mind. Maybe to invent an 
easy way for users, to tunnel through http??? 

> - Should openvasd force an initial sync during installation or just
>   display a notice that a sync is need to use OpenVAS?

I suggest, not to force an initial sync, as some users or security analysts 
might want to test new plugins before they break things at their customners. 
It might be, they want to keep old plugins during tests. IMO the suggestion is 
the better way, so the security analyst can decide for himself, if to upgrade 
or not.
> - Any other issues you can think of. :)

None at the moment. :)

> I'm looking forward to your opinions. Please do not hesitate to ask if
> my proposal does not make sense to you.
> I am crossposting this to openvas-discuss and openvas-plugins as well to
> reach all involved parties. Please keep crossposting to a minimum in
> your replies and try to reply in openvas-devel. Thank you!
> Regards,
> Michael

Best regards

Hans-J. Ullrich

Inh.: Hans-J. Ullrich
Münstedter Weg 10
31246 Oberg
www:  http://www.ullrich-it.de
www2: http://www.ccpeine.de

IT-Spezialist für die Bereiche IT-Sicherheit, 
Linux und Unix, EDV-Schulungen und -Workshops 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090423/54d27f66/attachment.html>

More information about the Openvas-devel mailing list