[Openvas-devel] Planning OpenVAS 4 Beta
bitdealer at gmail.com
Thu Nov 4 01:09:17 CET 2010
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. 18.104.22.168 for beta1, 22.214.171.124 for beta 2,
> > 126.96.36.199 for rc1, 188.8.131.52 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
> I would plan to use these package names, rather than your scheme..
> (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.
More information about the Openvas-devel