[Openvas-devel] Planning OpenVAS 4 Beta

Nigel Taylor njtaylor at asterisk.demon.co.uk
Fri Nov 5 00:02:53 CET 2010



On 11/04/10 11:14, Thomas Reinke wrote:
> Stephan Kleine wrote:
>> On Thursday November 4 2010 00:36:25 Nigel Taylor wrote:
>>> On 10/31/10 20:37, Stephan Kleine wrote:
>>>> On Friday October 29 2010 22:30:57 Jan-Oliver Wagner wrote:
>>>>> Hi,
>>>>>
>>>>> now that we completed another round of releases for the current
>>>>> stable version I'd like to start into the Beta phase
>>>>> of "OpenVAS 4" (or whatever better name is proposed).
>>>>>
>>>>> As it stands, first Beta could consist of these components.
>>>>> I might have forgotten or mixed up something. Let me know.
>>>>>
>>>>> openvas-libraries 4.0.0~beta1
>>>>>
>>>>>   -> current trunk perhaps with my nvti patch and Michaels'
>>>>>   
>>>>>      patch for network scans and a patch to optinally force
>>>>>      any sort of http request through a security proxy (modsecurity)
>>>>>      where blacklists can apply etc.
>>>>>
>>>>> openvas-scanner 3.2.0~beta1
>>>>>
>>>>>   -> current trunk with the rest of Michaels patch and perhaps
>>>>>   
>>>>>      further nvti patches
>>>>>
>>>>> openvas-manager 2.0.0~beta1
>>>>>
>>>>>   -> current trunk.
>>>>>
>>>>> openvas-administrator 0.9.0
>>>>>
>>>>>   -> as is
>>>>>
>>>>> gsa 2.0.0~beta1
>>>>>
>>>>>   -> current trunk
>>>>>
>>>>> gsd 1.0.0~rc2
>>>>>
>>>>>   -> current trunk with some adpations to handle OMP 1.0 and OMP
>>>>>   2.0~beta1
>>>>>   
>>>>>      in parallel.
>>>>>
>>>>> openvas-cli 1.0.2
>>>>>
>>>>>   -> current trunk with similar adapations as gsd.
>>>>>
>>>>> Major new features would be:
>>>>> (and very likely I forgot a quite a number of further)
>>>>>
>>>>> * Master-Slave
>>>>> * Report Format Plugin Framework
>>>>> * Targets: More ways to specify ranges
>>>>> * Credentials: Editor (password changes possible)
>>>>> * Escalators: More of them, current improved
>>>>> * OMP: protocol self-documentation as HTML, XML, RNC
>>>>> * Network scan plugins (speedup), in case we apply the patch
>>>>> * lower mem footprint (~10% more concurrent scanner possible), if we
>>>>> apply the patch
>>>>>
>>>>>
>>>>> My yet unmet wishlist includes
>>>>> * full migration to cmake
>>>>> * turn cnvts into nasl functions, called by a nasl replacement wrapper
>>>>> * simplify/stripdown OTP to essentials.
>>>>>
>>>>>
>>>>> Comments, Suggestions?
>>>> Can you please change the version names since ~beta1 makes it
>>>> unnecessarily harder to package cause rpm can't handle -betaX or ~betaY
>>>> (and I would be surprised if .deb can do those).
>>>>
>>>> So, please name those, e.g. 3.1.98.1 for beta1, 3.1.98.2 for beta 2,
>>>> 3.1.99.1 for rc1, 3.1.99.3 for rc3 and so on including naming the source
>>>> archives and the subdirectory within them according this way.
>>>>
>>>> My point simply is that this would allow seamless upgrades - otherwise I
>>>> would have to name the packages like that for which I'm honestly too
>>>> lazy (whithout those changes updates from beta1 to beta2 will work, to
>>>> rc1 prolly too (since r > b) but 4.0.0 is smaller than 4.0.0.betaX).
>>>>
>>>> thanks,
>>>> Stephan
>>>> _______________________________________________
>>>> Openvas-devel mailing list
>>>> Openvas-devel at wald.intevation.org
>>>> http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
>>> I agree with the comment made above I built the gsd-1.0.0~rc1 package for
>>> OpenBSD created an iso image, ~ is used as a special for backup files for
>>> editors normally ignored, same for windows ~ used for short file names good
>>> idea to avoid using. The package went missing from the iso image.
>>>
>>> I have now changed the package name to gsd-1.0-rc1 in the OpenBSD port
>>> Makefile.
>>>
>>> I would plan to use these package names, rather than your scheme..
>>> openvas-libraries-4.0-beta1
>>> openvas-scanner-3.2-beta1
>>> openvas-manager-2.0-beta1
>>> gsa-2.0-beta1
>>> gsd-1.0-rc2
>>> (Previous releases appear to have used something like this).
>>
>> Right, but this doesn't resolve my problem. rpm and deb simply can't handle 
>> something like -betaX so I had to artificially change it to some made up 
>> version - like 3.98.1.
>>
>> My point simply is that if "upstream" would use something like e.g. 3.98.1 for 
>> their first beta of v4 and proceed like explained above it would be easy to 
>> package. Using -betaX just makes it unnecessary hard.
> 
> Ditto here.  The scanner itself provides extra ammunition to support
> this. Think of how we ourselves do version checks for package numbers.
> 
> Think bug found in 3.2-beta1, but resolved in all subsequent packages.
> Oops - 3.2 is later than 3.2-beta1, but is lexicographically less.
> This has caused exception use cases that we've had to code up in the
> past to handle these scenarios.
> 
> There would be a certain irony if we chose package number schemes
> out of the ordinary that actually made our own life even _slightly_
> more difficult in terms of vulnerability checks.
> 
> Thomas
> _______________________________________________
> Openvas-devel mailing list
> Openvas-devel at wald.intevation.org
> http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
> 

I have no problem with using 3.98.1, 3.98.2, 3.99.1, 3.99.2.

If source is released as 4.0.0~beta1 then I will rename the package to
4.0-beta1. If source is released as 3.98.1,then I will use 3.98.1, I don't want
to get source 4.0.0~beta1 and produce a package 3.98.1.

Regards

Nigel Taylor


More information about the Openvas-devel mailing list