[Openvas-devel] Planning OpenVAS 4 Beta
njtaylor at asterisk.demon.co.uk
Thu Nov 4 00:36:25 CET 2010
On 10/31/10 20:37, Stephan Kleine wrote:
> On Friday October 29 2010 22:30:57 Jan-Oliver Wagner wrote:
>> 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. 126.96.36.199 for beta1, 188.8.131.52 for beta 2, 184.108.40.206
> for rc1, 220.127.116.11 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).
> Openvas-devel mailing list
> Openvas-devel at wald.intevation.org
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..
(Previous releases appear to have used something like this).
Clicking on this link browsing..
Might be coincidence but looks like the browsing also doesn't like the ~
character either. I got this response..
An Exception Has Occurred
tags/gsd-release-1.0.0\~rc1: unknown location
HTTP Response Status
404 Not Found
Traceback (most recent call last):
File "/var/lib/gforge/etc/viewcvs.py", line 3235, in main
File "/var/lib/gforge/etc/viewcvs.py", line 317, in run_viewcvs
% self.where, '404 Not Found')
ViewCVSException: 404 Not Found: tags/gsd-release-1.0.0\~rc1: unknown location
More information about the Openvas-devel