[Openvas-devel] Planning OpenVAS 4 Beta

Thomas Reinke lists at securityspace.com
Thu Nov 4 12:14:05 CET 2010


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


More information about the Openvas-devel mailing list