From JBebeau at CASTLEGARDE.COM  Wed Oct  1 22:28:37 2008
From: JBebeau at CASTLEGARDE.COM (Jon Bebeau)
Date: Wed, 1 Oct 2008 16:28:37 -0400
Subject: [Openvas-devel] Guidance compiling OpenVAS-Client 2.0 beta1 with
	Visual Studio
Message-ID: <D3A02341AEE23242A4188BDA5AD854A85F4746@bounty.CASTLEGARDE.COM>

Hello all, 

 

I'm new to OpenVAS and I'd like to compile the client for Windows XP
using Visual Studio.  Any guidance and suggestions on how to put this
code together is appreciated.

 

In advance,

 

Jon

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081001/2bba9f71/attachment.html

From c_edjenguele at yahoo.it  Thu Oct  2 10:10:16 2008
From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE)
Date: Thu, 2 Oct 2008 08:10:16 +0000 (GMT)
Subject: [Openvas-devel] Guidance compiling OpenVAS-Client 2.0 beta1
	with Visual Studio
Message-ID: <9717.60534.qm@web26007.mail.ukl.yahoo.com>

Hi,
this is a good question, I've tried to do this too,
but with the 1.0.4 release the ithe possiblity to compile it?for windows using namake,
however you must prepare the package on a linux machine!
under the openvas-client-1.0.4/openvas-client-1.0.4/nessus directory, there is a file named nmake.w32,
and then on windows just?launch the file?nmake.bat

PS:?I've tested this procedure with nessus client!,?so?with openvas-client it must works to.
?---
Christian Eric Edjenguele
IT Security Software Developer & Researcher
tel. +39 3408580513 



----- Messaggio originale -----
Da: Jon Bebeau <JBebeau at CASTLEGARDE.COM>
A: openvas-devel at wald.intevation.org
Inviato: Mercoled? 1 ottobre 2008, 22:28:37
Oggetto: [Openvas-devel] Guidance compiling OpenVAS-Client 2.0 beta1 with Visual Studio


Hello all, 
?
I?m new to OpenVAS and I?d like to compile the client for Windows XP using Visual Studio.? Any guidance and suggestions on how to put this code together is appreciated.
?
In advance,
?
Jon


      Scopri il blog di Yahoo! Mail:
Trucchi, novit? e la tua opinione.
http://www.ymailblogit.com/blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081002/7e262a6c/attachment.htm

From kost at linux.hr  Sun Oct  5 22:21:27 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Sun, 05 Oct 2008 22:21:27 +0200
Subject: [Openvas-devel] OpenVAS talk at CCC
Message-ID: <48E921C7.2040101@linux.hr>

Hello!

Just contributed abstract and description and other things needed for
OpenVAS talk at CCC (as today is deadline).

You can take a look at the submitted things here:
http://www.linux.hr/openvas/openvas-25c3-contribution.png

It's for reference only as today is deadline, so if there's no serious
errors - you have to live with that :)

Final notification of acceptance will be November the 7th.

Kost

From kost at linux.hr  Sun Oct  5 22:26:37 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Sun, 05 Oct 2008 22:26:37 +0200
Subject: [Openvas-devel] [Fwd: OpenVAS talk at CCC]
Message-ID: <48E922FD.2050205@linux.hr>

Actually, you have 30 minutes to comment (23:59 UTC).

-------- Original Message --------
Subject: OpenVAS talk at CCC
Date: Sun, 05 Oct 2008 22:21:27 +0200
From: Vlatko Kosturjak <kost at linux.hr>
To: openvas-devel at wald.intevation.org

Hello!

Just contributed abstract and description and other things needed for
OpenVAS talk at CCC (as today is deadline).

You can take a look at the submitted things here:
http://www.linux.hr/openvas/openvas-25c3-contribution.png

It's for reference only as today is deadline, so if there's no serious
errors - you have to live with that :)

Final notification of acceptance will be November the 7th.

Kost


From JBebeau at CASTLEGARDE.COM  Tue Oct  7 01:14:29 2008
From: JBebeau at CASTLEGARDE.COM (Jon Bebeau)
Date: Mon, 6 Oct 2008 19:14:29 -0400
Subject: [Openvas-devel] Dependencies compiling openvas-libnasl 2.0-beta1
Message-ID: <D3A02341AEE23242A4188BDA5AD854A85F481A@bounty.CASTLEGARDE.COM>

Hi all,

 

I'm attempting to compile from source development branch, 2.0 beta.  I'm
using a clean Deb Etch and I find a bunch of packages needed;
libgnutls-dev, libpcap-dev, libgpgme-dev, to list a few.  I got through
openvas-libraries OK, but into openvas-libnasl and it needs GLIB...

 

Checking for GLIB... no

Configure: error: "glib not found"

 

Google led me to glib-2.18.1.tar.gz.  Compiling this glib (glib-2.18.1)
tell me it needs gettext.

 

It seems to me I'm missing something big, like not having the proper
development platform.  I only installed the basic debian with no desktop
or even "standard", only kernel headers and build-essentials, plus the
packages listed above.  Can someone list the required packages to
compile OpenVAS?

 

Thanks,

 

Jon

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081006/8872550e/attachment.htm

From JBebeau at CASTLEGARDE.COM  Tue Oct  7 01:40:29 2008
From: JBebeau at CASTLEGARDE.COM (Jon Bebeau)
Date: Mon, 6 Oct 2008 19:40:29 -0400
Subject: [Openvas-devel] Compile error in openvas-libnasl 2.0-beta1
Message-ID: <D3A02341AEE23242A4188BDA5AD854A85F481C@bounty.CASTLEGARDE.COM>

In compiling openvas-libnasl from source beta 2, I get the following
errors:

 

nasl_cmd_exec.c: In function 'nasl_fread':

nasl_cmd_exec.c:280: error: 'FALSE' undeclared (first use in this
function)

nasl_cmd_exec.c:280: error: (Each undeclared identifier is reported only
once

nasl_cmd_exec.c:280: error: for each function it appears in.)

nasl_cmd_exec.c:281: warning: passing argument 1 of 'close' makes
integer from pointer without a cast

nasl_cmd_exec.c:286: error: 'st' undeclared (first use in this function)

nasl_cmd_exec.c: In function 'nasl_fwrite':

nasl_cmd_exec.c:413: error: 'FALSE' undeclared (first use in this
function)

nasl_cmd_exec.c:414: warning: passing argument 1 of 'close' makes
integer from pointer without a cast

make[1]: *** [nasl_cmd_exec.o] Error 1

make[1]: Leaving directory `/root/openvas-libnasl/nasl'

make: *** [all] Error 2

 

I don't know if this list is the proper place or if it should be on bug
tracker.  As it is beta, I thought I'd ask here.

 

Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081006/435f366e/attachment.html

From michael.wiegand at intevation.de  Tue Oct  7 08:18:57 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Tue, 7 Oct 2008 08:18:57 +0200
Subject: [Openvas-devel] Dependencies compiling openvas-libnasl 2.0-beta1
In-Reply-To: <D3A02341AEE23242A4188BDA5AD854A85F481A@bounty.CASTLEGARDE.COM>
References: <D3A02341AEE23242A4188BDA5AD854A85F481A@bounty.CASTLEGARDE.COM>
Message-ID: <200810070818.57918.michael.wiegand@intevation.de>

[Tuesday 07 October 2008 - 01:14:29] "Jon Bebeau" <JBebeau at castlegarde.com>:
> Hi all,
>
> (..)
>
> It seems to me I'm missing something big, like not having the proper
> development platform.  I only installed the basic debian with no desktop
> or even "standard", only kernel headers and build-essentials, plus the
> packages listed above.  Can someone list the required packages to
> compile OpenVAS?

Jon,

since 2.0-beta1, glib is indeed required to compile openvas-libnasl due to 
changes in command line parsing in the standalone NASL interpreter.

The package you need is available under etch as "libglib2.0-dev". Could you 
install this package and let me know if you are able to compile?

The documentation and the error messages are indeed not yet very helpful, this 
will be fixed shortly. Thank you for testing the beta and bringing this to 
our attention.

Regards,

Michael

-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From michael.wiegand at intevation.de  Tue Oct  7 08:34:37 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Tue, 7 Oct 2008 08:34:37 +0200
Subject: [Openvas-devel] Compile error in openvas-libnasl 2.0-beta1
In-Reply-To: <D3A02341AEE23242A4188BDA5AD854A85F481C@bounty.CASTLEGARDE.COM>
References: <D3A02341AEE23242A4188BDA5AD854A85F481C@bounty.CASTLEGARDE.COM>
Message-ID: <200810070834.37675.michael.wiegand@intevation.de>

[Tuesday 07 October 2008 - 01:40:29] "Jon Bebeau" <JBebeau at castlegarde.com>:
> In compiling openvas-libnasl from source beta 2, I get the following
> errors:
>
> nasl_cmd_exec.c: In function 'nasl_fread':
>
> (..)
>
> make[1]: *** [nasl_cmd_exec.o] Error 1
>
> make[1]: Leaving directory `/root/openvas-libnasl/nasl'
>
> make: *** [all] Error 2
>
> I don't know if this list is the proper place or if it should be on bug
> tracker.  As it is beta, I thought I'd ask here.

I assume you did try the latest SVN revision from -trunk. Please be aware that 
the trunk is (as always) under development and not always guaranteed to work 
as expected. The code you are using is *not* a release version and as such 
has not yet passed the quality checks we do before a release.

I agree that it is regrettable that the code does not compile (it seems 
*someone* did not test his code before committing ;) ), but this is to be 
expected in a development trunk and should be fixed shortly.

If you are interested in following the latest developments and help with 
testing, I would advise you join our IRC channel #openvas on irc.oftc.net.

Regards,

Michael

-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From jan-oliver.wagner at intevation.de  Wed Oct  8 11:41:37 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Wed, 8 Oct 2008 11:41:37 +0200
Subject: [Openvas-devel] Guidance compiling OpenVAS-Client 2.0 beta1
	with Visual Studio
In-Reply-To: <9717.60534.qm@web26007.mail.ukl.yahoo.com>
References: <9717.60534.qm@web26007.mail.ukl.yahoo.com>
Message-ID: <200810081141.39465.jan-oliver.wagner@intevation.de>

On Donnerstag, 2. Oktober 2008, Christian Eric EDJENGUELE wrote:
> this is a good question, I've tried to do this too,
> but with the 1.0.4 release the ithe possiblity to compile it?for windows using namake,
> however you must prepare the package on a linux machine!
> under the openvas-client-1.0.4/openvas-client-1.0.4/nessus directory, there is a file named nmake.w32,
> and then on windows just?launch the file?nmake.bat
> 
> PS:?I've tested this procedure with nessus client!,?so?with openvas-client it must works to.

it is very likely that this will not work for OpenVAS-Client 1.0.4.
For 2.x the nmake stuff has even been removed.

In packaging/w32 are some hints how to get OpenVAS compiled
for Windows with cygwin.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From michael.wiegand at intevation.de  Wed Oct  8 12:53:18 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 8 Oct 2008 12:53:18 +0200
Subject: [Openvas-devel] Voting on Change Request #16
Message-ID: <200810081253.18754.michael.wiegand@intevation.de>

Hello,

I have prepared a change request which should solve the issue with new NVTs 
becoming automatically enabled in OpenVAS-Client in cases where this type of 
behavior is not desirable.

Please take a look at
http://www.openvas.org/openvas-cr-16.html
and let me know what you think and whether you agree with this request or not.

The change will only happen in the client and should be pretty 
straightforward.

Regards,

  Michael
-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From openvas-bugs at wald.intevation.org  Wed Oct  8 09:19:40 2008
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Wed,  8 Oct 2008 09:19:40 +0200 (CEST)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B779=5D_=22checks_t?=
	=?utf-8?q?o_perform_concurrently=22_is_set_to_default_value_of_4?=
	=?utf-8?q?=2C_some_Windows_plugins_fails_to_report?=
Message-ID: <20081008071940.6868E4070A@pyrosoma.intevation.org>

Bugs item #779, was opened at 2008-10-08 12:49
Status: Open
Priority: 3
Submitted By: Chandrashekhar B (chandra)
Assigned to: Nobody (None)
Summary: "checks to perform concurrently" is set to default value of 4, some Windows plugins fails to report 
Resolution: None
Severity: major
Version: None
Component: openvas-plugins
Operating System: None
Product: OpenVAS
Hardware: None
URL: 


Initial Comment:
The issue occurs when multiple plugins are selected for scanning. But, when only one plugin is selected, it reports appropriately.

Example scenario: 
(Quoting from Carsten)
Test is running gb_vmware_prdts_mult_vuln_win.nasl and gb_thunderbird_mult_vuln_july08_win.nasl against a host which has installed vmwareplayer 2.0.1 and Thunderbird 1.5.12. Only a warning for the vmware player is shown. Disabling the vmware check and running only the thunderbird test will bring up the Thunderbird warning.  
Running Firefox and Thunderbird test against a host with both vunerable versions brings sometimes zero, one or  two warnings only by running the test a few times without any changes. 

Observing the logs and the saved KB items, it looks like some of the plugins are failing to launch or they exit intermittently without traversing the entire code. 

Work around:
When "checks to perform concurrently" is set to 1, all plugins report appropriately. 



----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=779&group_id=29

From jan-oliver.wagner at intevation.de  Wed Oct  8 14:39:05 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Wed, 8 Oct 2008 14:39:05 +0200
Subject: [Openvas-devel] Voting on Change Request #16
In-Reply-To: <200810081253.18754.michael.wiegand@intevation.de>
References: <200810081253.18754.michael.wiegand@intevation.de>
Message-ID: <200810081439.07668.jan-oliver.wagner@intevation.de>

On Mittwoch, 8. Oktober 2008, Michael Wiegand wrote:
> I have prepared a change request which should solve the issue with new NVTs 
> becoming automatically enabled in OpenVAS-Client in cases where this type of 
> behavior is not desirable.
> 
> Please take a look at
> http://www.openvas.org/openvas-cr-16.html
> and let me know what you think and whether you agree with this request or not.
> 
> The change will only happen in the client and should be pretty 
> straightforward.

Basically I vote +1.

However, you should add extend the CR:

 - the corresponding item on the roadmap cites peridioc execution of the very same scan.
    This should be added to Purpose.

 - The Purpose section should also mention, that this is only a first step towards
    Family-based scan scenarios. I.e. it should be possible to define a Family (Debian
    local security Checks) and have all new NVTs of this family selected and all others not.

 - Design and Implementation should name the new parameter explicitely, name the code parts
   that need to modified.
   IIUC from IRC, it makes also sense to add a information dialog about new NVTs during
   this change.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From timb at nth-dimension.org.uk  Wed Oct  8 16:03:02 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Wed, 8 Oct 2008 15:03:02 +0100
Subject: [Openvas-devel] Voting on Change Request #16
In-Reply-To: <200810081439.07668.jan-oliver.wagner@intevation.de>
References: <200810081253.18754.michael.wiegand@intevation.de>
	<200810081439.07668.jan-oliver.wagner@intevation.de>
Message-ID: <200810081503.02758.timb@nth-dimension.org.uk>

On Wednesday 08 October 2008 13:39:05 Jan-Oliver Wagner wrote:
> On Mittwoch, 8. Oktober 2008, Michael Wiegand wrote:
> > I have prepared a change request which should solve the issue with new
> > NVTs becoming automatically enabled in OpenVAS-Client in cases where this
> > type of behavior is not desirable.
> >
> > Please take a look at
> > http://www.openvas.org/openvas-cr-16.html
> > and let me know what you think and whether you agree with this request or
> > not.
> >
> > The change will only happen in the client and should be pretty
> > straightforward.
>
> Basically I vote +1.
>
> However, you should add extend the CR:
>
>  - the corresponding item on the roadmap cites peridioc execution of the
> very same scan. This should be added to Purpose.
>
>  - The Purpose section should also mention, that this is only a first step
> towards Family-based scan scenarios. I.e. it should be possible to define a
> Family (Debian local security Checks) and have all new NVTs of this family
> selected and all others not.
>
>  - Design and Implementation should name the new parameter explicitely,
> name the code parts that need to modified.
>    IIUC from IRC, it makes also sense to add a information dialog about new
> NVTs during this change.

Likewise, but as Jan has alluded to, I would recommend some changes to the GUI 
to accompany the underlying change.  Firstly, should there should be an 
option to enable automatic inclusion of new families.  Secondly, if that 
option is disabled, perhaps the GUI should make some attempt to notify the 
user that new families exist.  I say this, as whilst I see the benefit from 
an auditing/governance perspective where you may wish to baseline and then 
measure compliance, from an active testing perspective I want the new plugins 
and I don't want to forget that they're there.  It's probably not a problem 
for me per se, as I track changes via the commit list but others may choose 
not to.

Cheers,
Tim
-- 
Tim Brown
<mailto:timb at nth-dimension.org.uk>
<http://www.nth-dimension.org.uk/>

From jan-oliver.wagner at intevation.de  Thu Oct  9 11:32:37 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 9 Oct 2008 11:32:37 +0200
Subject: [Openvas-devel] Voting on Change Request #16
In-Reply-To: <200810081503.02758.timb@nth-dimension.org.uk>
References: <200810081253.18754.michael.wiegand@intevation.de>
	<200810081439.07668.jan-oliver.wagner@intevation.de>
	<200810081503.02758.timb@nth-dimension.org.uk>
Message-ID: <200810091132.39517.jan-oliver.wagner@intevation.de>

On Mittwoch, 8. Oktober 2008, Tim Brown wrote:
> Likewise, but as Jan has alluded to, I would recommend some changes to the GUI 
> to accompany the underlying change.  Firstly, should there should be an 
> option to enable automatic inclusion of new families.  Secondly, if that 
> option is disabled, perhaps the GUI should make some attempt to notify the 
> user that new families exist.  I say this, as whilst I see the benefit from 
> an auditing/governance perspective where you may wish to baseline and then 
> measure compliance, from an active testing perspective I want the new plugins 
> and I don't want to forget that they're there.  It's probably not a problem 
> for me per se, as I track changes via the commit list but others may choose 
> not to.

Michael, can you try to the essence of this to CR#16?

Tim: Please note that the Client can inform the user about new NVTs
only in case caching is switched on. If not, there currently no chance
for the Client. Only the admin who runs nvt sync sees new arrivals.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From jan-oliver.wagner at intevation.de  Thu Oct  9 12:35:33 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 9 Oct 2008 12:35:33 +0200
Subject: [Openvas-devel] Launch news about 2.0 beta phase and compendium RC?
Message-ID: <200810091235.35339.jan-oliver.wagner@intevation.de>

Hello OpenVAS developers,

now that now serious problems occured with the 2.0-beta1 series
and a completed compendium I think it is a good time to launch
a OpenVAS news.

I'd appreciate a quick feedback and dicuss cycle to get the news
out rapidely.

I could image something like this:

OpenVAS 2.0 beta-testing started accompanied with new  comprehensive documentation

In late September, the OpenVAS[1] developer team released the 2.0-beta1 version of
the OpenVAS server and OpenVAS-Client for network security scanning.
Intended audience are experienced users interested in upcoming features and
developers of vulnerability checks.

The new version introduces first steps of support for OVAL[2] language. OVAL is an
international, information security, community standard to promote open, standardaized
and publicly available security content.
OpenVAS server can execute OVAL files just like its own (NASL) checks by using
the OVAL interpreter "ovaldi". While the plain ovaldi tool can only check systems where
it is installed, in combination with OpenVAS it can test any taget system for which OpenVAS
collected information. The beta1 release offers sample support for
Redhat Enterprise Linux OVAL tests.

The major internal changes are the cleaned and extended protocol for client-server
communication (OTP) and the transition to the new OID-based scheme for unique IDs
of vulnerability tests.

The OpenVAS Network Vulerability Tests (NVTs)
remains compatible with both, the 1.0 and 2.0 series of OpenVAS.
This also means, the OpenVAS NVT feed service (meanwhile extended to
deliver the full range of NVTs, grown to over 5000) is also compatible for
both release series.

Concurrently, the first release candidate of the new OpenVAS Compendium
has been made available in PDF and HTML format for final reviews and as a
base for translation into other languages (german already in progress).

All download links can be found on the OpenVAS homepage[1].


[1] http://www.openvas.org
[2] http://oval.mitre.org

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From jan-oliver.wagner at intevation.de  Fri Oct 10 10:49:22 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 10 Oct 2008 10:49:22 +0200
Subject: [Openvas-devel] Manage sladinstaller tool in OpenVAS SVN
Message-ID: <200810101049.24904.jan-oliver.wagner@intevation.de>

Hi,

as you know, OpenVAS supports SLAD [1]. The OpenVAS-Client even includes
a menu entry to call the sladinstaller, which is a GTK GUI for installing
SLAD on remote machines, GNU GPL licensed.

IMHO it makes sense to manage such GUIs that have quite some
relation to OpenVAS inside the OpenVAS repository.

The primary authors are OK to move sladinstaller over to the SVN
of OpenVAS.
Once the module is committed, we can apply a transition from Nessus-support
to OpenVAS support of sladinstaller. Nessus is of no relevance anymore for
SLAD.

Best

	Jan

[1] http://www.openvas.org/integrated-tools.html

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From felix.wolfsteller at intevation.de  Fri Oct 10 15:25:05 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Fri, 10 Oct 2008 15:25:05 +0200
Subject: [Openvas-devel] Path towards CR#16
Message-ID: <200810101525.05618.felix.wolfsteller@intevation.de>

Hi all
I've prepared some changes in the client towards CR#16 ( 
http://www.openvas.org/openvas-cr-16.html ), which is still to be voted upon.
Patch is attached and ready to be commited, 
Changelog below

Enjoy,
-- felix

2008-10-10  Felix Wolfsteller <felix.wolfsteller at intevation.de>

	Introduced a new scope- wise preference to control automatic
	en/disabling of new plugins. Partial solution to change request #16:
	http://www.openvas.org/openvas-cr-16.html .

	* nessus/preferences.c (prefs_get_default): Added default for 
	"auto_enable_new_plugins" option (1)

	* nessus/prefs_dialog/prefs_dialog.c (prefs_dialog_set_defaults, 
	prefs_dialog_apply): Hooked checkbox up with preference

	* nessus/prefs_dialog/prefs_plugins.c (prefs_dialog_plugins): Create and
	hook up GTK checkbox for new option

	* nessus/context.h (context_add_plugin): Changed signature of add_plugin
	from void to int

	* nessus/context.c (context_add_plugin): En/Disables new plugins based
	on the preference, returns if plugin was new (to be able to count)

	* nessus/comm.c (fetch_new_plugins, fetch_new_plugins): Counts new
	plugins based on the return value of context_add_plugin, displays
	info to user


-- 
Felix Wolfsteller |  ++49-541-335 08 3451  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: towardscr16.patch
Type: text/x-diff
Size: 8086 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081010/2cb33b21/towardscr16.bin

From timb at nth-dimension.org.uk  Mon Oct 13 08:44:56 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Mon, 13 Oct 2008 07:44:56 +0100
Subject: [Openvas-devel] Launch news about 2.0 beta phase and compendium
	RC?
In-Reply-To: <200810091235.35339.jan-oliver.wagner@intevation.de>
References: <200810091235.35339.jan-oliver.wagner@intevation.de>
Message-ID: <200810130744.56844.timb@nth-dimension.org.uk>

On Thursday 09 October 2008 11:35:33 Jan-Oliver Wagner wrote:
> Hello OpenVAS developers,
>
> now that now serious problems occured with the 2.0-beta1 series
> and a completed compendium I think it is a good time to launch
> a OpenVAS news.
>
> I'd appreciate a quick feedback and dicuss cycle to get the news
> out rapidely.

Your announcement looks good.  As I have already mentioned to Michael, I have 
made significant changes over the weekend, namely fixing the outstanding bugs 
against the symlink detection code, starting on integrating Solaris local 
checks, generating packaging for Debian (openvas-{client, libraries, libnasl, 
server}), regenerating some of the autoconf files etc.  I would therefore 
suggest a beta2 allowing time to confirm these changes do not cause problems 
elsewhere and allowing for packaging to be generated for other platforms.  
How does everyone feel about that?

Tim
-- 
Tim Brown
<mailto:timb at nth-dimension.org.uk>
<http://www.nth-dimension.org.uk/>

From openvas-bugs at wald.intevation.org  Mon Oct 13 00:14:53 2008
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Mon, 13 Oct 2008 00:14:53 +0200 (CEST)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B788=5D_Calling_ssh?=
	=?utf-8?q?=5Flogin=5For=5Freuse=5Fconnection=28=29_causes_an_error?=
	=?utf-8?q?_message_in_openvasd=2Emessages?=
Message-ID: <20081012221453.63076406F8@pyrosoma.intevation.org>

Bugs item #788, was opened at 2008-10-12 22:14
Status: Open
Priority: 3
Submitted By: Carsten Koch-Mauthe (ckm)
Assigned to: Nobody (None)
Summary: Calling ssh_login_or_reuse_connection() causes an error message in openvasd.messages 
Resolution: None
Severity: normal
Version: None
Component: openvas-libnasl
Operating System: None
Product: OpenVAS
Hardware: None
URL: 


Initial Comment:
Calling ssh_login_or_reuse_connection() within a script will always give the following messages in openvasd.messages:
===
[Mon Oct 13 00:01:11 2008][6979] shared_socket: Secret/SSH/socket is unknown
[Mon Oct 13 00:01:11 2008][6980] shared_socket: Secret/SSH/socket is unknown
[Mon Oct 13 00:01:11 2008][6979] shared_socket_register(): Error - recv_fd() failed
[Mon Oct 13 00:01:11 2008][6980] shared_socket_register(): Error - recv_fd() failed
===

Reusing an ssh connection seems not to be possible. Every call of login_or_reuse_connection() opens a new connection to the target host.
Probably the shared_socket_register(name:"Secret/SSH/socket", socket:soc); from ssh_func.inc is not working ok. shared_socket_register seems to be a libnasl function.


----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=788&group_id=29

From jan-oliver.wagner at intevation.de  Mon Oct 13 09:01:29 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 13 Oct 2008 09:01:29 +0200
Subject: [Openvas-devel] Launch news about 2.0 beta phase and compendium
	RC?
In-Reply-To: <200810130744.56844.timb@nth-dimension.org.uk>
References: <200810091235.35339.jan-oliver.wagner@intevation.de>
	<200810130744.56844.timb@nth-dimension.org.uk>
Message-ID: <200810130901.32019.jan-oliver.wagner@intevation.de>

On Montag, 13. Oktober 2008, Tim Brown wrote:
> On Thursday 09 October 2008 11:35:33 Jan-Oliver Wagner wrote:
> > now that now serious problems occured with the 2.0-beta1 series
> > and a completed compendium I think it is a good time to launch
> > a OpenVAS news.
> >
> > I'd appreciate a quick feedback and dicuss cycle to get the news
> > out rapidely.
> 
> Your announcement looks good.  As I have already mentioned to Michael, I have 
> made significant changes over the weekend, namely fixing the outstanding bugs 
> against the symlink detection code, starting on integrating Solaris local 
> checks, generating packaging for Debian (openvas-{client, libraries, libnasl, 
> server}), regenerating some of the autoconf files etc.  I would therefore 
> suggest a beta2 allowing time to confirm these changes do not cause problems 
> elsewhere and allowing for packaging to be generated for other platforms.  
> How does everyone feel about that?

I'd prefer to handle PR and beta2 independent of each other. We'll need antother
1-2 weeks to get out beta2 and verify it works mostly everywhere.

The message is "beta-phase started" which is already true with beta1.

Apart from this of course we should head for a beta2 :-)

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From michael.wiegand at intevation.de  Mon Oct 13 09:32:05 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Mon, 13 Oct 2008 09:32:05 +0200
Subject: [Openvas-devel] Launch news about 2.0 beta phase and compendium
	RC?
In-Reply-To: <200810130744.56844.timb@nth-dimension.org.uk>
References: <200810091235.35339.jan-oliver.wagner@intevation.de>
	<200810130744.56844.timb@nth-dimension.org.uk>
Message-ID: <200810130932.05160.michael.wiegand@intevation.de>

[Monday 13 October 2008 - 08:44:56] Tim Brown <timb at nth-dimension.org.uk>:
> autoconf files etc.  I would therefore suggest a beta2 allowing time to
> confirm these changes do not cause problems elsewhere and allowing for
> packaging to be generated for other platforms. How does everyone feel about
> that?

I have some things on my todo list that I would like to include in beta2; most 
of them are minor, the only bigger issue is updating the ovaldi support. 

AFAICT, the integration of the patch that would make ovaldi OpenVAS-compatible 
out of the box is still in progress, so I'd rather wait until ovaldi has 
stabilized regarding that before updating the code on the OpenVAS side of 
things.

While I'm quite optimistic that ovaldi should be OpenVAS-compatible by the 
time we hit 2.0, I'm not sure that they can make it in time for beta2. So I 
guess we need to decide if we want to have updated (mostly code-wise, not 
necessarily feature-wise) ovaldi support in beta2 or if this update is 
sufficient at a later date.

Regards,

  Michael

-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From michael.wiegand at intevation.de  Mon Oct 13 12:54:07 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Mon, 13 Oct 2008 12:54:07 +0200
Subject: [Openvas-devel] Voting on Change Request #17
Message-ID: <200810131254.08037.michael.wiegand@intevation.de>

Hello,

I have just added another change request and would like your feedback as well 
as your votes on this issue. You can find the change request at 
http://www.openvas.org/openvas-cr-17.html

Basically this change would enable the client to receive and process 
information on NVT signatures and trust level and display them to the user. 
The ultimate goal is to make the NVT signature process more transparent to 
the user and allow him to ensure NVT trustworthiness for himself as well as 
make the signatures of the NVTs he used in his test available to others.

This change would entail one last change to OTP 1.0.

As always, I'm looking forward to your thoughts on this issue.

Regards,

  Michael

-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From jan-oliver.wagner at intevation.de  Mon Oct 13 14:02:31 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 13 Oct 2008 14:02:31 +0200
Subject: [Openvas-devel] OpenVAS Contest closes soon
Message-ID: <200810131402.33840.jan-oliver.wagner@intevation.de>

Hello,

the OpenVAS Contest[1] "Best Advances for OpenVAS Network Vulnerability Tests"
closes soon (Oct. 15th).

Because it appeared to  be a bit unclear, I'd underline that anyone who
contributed and is not a sponsor(-member) should be considered for the award :-)

From Oct. 16th on the OpenVAS steering comittee and the sponsors will start
to review the contributions. On Oct. 30th winners are announced.

So, anyone who still has something in the queue, commit it or
send to the mailing lists.

Best

	Jan


[1] http://www.openvas.org/openvas-contest.html

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From bernhard.herzog at intevation.de  Mon Oct 13 12:58:07 2008
From: bernhard.herzog at intevation.de (Bernhard Herzog)
Date: Mon, 13 Oct 2008 12:58:07 +0200
Subject: [Openvas-devel] [Openvas-commits] r1507 - in
	trunk/openvas-libnasl: . nasl
In-Reply-To: <20081012002951.40709406FF@pyrosoma.intevation.org>
References: <20081012002951.40709406FF@pyrosoma.intevation.org>
Message-ID: <200810131258.10089.bernhard.herzog@intevation.de>

On 12.10.2008, scm-commit at wald.intevation.org wrote:
> --- trunk/openvas-libnasl/nasl/nasl_cmd_exec.c	2008-10-10 13:56:50 UTC (rev 1506)
> +++ trunk/openvas-libnasl/nasl/nasl_cmd_exec.c	2008-10-12 00:29:50 UTC (rev 1507)
> @@ -20,6 +20,7 @@ 
>    * This file contains all the "unsafe" functions found in NASL
>    */
>  #include <includes.h>
> +#include <glib.h>

AFAICT, the code in nasl_cmd_exec.c depends on anything from glib, so this include
shouldn't be necessary.

> @@ -277,7 +278,7 @@
>      }
>    }
>    fp = fdopen(fd, "r");
> -  if(fp != FALSE) {
> +  if (fp != FALSE) {

Why is the file pointer compared to FALSE?  FALSE is conceptually a boolean and an
int whereas fp is a pointer to FILE.  This doesn't make sense.

Also, since FALSE probably expands to 0, this test is equivalent to
if (fp != NULL).  That doesn't make sense either.
The code as it stands now treats a successful fdopen as an error.

Regards,

  Bernhard

-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081013/43ee0be3/attachment.pgp

From timb at nth-dimension.org.uk  Mon Oct 13 14:43:46 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Mon, 13 Oct 2008 13:43:46 +0100
Subject: [Openvas-devel] [Openvas-commits] r1507 - in
	trunk/openvas-libnasl: . nasl
In-Reply-To: <200810131258.10089.bernhard.herzog@intevation.de>
References: <20081012002951.40709406FF@pyrosoma.intevation.org>
	<200810131258.10089.bernhard.herzog@intevation.de>
Message-ID: <200810131343.46806.timb@nth-dimension.org.uk>

On Monday 13 October 2008 11:58:07 Bernhard Herzog wrote:

> AFAICT, the code in nasl_cmd_exec.c depends on anything from glib, so this
> include shouldn't be necessary.

Well it does at the moment, since I used TRUE and FALSE.

> Why is the file pointer compared to FALSE?  FALSE is conceptually a boolean
> and an int whereas fp is a pointer to FILE.  This doesn't make sense.

Oops well caught.  I was trying to avoid using something such as !fp since I'm 
not a big fan of implicit comparisons.

You can tell this code was written late in to the night :(.

Tim
-- 
Tim Brown
<mailto:timb at nth-dimension.org.uk>
<http://www.nth-dimension.org.uk/>

From bh at intevation.de  Mon Oct 13 15:03:46 2008
From: bh at intevation.de (Bernhard Herzog)
Date: Mon, 13 Oct 2008 15:03:46 +0200
Subject: [Openvas-devel] [Openvas-commits] r1507 - in
	trunk/openvas-libnasl: . nasl
In-Reply-To: <200810131343.46806.timb@nth-dimension.org.uk>
References: <20081012002951.40709406FF@pyrosoma.intevation.org>
	<200810131258.10089.bernhard.herzog@intevation.de>
	<200810131343.46806.timb@nth-dimension.org.uk>
Message-ID: <200810131503.49984.bh@intevation.de>

On 13.10.2008, Tim Brown wrote:
> On Monday 13 October 2008 11:58:07 Bernhard Herzog wrote:
> > AFAICT, the code in nasl_cmd_exec.c depends on anything from glib, so
> > this include shouldn't be necessary.
>
> Well it does at the moment, since I used TRUE and FALSE.

Well, nasl_cmd_exec.c only uses FALSE, and all uses are comparisons with a 
FILE*.  In addition to the one in line 281, there's another one in line 414.

> > Why is the file pointer compared to FALSE?  FALSE is conceptually a
> > boolean and an int whereas fp is a pointer to FILE.  This doesn't make
> > sense.
>
> Oops well caught.  I was trying to avoid using something such as !fp since
> I'm not a big fan of implicit comparisons.
>
> You can tell this code was written late in to the night :(.

Yeah, this kind of thing can happen to anybody.  It might be a good idea to 
take this as an opportunity to extend the NASL test-suite I started in 
openvas-libnasl/test/ a while ago.  Ideally, whenever the NASL interpreter is 
modified and the affected NASL-functions are not already covered by the 
test-suite, a corresponding test should be added before changing the NASL 
interpreter to make sure the behavior at least stays the same.

Regards,

  Bernhard

-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081013/d1e6718e/attachment.pgp

From jan-oliver.wagner at intevation.de  Mon Oct 13 17:24:03 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 13 Oct 2008 17:24:03 +0200
Subject: [Openvas-devel] [Openvas-commits] r1507 - in
	trunk/openvas-libnasl: . nasl
In-Reply-To: <200810131503.49984.bh@intevation.de>
References: <20081012002951.40709406FF@pyrosoma.intevation.org>
	<200810131343.46806.timb@nth-dimension.org.uk>
	<200810131503.49984.bh@intevation.de>
Message-ID: <200810131724.05385.jan-oliver.wagner@intevation.de>

On Montag, 13. Oktober 2008, Bernhard Herzog wrote:
> Yeah, this kind of thing can happen to anybody. ?It might be a good idea to 
> take this as an opportunity to extend the NASL test-suite I started in 
> openvas-libnasl/test/ a while ago. ?Ideally, whenever the NASL interpreter is 
> modified and the affected NASL-functions are not already covered by the 
> test-suite, a corresponding test should be added before changing the NASL 
> interpreter to make sure the behavior at least stays the same.

This is something we should mention in the compendium in the developer's section.

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From bh at intevation.de  Tue Oct 14 15:16:06 2008
From: bh at intevation.de (Bernhard Herzog)
Date: Tue, 14 Oct 2008 15:16:06 +0200
Subject: [Openvas-devel] [Openvas-commits] r1537 - in
	trunk/openvas-libnasl: . nasl
In-Reply-To: <20081013202046.72D09406C7@pyrosoma.intevation.org>
References: <20081013202046.72D09406C7@pyrosoma.intevation.org>
Message-ID: <200810141516.09865.bh@intevation.de>

On 13.10.2008, scm-commit at wald.intevation.org wrote:
> Modified: trunk/openvas-libnasl/nasl/nasl_cmd_exec.c
> ===================================================================
> --- trunk/openvas-libnasl/nasl/nasl_cmd_exec.c	2008-10-13 14:33:58 UTC (rev 1536)
> +++ trunk/openvas-libnasl/nasl/nasl_cmd_exec.c	2008-10-13 20:20:45
> @@ -278,7 +277,7 @@ 
>      }
>    }
>    fp = fdopen(fd, "r");
> -  if (fp != FALSE) {
> +  if (fp == NULL) {
>      close(fp);

The close here and later in fwrite also need to be changed.  It should read

   close(fd);

Regards,

   Bernhard

-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081014/fa4a458e/attachment.pgp

From bh at intevation.de  Tue Oct 14 15:33:19 2008
From: bh at intevation.de (Bernhard Herzog)
Date: Tue, 14 Oct 2008 15:33:19 +0200
Subject: [Openvas-devel] Symlink attacks against fwrite/fread/file_open
	functions
In-Reply-To: <200809291224.58595.timb@nth-dimension.org.uk>
References: <200809291224.58595.timb@nth-dimension.org.uk>
Message-ID: <200810141533.22336.bh@intevation.de>

On 29.09.2008, Tim Brown wrote:
> Because they simply open the requested file without any checks, it is
> possible to carry out symlink attacks against these functions.
>
> I have attached a patch which should I believe resolve the issue but I
> welcome comments before I commit as to whether a) it resolves the issue
> correctly and b) whether it will have unwanted side effects.

The patch seems to be basically what's currently in SVN (rev. 1537 of 
nasl_cmd_exec.c).  My comments refer to what's in SVN.

I don't think it resolves the issue correctly.  For example, if /tmp/foo is 
symlink pointing to bar which does not exist, then the NASL function call 
fwrite("contents", "/tmp/foo") will do this:

 1. lstat on /tmp/foo which succeeds
 2. open("/tmp/foo", O_WRONLY|O_CREAT, 0600)
    This also succeeds and creates bar.

    At this point any damage may already be done, no matter which safety
    checks follow.

Also, the NASL fwrite now behaves differently than before.  The old C code 
used fwrite with mode "w" to open the file which truncates the file.  The new 
code doesn't truncate the file AFAICT (open would need the O_TRUNC flag for 
that).

Regards,

  Bernhard

-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081014/0fd1b74c/attachment.pgp

From lists at securityspace.com  Tue Oct 14 20:42:52 2008
From: lists at securityspace.com (Thomas Reinke)
Date: Tue, 14 Oct 2008 14:42:52 -0400
Subject: [Openvas-devel] [Openvas-commits] r1542 - in
	trunk/openvas-plugins: . scripts
In-Reply-To: <20081014144709.18C994074B@pyrosoma.intevation.org>
References: <20081014144709.18C994074B@pyrosoma.intevation.org>
Message-ID: <48F4E82C.5090407@securityspace.com>

This checkin is breaking about 2500 of our scripts, due to
a change in calling notation for the "rpm" parameter.
Up to now, the rpm parm was required to be of the format
(using the example) "gnutls-utils~1.4.1~3"

The submitted fix changes that to 1.4.1~3.

I believe the fix was trying to address a different
problem we see, introduced by adding newlines to the
rpm kb database.

Unless someone objects, I'd prefer to revert the
parameter calling structure, along with an appropriate
fix to account for the added newlines in the kb.

Issues?

Thomas

> +
> +# Example call: isrpmvuln(pkg:"gnutls-utils", rpm:"1.4.1~3", rls:"FC6")
> +
>  function isrpmvuln(pkg, rpm, rls) {
>      # Check that we have the data for this release.
>      kbrls = get_kb_item("ssh/login/release");
> @@ -27,7 +30,8 @@
>      }
>      rpms = get_kb_item("ssh/login/rpms");
>      if(!rpms) return(0);
> -    pat = string(";(", pkg, "~[^;]+);");
> +#   pat = string(";(", pkg, "~[^;]+);");
> +    pat = string(pkg, "~([^;]+);");
>      matches = eregmatch(pattern:pat, string:rpms);
>      if(isnull(matches)) {
>  	return(0);
> 
> _______________________________________________
> Openvas-commits mailing list
> Openvas-commits at wald.intevation.org
> http://lists.wald.intevation.org/mailman/listinfo/openvas-commits
> 


From lists at securityspace.com  Tue Oct 14 21:15:15 2008
From: lists at securityspace.com (Thomas Reinke)
Date: Tue, 14 Oct 2008 15:15:15 -0400
Subject: [Openvas-devel] [Openvas-commits] r1542 -
 in	trunk/openvas-plugins: . scripts
In-Reply-To: <48F4E82C.5090407@securityspace.com>
References: <20081014144709.18C994074B@pyrosoma.intevation.org>
	<48F4E82C.5090407@securityspace.com>
Message-ID: <48F4EFC3.7050905@securityspace.com>

For reference, I attach the modified function that both
reverts the parameter calling notation and fixes the
bug previously introduced.

Thomas

function isrpmvuln(pkg, rpm, rls) {
     # Check that we have the data for this release.
     kbrls = get_kb_item("ssh/login/release");
     if(kbrls!=rls) {
         return(0);
     }
     rpms = get_kb_item("ssh/login/rpms");
     if(!rpms) return(0);

     # Must include in the package search leading \n or ; to prevent
     # permissive search (e.g. search for 'ash' must not match 'bash')

     pat = string("[\n;](", pkg, "~[^;]+);");
#    pat = string(pkg, "~([^;]+);");
     matches = eregmatch(pattern:pat, string:rpms);
     if(isnull(matches)) {
         return(0);
     }
     rc = revcomp(a:matches[1], b:rpm);
     if(rc<0) {
         norm_pkg = "";
         foreach comp (split(matches[1], sep: "~", keep:0)) {
             norm_pkg = string(norm_pkg,"-",comp);
         }
         norm_pkg = substr(norm_pkg, 1);
         security_note(0, data: "Package " + pkg + " version " +
                 norm_pkg + " is installed which is known to be 
vulnerable.");
         return(1);
     }
     return(0);
}


Thomas Reinke wrote:
> This checkin is breaking about 2500 of our scripts, due to
> a change in calling notation for the "rpm" parameter.
> Up to now, the rpm parm was required to be of the format
> (using the example) "gnutls-utils~1.4.1~3"
> 
> The submitted fix changes that to 1.4.1~3.
> 
> I believe the fix was trying to address a different
> problem we see, introduced by adding newlines to the
> rpm kb database.
> 
> Unless someone objects, I'd prefer to revert the
> parameter calling structure, along with an appropriate
> fix to account for the added newlines in the kb.
> 
> Issues?
> 
> Thomas
> 
>> +
>> +# Example call: isrpmvuln(pkg:"gnutls-utils", rpm:"1.4.1~3", rls:"FC6")
>> +
>>  function isrpmvuln(pkg, rpm, rls) {
>>      # Check that we have the data for this release.
>>      kbrls = get_kb_item("ssh/login/release");
>> @@ -27,7 +30,8 @@
>>      }
>>      rpms = get_kb_item("ssh/login/rpms");
>>      if(!rpms) return(0);
>> -    pat = string(";(", pkg, "~[^;]+);");
>> +#   pat = string(";(", pkg, "~[^;]+);");
>> +    pat = string(pkg, "~([^;]+);");
>>      matches = eregmatch(pattern:pat, string:rpms);
>>      if(isnull(matches)) {
>>  	return(0);
>>
>> _______________________________________________
>> Openvas-commits mailing list
>> Openvas-commits at wald.intevation.org
>> http://lists.wald.intevation.org/mailman/listinfo/openvas-commits
>>
> 
> _______________________________________________
> Openvas-devel mailing list
> Openvas-devel at wald.intevation.org
> http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
> 


From c.koch-mauthe at dn-systems.de  Tue Oct 14 22:19:25 2008
From: c.koch-mauthe at dn-systems.de (Carsten Koch-Mauthe)
Date: Tue, 14 Oct 2008 22:19:25 +0200
Subject: [Openvas-devel] [Openvas-commits] r1542 - in
	trunk/openvas-plugins: . scripts
In-Reply-To: <48F4E82C.5090407@securityspace.com>
References: <20081014144709.18C994074B@pyrosoma.intevation.org>
	<48F4E82C.5090407@securityspace.com>
Message-ID: <200810142219.25751.c.koch-mauthe@dn-systems.de>

Hi Thomas,

> This checkin is breaking about 2500 of our scripts, due to
> a change in calling notation for the "rpm" parameter.

Which scripts are using this inc ?
/openvas-plugins/scripts> grep -i "pkg-lib-rpm.inc" * 
returns zero results on my system.
Do i miss something ?

-- 
Gruss
? ? Carsten Koch-Mauthe
? ? 
?http://www.dn-systems.de ?mail: c.koch-mauthe at dn-systems.de 
?DN-Systems Enterprise Internet Solutions GmbH
?Hornemannstr. 11 31137 Hildesheim, Germany ? ? 
?Tel. +49-5121-28989-0 Fax. +49-5121-28989-11 
?21 Sunrise Ct, S.San Francisco, CA 94080, USA
?Tel. +1-650-472-2512 ?Mob. +1-650-430-1219
?Handelsregister HRB-3213 Amtsgericht Hildesheim
?Gesch?ftsf?hrer Lukas Grunwald

From timb at nth-dimension.org.uk  Tue Oct 14 22:38:46 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Tue, 14 Oct 2008 21:38:46 +0100
Subject: [Openvas-devel] Symlink attacks against fwrite/fread/file_open
	functions
In-Reply-To: <200810141533.22336.bh@intevation.de>
References: <200809291224.58595.timb@nth-dimension.org.uk>
	<200810141533.22336.bh@intevation.de>
Message-ID: <200810142138.46642.timb@nth-dimension.org.uk>

On Tuesday 14 October 2008 14:33:19 Bernhard Herzog wrote:
> On 29.09.2008, Tim Brown wrote:
> > Because they simply open the requested file without any checks, it is
> > possible to carry out symlink attacks against these functions.
> >
> > I have attached a patch which should I believe resolve the issue but I
> > welcome comments before I commit as to whether a) it resolves the issue
> > correctly and b) whether it will have unwanted side effects.
>
> The patch seems to be basically what's currently in SVN (rev. 1537 of
> nasl_cmd_exec.c).  My comments refer to what's in SVN.
>
> I don't think it resolves the issue correctly.  For example, if /tmp/foo is
> symlink pointing to bar which does not exist, then the NASL function call
> fwrite("contents", "/tmp/foo") will do this:
>
>  1. lstat on /tmp/foo which succeeds
>  2. open("/tmp/foo", O_WRONLY|O_CREAT, 0600)
>     This also succeeds and creates bar.

The lstat() function shall be equivalent to stat(), except when path refers to 
a symbolic link. In that case lstat() shall return information about the 
link, while stat() shall return information about the file the link 
references.  If lstat() returns -1, then we know we have neither a file or a 
symlink and can open safely.

If not, we have something there to work with.  By opening it with O_WRONLY|
O_CREAT, in the worst case we create a new file where the symlink points to a 
non-existant file.  Note that by not using O_TRUNC at this stage, existing 
files will not be messed with[1].

We then fstat() the file descriptor and compare its results with that of 
lstat().  If and only if their inode and device tally, i.e. lstat() found a 
file not a symlink, do we convert the file descriptor using fdopen() and 
write.  

The creation of the file is problematic by open(), I'd agree, but we need to 
open it as we wish to use it because otherwise we will get a race condition 
between validating and creating/opening the requested file path.  However, 
since we only create it, if it's not there and since we don't write to it 
until after further checks (and we abort if those checks fail), the worst 
that can be achieved is creating new empty files with the umask and ownership 
of the openvasd if they do not exist.  This seems to be an improvement on 
letting openvasd trample over any and all files.  Don't forget in it's 
current behaviour, it will happily write to the file and indeed this might be 
exploitable in certain cases[2].

Three further changes might be useful:

1) Calling ftruncate() after the fstat() if it is valid to align the function 
with previous behaviour and your comments about O_TRUNC.  This seems sensible 
and I'll make this change.
2) Adding code to remove empty files created by the open() call with O_CREAT. 
This adds lots of additional complications :(.
3) Perhaps we should consider allowing NASL only to write to a directory owned 
by root, group root and with permissions of 700.  This would effectively 
sandbox the attack?

As a side, yes, I should be calling close(fd) if fdopen returns NULL.  This 
will be fixed in my next commit.

I did spot another bug(?) whilst looking into this.  In nasl_file_open:

...
 else if ( strcmp(mode, "w") == 0 )
        imode = O_WRONLY|O_CREAT;
  else if ( strcmp(mode, "w+") == 0 )
        imode = O_WRONLY|O_TRUNC|O_CREAT;
...

According to the Open Group, in the context of libc, both operations should 
truncate the file[3].  This example (along with other modes that 
nasl_file_write() supports) are inconsistant with how people might percieve 
them.

Cheers for the constructive criticism,
Tim

[1] http://www.opengroup.org/onlinepubs/009695399/functions/open.html
[2] /trunk/openvas-plugins/scripts/hydra_options.nasl[4]
[3] http://www.opengroup.org/onlinepubs/009695399/functions/fopen.html
[4] Although you'd need to bruteforce nasl_rand() ;)
-- 
Tim Brown
<mailto:timb at nth-dimension.org.uk>
<http://www.nth-dimension.org.uk/>

From lists at securityspace.com  Tue Oct 14 22:46:28 2008
From: lists at securityspace.com (Thomas Reinke)
Date: Tue, 14 Oct 2008 16:46:28 -0400
Subject: [Openvas-devel] [Openvas-commits] r1542 -
 in	trunk/openvas-plugins: . scripts
In-Reply-To: <200810142219.25751.c.koch-mauthe@dn-systems.de>
References: <20081014144709.18C994074B@pyrosoma.intevation.org>	<48F4E82C.5090407@securityspace.com>
	<200810142219.25751.c.koch-mauthe@dn-systems.de>
Message-ID: <48F50524.1010706@securityspace.com>

Hi,

Currently our existing test suite - see
http://www.securityspace.com/smysecure/index.html (table).

There's Fedora - 1778 scripts,
         Mandrake - 1364 scripts
         RedHat - 1177 scripts

etc. etc (any Local family reliant on rpms is
impacted by this function).

I realize these aren't in OpenVAS at this point in time,
and while OpenVAS should retain priority over any
proprietary scripts, my suggestion would be to avoid
making change to functioning, debugged code simply
for convenience sake.

In this case, several changes already were made (newlines
in gather-package-list.nasl) which introduced a bug (caused
isrpmvuln to break), and then a change was made in isrpmvuln
which introduced a bug by allowing overly permissive regex
pattern matching, causing false positives.

Again, if there's a compelling reason to change something,
fine, let's do it - OpenVAS takes priority.  But arbitrary
structure changes to existing, debugged functions don't
in my mind fall in the category of compelling changes.
(And as witnessed, can have unintended consequences.)

Thomas

Carsten Koch-Mauthe wrote:
> Hi Thomas,
> 
>> This checkin is breaking about 2500 of our scripts, due to
>> a change in calling notation for the "rpm" parameter.
> 
> Which scripts are using this inc ?
> /openvas-plugins/scripts> grep -i "pkg-lib-rpm.inc" * 
> returns zero results on my system.
> Do i miss something ?
> 


From bchandra at secpod.com  Wed Oct 15 07:13:19 2008
From: bchandra at secpod.com (Chandrashekhar B)
Date: Wed, 15 Oct 2008 10:43:19 +0530
Subject: [Openvas-devel] [Openvas-commits] r1542 -
	in	trunk/openvas-plugins: . scripts
In-Reply-To: <48F50524.1010706@securityspace.com>
References: <20081014144709.18C994074B@pyrosoma.intevation.org>	<48F4E82C.5090407@securityspace.com><200810142219.25751.c.koch-mauthe@dn-systems.de>
	<48F50524.1010706@securityspace.com>
Message-ID: <ED16B89FE41540B29DDC1D616ABCA2E5@bchandra>


-----Original Message-----
From: openvas-devel-bounces at wald.intevation.org
[mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Thomas
Reinke
Sent: Wednesday, October 15, 2008 2:16 AM
To: openvas-devel at wald.intevation.org
Subject: Re: [Openvas-devel] [Openvas-commits] r1542 - in
trunk/openvas-plugins: . scripts

> Hi,

> Currently our existing test suite - see
> http://www.securityspace.com/smysecure/index.html (table).

> There's Fedora - 1778 scripts,
>         Mandrake - 1364 scripts
>         RedHat - 1177 scripts

> etc. etc (any Local family reliant on rpms is
> impacted by this function).

We weren't aware of this, searched for pkg-lib-rpm.inc in the entire code to
ensure that nobody was using, before making the changes.

> I realize these aren't in OpenVAS at this point in time,
> and while OpenVAS should retain priority over any
> proprietary scripts, my suggestion would be to avoid
> making change to functioning, debugged code simply
> for convenience sake.

> In this case, several changes already were made (newlines
> in gather-package-list.nasl) which introduced a bug (caused
> isrpmvuln to break), and then a change was made in isrpmvuln
> which introduced a bug by allowing overly permissive regex
> pattern matching, causing false positives.

Newline character was introduced because of an issue we had with regex.
Before making the change, it was discussed in the mailing list. The new
change was not discussed in the list, will ensure that this is done before
making the change. 

> Again, if there's a compelling reason to change something,
> fine, let's do it - OpenVAS takes priority.  But arbitrary
> structure changes to existing, debugged functions don't
> in my mind fall in the category of compelling changes.
> (And as witnessed, can have unintended consequences.)

The reason was that revision comparison revcomp() need only compare versions
and package comparison wasn't required. Before passing to revcomp(), we can
do a package checking and ensure that it is the same package and then pass
to revcomp(). In any case, if you would like to retain that way, it is fine,
it works for us. 

Chandra.


Carsten Koch-Mauthe wrote:
> Hi Thomas,
> 
>> This checkin is breaking about 2500 of our scripts, due to
>> a change in calling notation for the "rpm" parameter.
> 
> Which scripts are using this inc ?
> /openvas-plugins/scripts> grep -i "pkg-lib-rpm.inc" * 
> returns zero results on my system.
> Do i miss something ?
> 

_______________________________________________
Openvas-devel mailing list
Openvas-devel at wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel


From jan-oliver.wagner at intevation.de  Wed Oct 15 09:52:51 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Wed, 15 Oct 2008 09:52:51 +0200
Subject: [Openvas-devel] Voting on Change Request #17
In-Reply-To: <200810131254.08037.michael.wiegand@intevation.de>
References: <200810131254.08037.michael.wiegand@intevation.de>
Message-ID: <200810150952.54060.jan-oliver.wagner@intevation.de>

Hello Michael,

On Montag, 13. Oktober 2008, Michael Wiegand wrote:
> I have just added another change request and would like your feedback as well 
> as your votes on this issue. You can find the change request at 
> http://www.openvas.org/openvas-cr-17.html
> 
> Basically this change would enable the client to receive and process 
> information on NVT signatures and trust level and display them to the user. 
> The ultimate goal is to make the NVT signature process more transparent to 
> the user and allow him to ensure NVT trustworthiness for himself as well as 
> make the signatures of the NVTs he used in his test available to others.
> 
> This change would entail one last change to OTP 1.0.
> 
> As always, I'm looking forward to your thoughts on this issue.

+1 from my side. 

It is important that we get the OTP change as early as possible,
ideally it should already be in beta2.

However, can you propose a explicit new syntax in the
"Design an Implementation" section?
Like it will appear in the documentation of the protocol.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From sgros.ml at gmail.com  Wed Oct 15 12:24:35 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Wed, 15 Oct 2008 12:24:35 +0200
Subject: [Openvas-devel] 64 bit cleanless
Message-ID: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>

Hi!

I don't know if anyone already brought this to the mailing list, but I think
it's important.

While trying to compile trunk version of openvas-libraries on 64-bit fedora
the compiler gets a bunch of the following style warnings:

plugutils.c: In function 'plug_set_id':
plugutils.c:233: warning: cast to pointer from integer of different size

Namely, this concrete line is:

arg_add_value(desc, "ID", ARG_INT, sizeof(int), (void*)id);

which assumes that sizeof(int) is sizeof(void *). Wouldn't it be better to
use this second form instead of first? This of course doesn't solve the
warning, which requires a bit more digging through the code to come up with
appropriate solution.

Is anyone working on this?

Stjepan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081015/36dcfa08/attachment.html

From sgros.ml at gmail.com  Wed Oct 15 13:17:47 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Wed, 15 Oct 2008 13:17:47 +0200
Subject: [Openvas-devel] Root necessary to install openvas plugins...
Message-ID: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>

I have one additional question. Every component of openvas can be compiled
and installed as an ordinary user except openvas-plugins. Is there any
specific reason that installation has to be done with root privileges?

Also, why is it necessary to synchronize plugins before they can be used?
Namely, after installing trunk version of plugins several of them couldn't
be used as some inc files were missing. After update process
(openvas-nvt-sync) only one script failed:

Loading the plugins... 8670 (out of 11462)syntax error, unexpected IDENT,
expecting ';'
Parse error at or near line 40
/opt/fedora/openvas2/lib/openvas/plugins/secpod_rhinosoft_serv-u_dir_trav_and_dos_vuln_900149.nasl
could not be loaded
All plugins loaded

Stjepan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081015/50ca1c4d/attachment.htm

From jan-oliver.wagner at intevation.de  Wed Oct 15 14:45:03 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Wed, 15 Oct 2008 14:45:03 +0200
Subject: [Openvas-devel] Root necessary to install openvas plugins...
In-Reply-To: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>
References: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>
Message-ID: <200810151445.05659.jan-oliver.wagner@intevation.de>

On Mittwoch, 15. Oktober 2008, Stjepan Gros wrote:
> I have one additional question. Every component of openvas can be compiled
> and installed as an ordinary user except openvas-plugins. Is there any
> specific reason that installation has to be done with root privileges?

$ ./configure --help

...
  --enable-install=user   for debugging, install as non-root user
...


this is inherited from Nessus.

> Also, why is it necessary to synchronize plugins before they can be used?

shouldn't  be necessary in principle. Which version of the tar ball did you download?

> Namely, after installing trunk version of plugins several of them couldn't
> be used as some inc files were missing. After update process
> (openvas-nvt-sync) only one script failed:
> 
> Loading the plugins... 8670 (out of 11462)syntax error, unexpected IDENT,
> expecting ';'
> Parse error at or near line 40
> /opt/fedora/openvas2/lib/openvas/plugins/secpod_rhinosoft_serv-u_dir_trav_and_dos_vuln_900149.nasl
> could not be loaded
> All plugins loaded

thanks for the note. Chandra - thats one of yours ... ?

Best

	Jan


-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From bchandra at secpod.com  Wed Oct 15 15:37:28 2008
From: bchandra at secpod.com (Chandrashekhar B)
Date: Wed, 15 Oct 2008 19:07:28 +0530
Subject: [Openvas-devel] Root necessary to install openvas plugins...
In-Reply-To: <200810151445.05659.jan-oliver.wagner@intevation.de>
References: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>
	<200810151445.05659.jan-oliver.wagner@intevation.de>
Message-ID: <9DBC7D38009540169AD9632F380F961A@bchandra>


Issue in secpod_rhinosoft_serv-u_dir_trav_and_dos_vuln_900149.nasl is
already fixed.

Chandra.

-----Original Message-----
From: openvas-devel-bounces at wald.intevation.org
[mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver
Wagner
Sent: Wednesday, October 15, 2008 6:15 PM
To: openvas-devel at wald.intevation.org
Subject: Re: [Openvas-devel] Root necessary to install openvas plugins...

On Mittwoch, 15. Oktober 2008, Stjepan Gros wrote:
> I have one additional question. Every component of openvas can be compiled
> and installed as an ordinary user except openvas-plugins. Is there any
> specific reason that installation has to be done with root privileges?

$ ./configure --help

...
  --enable-install=user   for debugging, install as non-root user
...


this is inherited from Nessus.

> Also, why is it necessary to synchronize plugins before they can be used?

shouldn't  be necessary in principle. Which version of the tar ball did you
download?

> Namely, after installing trunk version of plugins several of them couldn't
> be used as some inc files were missing. After update process
> (openvas-nvt-sync) only one script failed:
> 
> Loading the plugins... 8670 (out of 11462)syntax error, unexpected IDENT,
> expecting ';'
> Parse error at or near line 40
>
/opt/fedora/openvas2/lib/openvas/plugins/secpod_rhinosoft_serv-u_dir_trav_an
d_dos_vuln_900149.nasl
> could not be loaded
> All plugins loaded

thanks for the note. Chandra - thats one of yours ... ?

Best

	Jan


-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
_______________________________________________
Openvas-devel mailing list
Openvas-devel at wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel


From sgros.ml at gmail.com  Wed Oct 15 16:40:17 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Wed, 15 Oct 2008 16:40:17 +0200
Subject: [Openvas-devel] Root necessary to install openvas plugins...
In-Reply-To: <200810151445.05659.jan-oliver.wagner@intevation.de>
References: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>
	<200810151445.05659.jan-oliver.wagner@intevation.de>
Message-ID: <4d7b043c0810150740q55dd928fg77092e4128d308fe@mail.gmail.com>

By mistake I sent this reply only to the poster so I'm resending it...

On Wed, Oct 15, 2008 at 2:45 PM, Jan-Oliver Wagner <
jan-oliver.wagner at intevation.de> wrote:

>
>
> > Also, why is it necessary to synchronize plugins before they can be used?
>
> shouldn't  be necessary in principle. Which version of the tar ball did you
> download?
>

I'm using trunk version. After installing openvas-plugins, but before plugin
update, the openvas-server reports the following errors during startup
process:

# openvasd
Loading the plugins... 1632 (out of 5737)byte_func.inc: No such file or
directory
Loading the plugins... 2193 (out of 5737)smb_file_funcs.inc: No such file or
directory
Loading the plugins... 2601 (out of 5737)smb_file_funcs.inc: No such file or
directory
Loading the plugins... 3213 (out of 5737)slad.inc: No such file or directory
[8673](/opt/fedora/openvas2/lib/openvas/plugins/slad_run.nasl) Undefined
function 'init_add_preferences'
Loading the plugins... 3723 (out of 5737)ssl_funcs.inc: No such file or
directory
Loading the plugins... 5457 (out of 5737)slad.inc: No such file or directory
All plugins loaded

After sync process there are no errors any more (the last commit corrected
the previously reported error).

SG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081015/1d5d06f8/attachment.html

From timb at nth-dimension.org.uk  Wed Oct 15 21:04:47 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Wed, 15 Oct 2008 20:04:47 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
Message-ID: <200810152004.47777.timb@nth-dimension.org.uk>

On Wednesday 15 October 2008 11:24:35 Stjepan Gros wrote:

> Is anyone working on this?

Nope, not on that specific bug.  OpenVAS is doubtless buggy on AMD64 though 
(as was Nessus).  I've seen at least one issue so far - bug #639 - in 
relation to signedness extension, but there are doubtless others.

I run it as my main test rig at work, so it does get tested and those that 
lead to SEGV at least recieve a patch.  Feel free to send a patch for any 
such issues if you can, and I'll see that they are suitably applied.

Or, grab yourself a SVN account (let me know the name, so I can add you to the 
project) and commit away.  64-bit unclean bugs *should* be squashed ;).

Cheers,
Tim
-- 
Tim Brown
<mailto:timb at nth-dimension.org.uk>
<http://www.nth-dimension.org.uk/>

From bh at intevation.de  Wed Oct 15 21:32:04 2008
From: bh at intevation.de (Bernhard Herzog)
Date: Wed, 15 Oct 2008 21:32:04 +0200
Subject: [Openvas-devel] Symlink attacks against fwrite/fread/file_open
	functions
In-Reply-To: <200810142138.46642.timb@nth-dimension.org.uk>
References: <200809291224.58595.timb@nth-dimension.org.uk>
	<200810141533.22336.bh@intevation.de>
	<200810142138.46642.timb@nth-dimension.org.uk>
Message-ID: <200810152132.04473.bh@intevation.de>

On 14.10.2008, Tim Brown wrote:
> On Tuesday 14 October 2008 14:33:19 Bernhard Herzog wrote:
> > On 29.09.2008, Tim Brown wrote:
> > > Because they simply open the requested file without any checks, it is
> > > possible to carry out symlink attacks against these functions.
> > >
> > > I have attached a patch which should I believe resolve the issue but I
> > > welcome comments before I commit as to whether a) it resolves the issue
> > > correctly and b) whether it will have unwanted side effects.
> >
> > The patch seems to be basically what's currently in SVN (rev. 1537 of
> > nasl_cmd_exec.c).  My comments refer to what's in SVN.
> >
> > I don't think it resolves the issue correctly.  For example, if /tmp/foo
> > is symlink pointing to bar which does not exist, then the NASL function
> > call fwrite("contents", "/tmp/foo") will do this:
> >
> >  1. lstat on /tmp/foo which succeeds
> >  2. open("/tmp/foo", O_WRONLY|O_CREAT, 0600)
> >     This also succeeds and creates bar.
>
> The lstat() function shall be equivalent to stat(), except when path refers
> to a symbolic link. In that case lstat() shall return information about the
> link, while stat() shall return information about the file the link
> references. 

> If lstat() returns -1, then we know we have neither a file or 
> a symlink and can open safely.

In that case the file should be opened with the O_EXCL flag. That one really 
does guard agains the symlink attack.  Without O_EXCL there's a race 
condition because the attacker might create the symlink between the calls to 
lstat and open.


> If not, we have something there to work with.  By opening it with O_WRONLY|
> O_CREAT, in the worst case we create a new file where the symlink points to
> a non-existant file.  Note that by not using O_TRUNC at this stage,
> existing files will not be messed with[1].
>
> We then fstat() the file descriptor and compare its results with that of
> lstat().  If and only if their inode and device tally, i.e. lstat() found a
> file not a symlink, do we convert the file descriptor using fdopen() and
> write.
>
> The creation of the file is problematic by open(), I'd agree, but we need
> to open it as we wish to use it because otherwise we will get a race
> condition between validating and creating/opening the requested file path. 
> However, since we only create it, if it's not there and since we don't
> write to it until after further checks (and we abort if those checks fail),
> the worst that can be achieved is creating new empty files with the umask
> and ownership of the openvasd if they do not exist.  This seems to be an
> improvement on letting openvasd trample over any and all files.  Don't
> forget in it's current behaviour, it will happily write to the file and
> indeed this might be exploitable in certain cases[2].
>
> Three further changes might be useful:
>
> 1) Calling ftruncate() after the fstat() if it is valid to align the
> function with previous behaviour and your comments about O_TRUNC.  This
> seems sensible and I'll make this change.
> 2) Adding code to remove empty files created by the open() call with
> O_CREAT. This adds lots of additional complications :(.
> 3) Perhaps we should consider allowing NASL only to write to a directory
> owned by root, group root and with permissions of 700.  This would
> effectively sandbox the attack?
>
> As a side, yes, I should be calling close(fd) if fdopen returns NULL.  This
> will be fixed in my next commit.
>
> I did spot another bug(?) whilst looking into this.  In nasl_file_open:
>
> ...
>  else if ( strcmp(mode, "w") == 0 )
>         imode = O_WRONLY|O_CREAT;
>   else if ( strcmp(mode, "w+") == 0 )
>         imode = O_WRONLY|O_TRUNC|O_CREAT;
> ...
>
> According to the Open Group, in the context of libc, both operations should
> truncate the file[3].  This example (along with other modes that
> nasl_file_write() supports) are inconsistant with how people might percieve
> them.
>
> Cheers for the constructive criticism,
> Tim
>
> [1] http://www.opengroup.org/onlinepubs/009695399/functions/open.html
> [2] /trunk/openvas-plugins/scripts/hydra_options.nasl[4]
> [3] http://www.opengroup.org/onlinepubs/009695399/functions/fopen.html
> [4] Although you'd need to bruteforce nasl_rand() ;)



-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From sgros.ml at gmail.com  Wed Oct 15 21:54:03 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Wed, 15 Oct 2008 21:54:03 +0200
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <200810152004.47777.timb@nth-dimension.org.uk>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<200810152004.47777.timb@nth-dimension.org.uk>
Message-ID: <4d7b043c0810151254p16bae024pa4fc2a3dd6ef4313@mail.gmail.com>

On Wed, Oct 15, 2008 at 9:04 PM, Tim Brown <timb at nth-dimension.org.uk>wrote:

> On Wednesday 15 October 2008 11:24:35 Stjepan Gros wrote:
>
> > Is anyone working on this?
>
> Nope, not on that specific bug.  OpenVAS is doubtless buggy on AMD64 though
> (as was Nessus).  I've seen at least one issue so far - bug #639 - in
> relation to signedness extension, but there are doubtless others.
>
> I run it as my main test rig at work, so it does get tested and those that
> lead to SEGV at least recieve a patch.  Feel free to send a patch for any
> such issues if you can, and I'll see that they are suitably applied.
>
> Or, grab yourself a SVN account (let me know the name, so I can add you to
> the
> project) and commit away.  64-bit unclean bugs *should* be squashed ;).


I can not promise that I'll do much so I'll not create svn account for now.
Still, as I would like to use openvas on my laptop I'll try to clean a bit
the code.

Attached is a small patch that changes sizeof(int) into sizeof(void *), and
uses casting to eliminate warnings in a single file. I also changed length
parameter type from long to in in fuction arg_add_value beacuse 2^31 should
be enough for all the values of this parameter and on 64-bit platform long
is 64 bits - I believe to much. Still, this change is negligable.

But the main question is: I saw that glib is used in openvas-server. Does
this means that glib is ok to use in other subsystems? If yes, than the most
elegant way to handle 64/32 bits is via glib's macros.

Also, are there any coding guidelines I should follow when modifying the
code?

SG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081015/d5520c67/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-libraries-64bit-v01.patch
Type: text/x-patch
Size: 9499 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081015/d5520c67/openvas-libraries-64bit-v01.bin

From timb at nth-dimension.org.uk  Wed Oct 15 22:45:12 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Wed, 15 Oct 2008 21:45:12 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0810151254p16bae024pa4fc2a3dd6ef4313@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<200810152004.47777.timb@nth-dimension.org.uk>
	<4d7b043c0810151254p16bae024pa4fc2a3dd6ef4313@mail.gmail.com>
Message-ID: <200810152145.12441.timb@nth-dimension.org.uk>

On Wednesday 15 October 2008 20:54:03 Stjepan Gros wrote:

> I can not promise that I'll do much so I'll not create svn account for now.
> Still, as I would like to use openvas on my laptop I'll try to clean a bit
> the code.

Not a problem, even little patches can help.

> Attached is a small patch that changes sizeof(int) into sizeof(void *), and
> uses casting to eliminate warnings in a single file. I also changed length
> parameter type from long to in in fuction arg_add_value beacuse 2^31 should
> be enough for all the values of this parameter and on 64-bit platform long
> is 64 bits - I believe to much. Still, this change is negligable.

I'll have a look at it shortly.

> But the main question is: I saw that glib is used in openvas-server. Does
> this means that glib is ok to use in other subsystems? If yes, than the
> most elegant way to handle 64/32 bits is via glib's macros.

I could give a long answer but ultimately the answer is yes.  If you want the 
background to our introduction of glib as a dependency, I would recommend 
taking a look at http://www.openvas.org/openvas-cr-9.html.  Essentially, 
OpenVAS has lots of cases of repeated code.  A goal is to replace them with 
tried and tested code from glib.

> Also, are there any coding guidelines I should follow when modifying the
> code?

If you spend enough time staring at the different conventions used when it was 
Nessus your eyes will bleed.  I tend to use the style of the file or function 
(;)) I am modifying.  I personally prefer explicit checks such as "if (blah 
== TRUE)" opposed to "if (blah)".  There are some excellent recommendations 
in the openvas-compendium module in the "Developers Guide for OpenVAS Server 
and Client" chapter and finally, there is a stub header in the doc module for 
new files.

Tim
-- 
Tim Brown
<mailto:timb at nth-dimension.org.uk>
<http://www.nth-dimension.org.uk/>

From michael.wiegand at intevation.de  Thu Oct 16 11:43:00 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Thu, 16 Oct 2008 11:43:00 +0200
Subject: [Openvas-devel] Voting on Change Request #17
In-Reply-To: <200810150952.54060.jan-oliver.wagner@intevation.de>
References: <200810131254.08037.michael.wiegand@intevation.de>
	<200810150952.54060.jan-oliver.wagner@intevation.de>
Message-ID: <200810161143.00626.michael.wiegand@intevation.de>

[Wednesday 15 October 2008 - 09:52:51] "Jan-Oliver Wagner" 
<jan-oliver.wagner at intevation.de>:
> However, can you propose a explicit new syntax in the
> "Design an Implementation" section?
> Like it will appear in the documentation of the protocol.

I have updated the CR with my proposal for the protocol commands, let me know 
what you think.

We have yet to decided the format/encoding for the certificate in the OTP 
response; just taking the binary certificate and putting it in the response 
is probably asking for trouble with the current implementation, so we should 
at least ASCII-armor it, shouldn't we?

Regards,

  Michael

-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From felix.wolfsteller at intevation.de  Thu Oct 16 12:53:54 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Thu, 16 Oct 2008 12:53:54 +0200
Subject: [Openvas-devel] openvas-server: svn remove openvasd/nsp.c
Message-ID: <200810161253.54569.felix.wolfsteller@intevation.de>

Hi
I just stumbled over nsp.c  in [openvas-server/]opvenvasd/.
I cannot see it included somewhere and its content is a bit *cough* 
nonverbose.

...
GPL
...
#ifndef __NESSUSD_NSP_H__
#define __NESSUSD_NSP_H__
#endif /* NESSUSD_NSP_H_ */
(EOF)

Removing it does not break the built-process.
Will be removed from the svn, if nobody has objections.

Felix


-- 
Felix Wolfsteller |  ++49-541-335 08 3451  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From sgros.ml at gmail.com  Thu Oct 16 19:04:55 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Thu, 16 Oct 2008 19:04:55 +0200
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <200810152145.12441.timb@nth-dimension.org.uk>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<200810152004.47777.timb@nth-dimension.org.uk>
	<4d7b043c0810151254p16bae024pa4fc2a3dd6ef4313@mail.gmail.com>
	<200810152145.12441.timb@nth-dimension.org.uk>
Message-ID: <4d7b043c0810161004h1e86c9cbr86cd45d8d13ced1c@mail.gmail.com>

On Wed, Oct 15, 2008 at 10:45 PM, Tim Brown <timb at nth-dimension.org.uk>wrote:

> On Wednesday 15 October 2008 20:54:03 Stjepan Gros wrote:
>
>
> > Attached is a small patch that changes sizeof(int) into sizeof(void *),
> and
> > uses casting to eliminate warnings in a single file. I also changed
> length
> > parameter type from long to in in fuction arg_add_value beacuse 2^31
> should
> > be enough for all the values of this parameter and on 64-bit platform
> long
> > is 64 bits - I believe to much. Still, this change is negligable.
>
> I'll have a look at it shortly.
>
> > But the main question is: I saw that glib is used in openvas-server. Does
> > this means that glib is ok to use in other subsystems? If yes, than the
> > most elegant way to handle 64/32 bits is via glib's macros.
>
> I could give a long answer but ultimately the answer is yes.  If you want
> the
> background to our introduction of glib as a dependency, I would recommend
> taking a look at http://www.openvas.org/openvas-cr-9.html.  Essentially,
> OpenVAS has lots of cases of repeated code.  A goal is to replace them with
> tried and tested code from glib.


Ok, I went throught the code and included GLib in those subsystems that
didn't use it yet. I then inserted GPOINTER_TO_SIZE instead of (int) and
GSIZE_TO_POINTER instead of (void *). Furthermore, every occurence of
sizeof(int) I changed into sizeof(gpointer). There were few places where
sizeof(variable) was used, but I converted them also to sizeof(gpointer) as
it's the real size that is handed into the function. Few other omissions
were also corrected (but look into patches for them). The patches are
attached, and where ever configure.in has changed, aclocal && autoconf have
to be rerun.

Here is a summary of additional problems I noticed:

files harglist.* are duplicated in client and in the openvas-libraries? i
suppose the version in client should be removed. also, it seems as if the
one in libraries is newer (according to changes I had to make).

compiling libaries
==============
configure gives the following warning:

config.status: WARNING:  openvas.tmpl.in seems to ignore the --datarootdir
setting


compiling libnasl
=============

also configure warning:

config.status: WARNING:  nasl.tmpl.in seems to ignore the --datarootdir
setting

but there is the following warning that someone else should look:

strutils.c:50: warning: suggest parentheses around && within ||

large number of the following style warnings:

*** Warning: inferring the mode of operation is deprecated.
*** Future versions of Libtool will require --mode=MODE be specified.

compiling server
=============
config.status: creating openvas.tmpl
config.status: WARNING:  openvas.tmpl.in seems to ignore the --datarootdir
setting
config.status: creating include/corevers.h
config.status: creating openvas-adduser
config.status: WARNING:  openvas-adduser.in seems to ignore the
--datarootdir setting
config.status: creating openvas-rmuser
config.status: creating openvas-mkcert
config.status: WARNING:  openvas-mkcert.in seems to ignore the --datarootdir
setting
config.status: creating openvas-mkcert-client
config.status: WARNING:  openvas-mkcert-client.in seems to ignore the
--datarootdir setting

Furthermore, while doing 'make distclean' the file openvasd-server is not
removed

plugins
======
config.status: creating openvas.tmpl
config.status: WARNING:  openvas.tmpl.in seems to ignore the --datarootdir
setting

client
====
config.status: creating nessus.tmpl
config.status: WARNING:  nessus.tmpl.in seems to ignore the --datarootdir
setting
config.status: creating include/corevers.h
config.status: creating openvasclient-mkcert
config.status: WARNING:  openvasclient-mkcert.in seems to ignore the
--datarootdir setting


That's it for now. Tomarrow I'll test it more and in the mean time I'm
waiting for comments on the patche.

SG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081016/d88e495d/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-client-64bit-v00.patch
Type: text/x-patch
Size: 22655 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081016/d88e495d/openvas-client-64bit-v00-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-libnasl-64bit-v00.patch
Type: text/x-patch
Size: 37087 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081016/d88e495d/openvas-libnasl-64bit-v00-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-libraries-64bit-v00.patch
Type: text/x-patch
Size: 18225 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081016/d88e495d/openvas-libraries-64bit-v00-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-plugins-64bit-v00.patch
Type: text/x-patch
Size: 13106 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081016/d88e495d/openvas-plugins-64bit-v00-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-server-64bit-v00.patch
Type: text/x-patch
Size: 18714 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081016/d88e495d/openvas-server-64bit-v00-0001.bin

From jan-oliver.wagner at intevation.de  Thu Oct 16 23:31:12 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 16 Oct 2008 23:31:12 +0200
Subject: [Openvas-devel] openvas-server: svn remove openvasd/nsp.c
In-Reply-To: <200810161253.54569.felix.wolfsteller@intevation.de>
References: <200810161253.54569.felix.wolfsteller@intevation.de>
Message-ID: <200810162331.16151.jan-oliver.wagner@intevation.de>

On Thursday 16 October 2008 12:53, Felix Wolfsteller wrote:
> I just stumbled over nsp.c  in [openvas-server/]opvenvasd/.

you mean nsp.h.

> I cannot see it included somewhere and its content is a bit *cough*
> nonverbose.
>
> ...
> GPL
> ...
> #ifndef __NESSUSD_NSP_H__
> #define __NESSUSD_NSP_H__
> #endif /* NESSUSD_NSP_H_ */
> (EOF)
>
> Removing it does not break the built-process.
> Will be removed from the svn, if nobody has objections.

yes, please remove it. Don't forget to update the MANIFEST file.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                                   Intevation GmbH
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From jan-oliver.wagner at intevation.de  Thu Oct 16 23:41:22 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 16 Oct 2008 23:41:22 +0200
Subject: [Openvas-devel] Voting on Change Request #17
In-Reply-To: <200810161143.00626.michael.wiegand@intevation.de>
References: <200810131254.08037.michael.wiegand@intevation.de>
	<200810150952.54060.jan-oliver.wagner@intevation.de>
	<200810161143.00626.michael.wiegand@intevation.de>
Message-ID: <200810162341.26416.jan-oliver.wagner@intevation.de>

On Thursday 16 October 2008 11:43, Michael Wiegand wrote:
> I have updated the CR with my proposal for the protocol commands, let me
> know what you think.

I would drop "0x" for the sigs.

> We have yet to decided the format/encoding for the certificate in the OTP
> response; just taking the binary certificate and putting it in the response
> is probably asking for trouble with the current implementation, so we
> should at least ASCII-armor it, shouldn't we?

yes, makes sense.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                                   Intevation GmbH
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From jan-oliver.wagner at intevation.de  Thu Oct 16 23:48:03 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 16 Oct 2008 23:48:03 +0200
Subject: [Openvas-devel] Root necessary to install openvas plugins...
In-Reply-To: <4d7b043c0810150740q55dd928fg77092e4128d308fe@mail.gmail.com>
References: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>
	<200810151445.05659.jan-oliver.wagner@intevation.de>
	<4d7b043c0810150740q55dd928fg77092e4128d308fe@mail.gmail.com>
Message-ID: <200810162348.05635.jan-oliver.wagner@intevation.de>

On Wednesday 15 October 2008 16:40, Stjepan Gros wrote:
> I'm using trunk version. After installing openvas-plugins, but before
> plugin update, the openvas-server reports the following errors during
> startup process:
>
> # openvasd
> Loading the plugins... 1632 (out of 5737)byte_func.inc: No such file or
> directory
> Loading the plugins... 2193 (out of 5737)smb_file_funcs.inc: No such file
> or directory
> Loading the plugins... 2601 (out of 5737)smb_file_funcs.inc: No such file
> or directory
> Loading the plugins... 3213 (out of 5737)slad.inc: No such file or
> directory [8673](/opt/fedora/openvas2/lib/openvas/plugins/slad_run.nasl)
> Undefined function 'init_add_preferences'
> Loading the plugins... 3723 (out of 5737)ssl_funcs.inc: No such file or
> directory
> Loading the plugins... 5457 (out of 5737)slad.inc: No such file or
> directory All plugins loaded
>
> After sync process there are no errors any more (the last commit corrected
> the previously reported error).

this is probably because your cache still contains the plugins and they are no
parsed again and thus no errors reported.

Best

	Jan
 
-- 
Dr. Jan-Oliver Wagner                                   Intevation GmbH
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From sgros.ml at gmail.com  Fri Oct 17 09:03:44 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Fri, 17 Oct 2008 09:03:44 +0200
Subject: [Openvas-devel] Root necessary to install openvas plugins...
In-Reply-To: <200810162348.05635.jan-oliver.wagner@intevation.de>
References: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>
	<200810151445.05659.jan-oliver.wagner@intevation.de>
	<4d7b043c0810150740q55dd928fg77092e4128d308fe@mail.gmail.com>
	<200810162348.05635.jan-oliver.wagner@intevation.de>
Message-ID: <4d7b043c0810170003y3928bfdfi5dc5e41eabe16abf@mail.gmail.com>

On Thu, Oct 16, 2008 at 11:48 PM, Jan-Oliver Wagner <
jan-oliver.wagner at intevation.de> wrote:

> On Wednesday 15 October 2008 16:40, Stjepan Gros wrote:
> > I'm using trunk version. After installing openvas-plugins, but before
> > plugin update, the openvas-server reports the following errors during
> > startup process:
> >
> > # openvasd
> > Loading the plugins... 1632 (out of 5737)byte_func.inc: No such file or
> > directory
> > Loading the plugins... 2193 (out of 5737)smb_file_funcs.inc: No such file
> > or directory
> > Loading the plugins... 2601 (out of 5737)smb_file_funcs.inc: No such file
> > or directory
> > Loading the plugins... 3213 (out of 5737)slad.inc: No such file or
> > directory [8673](/opt/fedora/openvas2/lib/openvas/plugins/slad_run.nasl)
> > Undefined function 'init_add_preferences'
> > Loading the plugins... 3723 (out of 5737)ssl_funcs.inc: No such file or
> > directory
> > Loading the plugins... 5457 (out of 5737)slad.inc: No such file or
> > directory All plugins loaded
> >
> > After sync process there are no errors any more (the last commit
> corrected
> > the previously reported error).
>
> this is probably because your cache still contains the plugins and they are
> no
> parsed again and thus no errors reported.
>

I install openvas in a separate, empty, directory. So I removed this
directory and reinstalled all from scratch. Starting openvasd produces again
the same error messages. As for cache, I assume that it's the .desc
subdirectory in plugins directory. The error messages are:

# openvasd
Loading the plugins... 306 (out of 5754)slad.inc: No such file or directory
Loading the plugins... 1683 (out of 5754)byte_func.inc: No such file or
directory
Loading the plugins... 2142 (out of 5754)ssl_funcs.inc: No such file or
directory
Loading the plugins... 3213 (out of 5754)slad.inc: No such file or directory
[13652](/opt/fedora/openvas2//lib/openvas/plugins/slad_run.nasl) Undefined
function 'init_add_preferences'
Loading the plugins... 4947 (out of 5754)smb_file_funcs.inc: No such file or
directory
Loading the plugins... 5559 (out of 5754)smb_file_funcs.inc: No such file or
directory
All plugins loaded

Anyway, the inc files that are displayed are used inside nasl files, but are
not present in the SVN trunk.

And now I know why there are no error messages after synchronization.
Synchronization didn't correct the errors but openvasd remembered faulty
plugins in cache and doesn't try to load them again. So basically, these
error messages are persistant.

SG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081017/4322ea5a/attachment.htm

From sgros.ml at gmail.com  Fri Oct 17 09:14:21 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Fri, 17 Oct 2008 09:14:21 +0200
Subject: [Openvas-devel] Root necessary to install openvas plugins...
In-Reply-To: <4d7b043c0810170003y3928bfdfi5dc5e41eabe16abf@mail.gmail.com>
References: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>
	<200810151445.05659.jan-oliver.wagner@intevation.de>
	<4d7b043c0810150740q55dd928fg77092e4128d308fe@mail.gmail.com>
	<200810162348.05635.jan-oliver.wagner@intevation.de>
	<4d7b043c0810170003y3928bfdfi5dc5e41eabe16abf@mail.gmail.com>
Message-ID: <4d7b043c0810170014o4e45238eg46fd5401c2768cd6@mail.gmail.com>

On Fri, Oct 17, 2008 at 9:03 AM, Stjepan Gros <sgros.ml at gmail.com> wrote:

>
>
> On Thu, Oct 16, 2008 at 11:48 PM, Jan-Oliver Wagner <
> jan-oliver.wagner at intevation.de> wrote:
>
>> On Wednesday 15 October 2008 16:40, Stjepan Gros wrote:
>> > I'm using trunk version. After installing openvas-plugins, but before
>> > plugin update, the openvas-server reports the following errors during
>> > startup process:
>> >
>> > # openvasd
>> > Loading the plugins... 1632 (out of 5737)byte_func.inc: No such file or
>> > directory
>> > Loading the plugins... 2193 (out of 5737)smb_file_funcs.inc: No such
>> file
>> > or directory
>> > Loading the plugins... 2601 (out of 5737)smb_file_funcs.inc: No such
>> file
>> > or directory
>> > Loading the plugins... 3213 (out of 5737)slad.inc: No such file or
>> > directory [8673](/opt/fedora/openvas2/lib/openvas/plugins/slad_run.nasl)
>> > Undefined function 'init_add_preferences'
>> > Loading the plugins... 3723 (out of 5737)ssl_funcs.inc: No such file or
>> > directory
>> > Loading the plugins... 5457 (out of 5737)slad.inc: No such file or
>> > directory All plugins loaded
>> >
>> > After sync process there are no errors any more (the last commit
>> corrected
>> > the previously reported error).
>>
>> this is probably because your cache still contains the plugins and they
>> are no
>> parsed again and thus no errors reported.
>>
>
> I install openvas in a separate, empty, directory. So I removed this
> directory and reinstalled all from scratch. Starting openvasd produces again
> the same error messages. As for cache, I assume that it's the .desc
> subdirectory in plugins directory. The error messages are:
>
> # openvasd
> Loading the plugins... 306 (out of 5754)slad.inc: No such file or directory
> Loading the plugins... 1683 (out of 5754)byte_func.inc: No such file or
> directory
> Loading the plugins... 2142 (out of 5754)ssl_funcs.inc: No such file or
> directory
> Loading the plugins... 3213 (out of 5754)slad.inc: No such file or
> directory
> [13652](/opt/fedora/openvas2//lib/openvas/plugins/slad_run.nasl) Undefined
> function 'init_add_preferences'
> Loading the plugins... 4947 (out of 5754)smb_file_funcs.inc: No such file
> or directory
> Loading the plugins... 5559 (out of 5754)smb_file_funcs.inc: No such file
> or directory
> All plugins loaded
>
> Anyway, the inc files that are displayed are used inside nasl files, but
> are not present in the SVN trunk.
>
> And now I know why there are no error messages after synchronization.
> Synchronization didn't correct the errors but openvasd remembered faulty
> plugins in cache and doesn't try to load them again. So basically, these
> error messages are persistant.
>

And while we are at a cache for the plugins, I don't think that storing
cache within ${prefix}/lib/plugins is a good practice for two reasons:

1. lib is architecture specific
2. lib resides in a potentially read-only filesystem

I believe that plugins should go into share subdirectory (meant for platform
independent, read-only files) and cache should go somewhere in /var.

I looked into configure switches (server, libraries, libnasl) but couldn't
find the ones that would allow control of those directories.

SG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081017/0d477b53/attachment-0001.html

From jan-oliver.wagner at intevation.de  Fri Oct 17 09:19:00 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 17 Oct 2008 09:19:00 +0200
Subject: [Openvas-devel] Root necessary to install openvas plugins...
In-Reply-To: <4d7b043c0810170014o4e45238eg46fd5401c2768cd6@mail.gmail.com>
References: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>
	<4d7b043c0810170003y3928bfdfi5dc5e41eabe16abf@mail.gmail.com>
	<4d7b043c0810170014o4e45238eg46fd5401c2768cd6@mail.gmail.com>
Message-ID: <200810170919.02509.jan-oliver.wagner@intevation.de>

On Freitag, 17. Oktober 2008, Stjepan Gros wrote:
> And while we are at a cache for the plugins, I don't think that storing
> cache within ${prefix}/lib/plugins is a good practice for two reasons:
> 
> 1. lib is architecture specific
> 2. lib resides in a potentially read-only filesystem
> 
> I believe that plugins should go into share subdirectory (meant for platform
> independent, read-only files) and cache should go somewhere in /var.
> 
> I looked into configure switches (server, libraries, libnasl) but couldn't
> find the ones that would allow control of those directories.

it is definitely a bad design to store the cache where it is stored currently.
This design is inherited from Nessus.

However, I do see the need to make a more comprehensive change
of the design here, namely to introduce a file tree for the NVTs
instead a flat structure.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From michael.wiegand at intevation.de  Fri Oct 17 10:23:50 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Fri, 17 Oct 2008 10:23:50 +0200
Subject: [Openvas-devel] Planning 1.0-rc2 of OpenVAS Compendium
Message-ID: <200810171023.50352.michael.wiegand@intevation.de>

Hello,

over the last few weeks we have finished translating the compendium into 
German and fixed some minor issues with the English rc1.

I would like to take this opportunity to release another RC, this time 
including the German version. If there is anything you would like to include 
in rc2 but haven't committed yet, now is a good time. :)

We are still doing some minor changes, but should be done by this afternoon.
If there are no serious issues with this release I'd like to do it on Monday.

Regards,

  Michael
-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From felix.wolfsteller at intevation.de  Fri Oct 17 14:20:38 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Fri, 17 Oct 2008 14:20:38 +0200
Subject: [Openvas-devel] openvas-client: patch to fix small memory leak
Message-ID: <200810171420.38242.felix.wolfsteller@intevation.de>

Hi
attached are two patches.
The first renames a local variable and peels an if- onion (was done to keep 
compatibilty to an age-old version, i guess).
The second checks for parsing errors when plugin- info is received.
Frees allocated strings, if an error occured.
Ready to commit
-- felix

ChangeLog
* nessus/comm.c (parse_plugin): Removed memory leak (were NULL returns,
without taking care of emalloc'd strings), cleanup.



-- 
Felix Wolfsteller |  ++49-541-335 08 3451  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_comm_patch0.patch
Type: text/x-diff
Size: 2540 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081017/74a31943/client_comm_patch0.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client_comm_patch1.patch
Type: text/x-diff
Size: 2689 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081017/74a31943/client_comm_patch1.bin

From bh at intevation.de  Fri Oct 17 14:53:06 2008
From: bh at intevation.de (Bernhard Herzog)
Date: Fri, 17 Oct 2008 14:53:06 +0200
Subject: [Openvas-devel] openvas-client: patch to fix small memory leak
In-Reply-To: <200810171420.38242.felix.wolfsteller@intevation.de>
References: <200810171420.38242.felix.wolfsteller@intevation.de>
Message-ID: <200810171453.09121.bh@intevation.de>

Hi,

Felix Wolfsteller <felix.wolfsteller at intevation.de> writes:
> --- 0/comm.c	2008-10-17 09:24:59.725068737 +0200
> +++ client_svn/nessus/comm.c	2008-10-17 11:27:37.501520328 +0200
> @@ -129,11 +129,12 @@
>   * plugin in it.
>   */
>  static struct nessus_plugin *
> -parse_plugin(char * buf)
> +parse_plugin(buf)
> +  char *buf;
>  {

At first I thought you proposed to introduce more K&R style function 
definitions and variables named "l".  But it seems the you produced the patch 
in reverse order.  If that's the case the patch looks OK.

The easiest way to produce patches in the correct order is to simply modify 
the code in an SVN working copy and use the "svn diff" command.  That would 
have the additional benefit of including the SVN revision in the diff.


   Bernhard

-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081017/0fd987a1/attachment.pgp

From michael.wiegand at intevation.de  Fri Oct 17 16:21:14 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Fri, 17 Oct 2008 16:21:14 +0200
Subject: [Openvas-devel] Path towards CR#16
In-Reply-To: <200810101525.05618.felix.wolfsteller@intevation.de>
References: <200810101525.05618.felix.wolfsteller@intevation.de>
Message-ID: <200810171621.14167.michael.wiegand@intevation.de>

[Friday 10 October 2008 - 15:25:05] Felix Wolfsteller 
<felix.wolfsteller at intevation.de>:
> 	* nessus/comm.c (fetch_new_plugins, fetch_new_plugins): Counts new
> 	plugins based on the return value of context_add_plugin, displays
> 	info to user

I'm updating the German translation right now and found that the way the count 
is displayed ("Found and %s %d new %s." in nessus/comm.c:1100 and 
nessus/comm.c:1293) makes it somewhat difficult to translate correctly, at 
least for German. Could you change the display to something that allows 
easier translation?

Regards,

  Michael
-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From jan-oliver.wagner at intevation.de  Fri Oct 17 16:56:01 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 17 Oct 2008 16:56:01 +0200
Subject: [Openvas-devel] Root necessary to install openvas plugins...
In-Reply-To: <4d7b043c0810170003y3928bfdfi5dc5e41eabe16abf@mail.gmail.com>
References: <4d7b043c0810150417p7fbe1eb3t9b38eadd243d4ab3@mail.gmail.com>
	<200810162348.05635.jan-oliver.wagner@intevation.de>
	<4d7b043c0810170003y3928bfdfi5dc5e41eabe16abf@mail.gmail.com>
Message-ID: <200810171656.03249.jan-oliver.wagner@intevation.de>

On Freitag, 17. Oktober 2008, Stjepan Gros wrote:
> Anyway, the inc files that are displayed are used inside nasl files, but are
> not present in the SVN trunk.

this is because the inc files are proprietary and thus were not inherited
from Nessus.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From sgros.ml at gmail.com  Sat Oct 18 23:35:33 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Sat, 18 Oct 2008 23:35:33 +0200
Subject: [Openvas-devel] Reorganizing plugins...
Message-ID: <4d7b043c0810181435j69e70b15x415a512fc79d534d@mail.gmail.com>

Attached is a patch that allows openvas to recursively scan directory in
search for plugins. Additionaly, include files can be in a separate
subdirectory which is specified in the conf. file using include_folder
statement, e.g. include_folder = /tmp. The patch is against latest trunk
r1568.

The patch won't change behaviour of openvas if flat directory structure is
used. Still, there are problems that I have to resolve:

1. only one include and one plugin directory can be specified

2. i have problems loading deb_*.nasl files if they are placed in separate
subdirectory, it's not caused by missing includes but something else is a
problem. i'll have to investigate this more.There are other plugins with the
same problem.

3. .desc subdirectory is still in the same directory as the associated
plugin

4. include files in the same directory as plugins, but not in the main
plugin directory, won't be found, at least I think because I didn't test
this

Be aware that tt might happen that I mixed this change with the patch to
remove warnings when compiling 64bits.

The plan to proceed is as follows:

1. debug this version

2. introduce multiple include folders

3. introduce multiple plugin folders

4. move .desc into separate tree

And two questions for the end:

1.  while working on this I noted that the maximum number of plugins is
restricted with the constant MAX_FILES to somwhere near 5000 files. Is this
correct?

2. why is for file list some form of hashing used? i changed this to a
simple linked list, but maybe I missed something?

SG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081018/1a7db562/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugin-dir-v00.patch
Type: text/x-patch
Size: 15105 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081018/1a7db562/plugin-dir-v00.bin

From felix.wolfsteller at intevation.de  Mon Oct 20 08:48:51 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Mon, 20 Oct 2008 08:48:51 +0200
Subject: [Openvas-devel] openvas-client: patch to fix small memory leak
In-Reply-To: <200810171453.09121.bh@intevation.de>
References: <200810171420.38242.felix.wolfsteller@intevation.de>
	<200810171453.09121.bh@intevation.de>
Message-ID: <200810200848.51648.felix.wolfsteller@intevation.de>

Hi
sure; you are right, 1) first patch was diff'ed in wrong direction, my fault 
2) could have done at least the first patch with svn diff.
felix

On Friday 17 October 2008 14:53:06 Bernhard Herzog wrote:
> Hi,
>
> Felix Wolfsteller <felix.wolfsteller at intevation.de> writes:
> > --- 0/comm.c	2008-10-17 09:24:59.725068737 +0200
> > +++ client_svn/nessus/comm.c	2008-10-17 11:27:37.501520328 +0200
> > @@ -129,11 +129,12 @@
> >   * plugin in it.
> >   */
> >  static struct nessus_plugin *
> > -parse_plugin(char * buf)
> > +parse_plugin(buf)
> > +  char *buf;
> >  {
>
> At first I thought you proposed to introduce more K&R style function
> definitions and variables named "l".  But it seems the you produced the
> patch in reverse order.  If that's the case the patch looks OK.
>
> The easiest way to produce patches in the correct order is to simply modify
> the code in an SVN working copy and use the "svn diff" command.  That would
> have the additional benefit of including the SVN revision in the diff.
>
>
>    Bernhard


-- 
Felix Wolfsteller |  ++49-541-335 08 3451  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From felix.wolfsteller at intevation.de  Mon Oct 20 10:11:46 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Mon, 20 Oct 2008 10:11:46 +0200
Subject: [Openvas-devel] Voting on Change Request #17
In-Reply-To: <200810161143.00626.michael.wiegand@intevation.de>
References: <200810131254.08037.michael.wiegand@intevation.de>
	<200810150952.54060.jan-oliver.wagner@intevation.de>
	<200810161143.00626.michael.wiegand@intevation.de>
Message-ID: <200810201011.46868.felix.wolfsteller@intevation.de>

On Thursday 16 October 2008 11:43:00 Michael Wiegand wrote:
> I have updated the CR with my proposal for the protocol commands, let me
> know what you think.

About protocol changes in CR#17 ( http://www.openvas.org/openvas-cr-17.html )
To keep up the intention of a human-readable protocol, and because there is 
not too much traffic to be expected from these commands, I would not
encode the trust level as [1 = trusted/0 = not trusted], but as "trusted" 
and "untrusted", making the servers response:

SERVER <|> CERTIFICATES
[certificate_data] <|> trusted
...
[certificate_data] <|> untrusted
...
<|> SERVER

-- felix


-- 
Felix Wolfsteller |  ++49-541-335 08 3451  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From jan-oliver.wagner at intevation.de  Mon Oct 20 14:19:17 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 20 Oct 2008 14:19:17 +0200
Subject: [Openvas-devel] Voting on Change Request #17
In-Reply-To: <200810201011.46868.felix.wolfsteller@intevation.de>
References: <200810131254.08037.michael.wiegand@intevation.de>
	<200810161143.00626.michael.wiegand@intevation.de>
	<200810201011.46868.felix.wolfsteller@intevation.de>
Message-ID: <200810201419.19467.jan-oliver.wagner@intevation.de>

On Montag, 20. Oktober 2008, Felix Wolfsteller wrote:
> On Thursday 16 October 2008 11:43:00 Michael Wiegand wrote:
> > I have updated the CR with my proposal for the protocol commands, let me
> > know what you think.
> 
> About protocol changes in CR#17 ( http://www.openvas.org/openvas-cr-17.html )
> To keep up the intention of a human-readable protocol, and because there is 
> not too much traffic to be expected from these commands, I would not
> encode the trust level as [1 = trusted/0 = not trusted], but as "trusted" 
> and "untrusted", making the servers response:
> 
> SERVER <|> CERTIFICATES
> [certificate_data] <|> trusted
> ...
> [certificate_data] <|> untrusted
> ...
> <|> SERVER

good  point.

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From sgros.ml at gmail.com  Tue Oct 21 09:48:38 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Tue, 21 Oct 2008 09:48:38 +0200
Subject: [Openvas-devel] Reorganizing plugins... 2. try
Message-ID: <4d7b043c0810210048r4449a1a8jfb276caf744b1f66@mail.gmail.com>

This is second release of a patch to reorganize plugin and cache
subdirectories. The first version included some parts of a patche I did for
64-bit clean compilation which are now hopefully removed. Also, I introduced
an error while doing last minute changes so that v00 patch didn't work as
it's supposed.

This time, I hope it's better. Also, there is now cache_folder directive in
configuration file that specifies top level directory for plugins. If
cache_folder is not specified, then .desc subdirectory will be created in
plugins_folder directory. Cache folder is organized into set of
subdirectories with a single letter.

I would like some feedback, is this good or not before doing the last
enhancment to allow multiple subdirectories to be specified (this won't be
so easy).

Stjepan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081021/b4e533dd/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugin-dir-v01.patch
Type: text/x-patch
Size: 31862 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081021/b4e533dd/plugin-dir-v01-0001.bin

From madhat at unspecific.com  Wed Oct 22 00:15:29 2008
From: madhat at unspecific.com (MadHat Unspecific)
Date: Tue, 21 Oct 2008 17:15:29 -0500
Subject: [Openvas-devel] Simple Patch (openvas-client)
Message-ID: <48FE5481.9040701@unspecific.com>

Since I actually use this and want to automate it, I propose these 2 
simple change to make it work better.  I am not sure if the "IF EXISTS" 
works everywhere or not, so...

Index: nessus/cli.c
===================================================================
--- nessus/cli.c	(revision 1597)
+++ nessus/cli.c	(working copy)
@@ -558,7 +558,7 @@
  cli_sql_dump_plugins(cli)
   struct cli_args * cli;
  {
- printf("DROP TABLE plugins;\n");
+ printf("DROP TABLE IF EXISTS plugins;\n");
   printf("CREATE TABLE plugins (\n");
   printf(" oid varchar(50) NOT NULL,\n");
   printf(" name varchar(255),\n");
@@ -571,7 +571,7 @@
   printf(" cve_id varchar(255),\n");
   printf(" bugtraq_id varchar(255),\n");
   printf(" xref blob,\n");
- printf(" primary key (id));\n");
+ printf(" primary key (oid));\n");
   _cli_sql_dump_plugins(Context->plugins);
   _cli_sql_dump_plugins(Context->scanners);
  }

-- 
MadHat (at) Unspecific.com
"The true man wants two things: danger and play.
  For that reason he wants woman, as the most dangerous plaything."
                           - Friedrich Nietzsche

From michael.wiegand at intevation.de  Wed Oct 22 11:32:31 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 22 Oct 2008 11:32:31 +0200
Subject: [Openvas-devel] Simple Patch (openvas-client)
In-Reply-To: <48FE5481.9040701@unspecific.com>
References: <48FE5481.9040701@unspecific.com>
Message-ID: <200810221132.31781.michael.wiegand@intevation.de>

[Wednesday 22 October 2008 - 00:15:29] MadHat Unspecific 
<madhat at unspecific.com>:
> Since I actually use this and want to automate it, I propose these 2
> simple change to make it work better.  I am not sure if the "IF EXISTS"
> works everywhere or not, so...

Thank you for your patch, I have committed the changes to openvas-client in 
the development trunk with revision #1599. I _think_ "IF EXISTS" is specified 
in the SQL specs and supported by the major SQL servers, although there seem 
to be issues with some versions of the Microsoft SQL server from what I can 
tell.

I don't think this change leads to incompatibilities; nevertheless, this might 
be a good opportunity for everybody using the SQL features to test if your 
custom scripts will still work with 2.0 and speak up if we broke anything.

Regards,

  Michael

-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From kost at linux.hr  Thu Oct 23 08:57:23 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Thu, 23 Oct 2008 08:57:23 +0200
Subject: [Openvas-devel] [Fwd: [rt.cccv.de #17458] OpenVAS - free your
	vulnerabilities]
Message-ID: <49002053.8030805@linux.hr>

Unfortunenatly,

We got rejected for main speech at CCC, but there is a chance to write
an article about OpenVAS in magazine "Die Datenschleuder". Anyone
interested to write it?

Also, as I'm eager to attract hackers at CCC to help/contribute, I
already submitted Lightning talk at:
http://events.ccc.de/congress/2008/wiki/Lightning_Talks

Take care,

-------- Original Message --------
Subject: [rt.cccv.de #17458] OpenVAS - free your vulnerabilities
Date: Wed, 22 Oct 2008 23:09:26 +0200 (CEST)
From: Constanze Kurz via RT <25c3-content at cccv.de>
Reply-To: 25c3-content at cccv.de
References: <RT-Ticket-17458 at cccv.de>

Hello Tim and Vlatko,

I was appointed as your friendly coordinator for your submission
"OpenVAS - free your vulnerabilities" to the 25th Chaos Communication
Congress.

I am sorry to inform you that the content committee did not accept your
submission. We had more than twice as many submissions as time slots so
we had to make some hard decisions.

Nevertheless we believe that the project in general and the scanner in
particular would interest many hackers here. Would you maybe consider to
write an article for our magazine "Die Datenschleuder"? We would really
appreciate this! (Can, of course, be in English and about 5,000 characters.)

We hope you come to the Congress anyway because it will surely be the
best hacker meeting in Europe this year. :}

Best regards, Constanze
Content Committee

========== This e-mail is part of 25C3 correspondence ==========
[WEBSITE] 25C3 Website/Wiki http://events.ccc.de/congress/2008/
[WEBLOG] Events Weblog http://events.ccc.de/

From jan-oliver.wagner at intevation.de  Fri Oct 24 10:21:23 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 24 Oct 2008 10:21:23 +0200
Subject: [Openvas-devel] Test of auto-enable-feature (CR#16)
Message-ID: <200810241021.33064.jan-oliver.wagner@intevation.de>

Hello Felix,

I just tried out the auto-enable-feature as of CR#16.

 * it is not documented in the compendiums. Can you
 add it there and mark it as OpenVAS-2.0 feature?
 Don't forget to mention that OpenVAS-2.0 will inform about number of
 new NVTs at server connect.
 The screenshots should be either updated or marked as OpenVAS 1.0.

 * Can you add a tooltip for the checkbox widget?

Thanks

	Jan

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From kost at linux.hr  Fri Oct 24 23:52:21 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Fri, 24 Oct 2008 23:52:21 +0200
Subject: [Openvas-devel] [Fwd: [rt.cccv.de #17458] OpenVAS - free your
 vulnerabilities]
In-Reply-To: <BLU105-W1866A2C6F906EFE1A75002A92B0@phx.gbl>
References: <49002053.8030805@linux.hr>
	<BLU105-W1866A2C6F906EFE1A75002A92B0@phx.gbl>
Message-ID: <49024395.7040806@linux.hr>

Seems you're the only one... so, feel free! :)

Daniel Cabezas wrote:
> Greetings,
> 
> If there are no more candidates, I could do the job, must the article
> include any screenshots, too?
> 
> 
> Bye,
> 
> Daniel
> 
> 
> 
> ------------------------------------------------------------------------
>> Date: Thu, 23 Oct 2008 08:57:23 +0200
>> From: kost at linux.hr
>> To: openvas-devel at wald.intevation.org
>> Subject: [Openvas-devel] [Fwd: [rt.cccv.de #17458] OpenVAS - free your
> vulnerabilities]
>>
>> Unfortunenatly,
>>
>> We got rejected for main speech at CCC, but there is a chance to write
>> an article about OpenVAS in magazine "Die Datenschleuder". Anyone
>> interested to write it?
>>
>> Also, as I'm eager to attract hackers at CCC to help/contribute, I
>> already submitted Lightning talk at:
>> http://events.ccc.de/congress/2008/wiki/Lightning_Talks
>>
>> Take care,
>>
>> -------- Original Message --------
>> Subject: [rt.cccv.de #17458] OpenVAS - free your vulnerabilities
>> Date: Wed, 22 Oct 2008 23:09:26 +0200 (CEST)
>> From: Constanze Kurz via RT <25c3-content at cccv.de>
>> Reply-To: 25c3-content at cccv.de
>> References: <RT-Ticket-17458 at cccv.de>
>>
>> Hello Tim and Vlatko,
>>
>> I was appointed as your friendly coordinator for your submission
>> "OpenVAS - free your vulnerabilities" to the 25th Chaos Communication
>> Congress.
>>
>> I am sorry to inform you that the content committee did not accept your
>> submission. We had more than twice as many submissions as time slots so
>> we had to make some hard decisions.
>>
>> Nevertheless we believe that the project in general and the scanner in
>> particular would interest many hackers here. Would you maybe consider to
>> write an article for our magazine "Die Datenschleuder"? We would really
>> appreciate this! (Can, of course, be in English and about 5,000
> characters.)
>>
>> We hope you come to the Congress anyway because it will surely be the
>> best hacker meeting in Europe this year. :}
>>
>> Best regards, Constanze
>> Content Committee
>>
>> ========== This e-mail is part of 25C3 correspondence ==========
>> [WEBSITE] 25C3 Website/Wiki http://events.ccc.de/congress/2008/
>> [WEBLOG] Events Weblog http://events.ccc.de/
>> _______________________________________________
>> Openvas-devel mailing list
>> Openvas-devel at wald.intevation.org
>> http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
> 
> ------------------------------------------------------------------------
> Ahora ll?vate lo mejor de MSN y Windows Live, en tu m?vil
> <http://serviciosmoviles.es.msn.com/>

From kost at linux.hr  Sat Oct 25 09:05:14 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Sat, 25 Oct 2008 09:05:14 +0200
Subject: [Openvas-devel] Rationale for removing hydra and snmp_portscan (C
	plugins)
Message-ID: <4902C52A.8020807@linux.hr>

Hello!

Just quick explanation on why hydra and snmp portscan C plugins were
removed. It's simple. They were empty plugins. I checked if there's any
leftover dependency and removed them as both of them were superseeded
with nasl equivalents (snmpwalk_portscan.nasl and hydra*nasl). In short,
C plugins didn't add any functionalities (empty plugins). I also
commited hydra_mysql.nasl and hydra_postgresql, so hydra is definitively
supported well in OpenVAS.

For example, this is all  code from hydra C plugin (stripped comments):
#include <includes.h>


int plugin_init(desc)
 struct arglist * desc;
{
 return -1;
}



int
plugin_run(desc)
 struct arglist * desc;
{
 return 0;
}

As you can see it's empty. Hope this will shed some light on why I
removed hydra and snmp plugins. If you need more information, don't
hesitate to contact/bug me.

Kost


From michael.wiegand at intevation.de  Mon Oct 27 12:04:56 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Mon, 27 Oct 2008 12:04:56 +0100
Subject: [Openvas-devel] Planning openvas-plugins 1.0.4 release
Message-ID: <200810271204.56684.michael.wiegand@intevation.de>

Hello,

as mentioned on openvas-distro, I would like to do a new release of 
openvas-plugins soon.

One reason behind this is that openvas-plugins 1.0.2 has been rejected from 
Debian since it contained NVTs with an unclear or incompatible license. These 
NVTs are still present in 1.0.3, but have been since replaced by GPLed NVTs 
(Thanks to Thomas Reinke!). Apart from this issue, there have been quite a 
lot of changes and additions in openvas-plugins since the 1.0.3 release that 
would justify a new release anyway.

As I said before, I would like to do this release very soon (today if 
possible) so the package maintainers can get the new release as soon as 
possible.

Let me know what you think.

Regards,

  Michael


-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From felix.wolfsteller at intevation.de  Tue Oct 28 10:06:35 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Tue, 28 Oct 2008 10:06:35 +0100
Subject: [Openvas-devel] [openvas-libnasl] ENABLE_PLUGIN_SERVER #ifdefs
Message-ID: <200810281006.35596.felix.wolfsteller@intevation.de>

Hi
I stumbled over a 
#ifdef ENABLE_PLUGIN_SERVER
    if ( recompile_all != 0 ) exit(0); /* Done */
#endif
in openvasd.c. I could not find ENABLE_PLUGIN_SERVER to be defined somewhere 
(neither in Make targets). Since recompile_all is not defined somewhere 
either, defining ENABLE_PLUGIN_SERVER would break the building process for 
the server anyway.
From the speaking name of the #define I guess it was used to build a 
(nessus?-) server just serving plugins but not executing them. Since 
OpenVAS-Server does not offer this split personality but introduced feeds, I 
suspect of these "#ifdef ENAB... #endif"  parts of code (~700 lines in 
preparse.c, ~30 in exec.c, 1 in openvasd.c) can be removed, right?
-- felix

-- 
Felix Wolfsteller |  ++49-541-335 08 3451  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From hanno at hboeck.de  Tue Oct 28 12:45:51 2008
From: hanno at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=)
Date: Tue, 28 Oct 2008 13:45:51 +0200
Subject: [Openvas-devel] Planning openvas-plugins 1.0.4 release
In-Reply-To: <200810271204.56684.michael.wiegand@intevation.de>
References: <200810271204.56684.michael.wiegand@intevation.de>
Message-ID: <200810281345.51474.hanno@hboeck.de>

Am Montag 27 Oktober 2008 schrieb Michael Wiegand:
> as mentioned on openvas-distro, I would like to do a new release of
> openvas-plugins soon.

My patch, sent on 2008-09-17, for respecting ldflags, didn't get in yet.

Can this be done before?

-- 
Hanno B?ck		Blog:		http://www.hboeck.de/
GPG: 3DBD3B20		Jabber/Mail:	hanno at hboeck.de

http://x1000malquer.de/ - ab 8.11. Atomtransporte stoppen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081028/583d6824/attachment.pgp

From jan-oliver.wagner at intevation.de  Tue Oct 28 14:03:44 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Tue, 28 Oct 2008 15:03:44 +0200
Subject: [Openvas-devel] ENABLE_PLUGIN_SERVER #ifdefs
In-Reply-To: <200810281006.35596.felix.wolfsteller@intevation.de>
References: <200810281006.35596.felix.wolfsteller@intevation.de>
Message-ID: <200810281403.46145.jan-oliver.wagner@intevation.de>

Hello,

On Dienstag, 28. Oktober 2008, Felix Wolfsteller wrote:
> I stumbled over a 
> #ifdef ENABLE_PLUGIN_SERVER
>     if ( recompile_all != 0 ) exit(0); /* Done */
> #endif
> in openvasd.c. I could not find ENABLE_PLUGIN_SERVER to be defined somewhere 
> (neither in Make targets). Since recompile_all is not defined somewhere 
> either, defining ENABLE_PLUGIN_SERVER would break the building process for 
> the server anyway.
> From the speaking name of the #define I guess it was used to build a 
> (nessus?-) server just serving plugins but not executing them. Since 
> OpenVAS-Server does not offer this split personality but introduced feeds, I 
> suspect of these "#ifdef ENAB... #endif"  parts of code (~700 lines in 
> preparse.c, ~30 in exec.c, 1 in openvasd.c) can be removed, right?

this code might be about creating "binaries" of the nasl scripts.

I suggest to leave it where it is and eventually get back to it
once we moved our minds about whether we want compiled versions
of the nasls. (BTW: I think yes, but lack time to give a detailed rational
at the moment)

Best

	Jan


-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From michael.wiegand at intevation.de  Tue Oct 28 14:08:45 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Tue, 28 Oct 2008 14:08:45 +0100
Subject: [Openvas-devel] Planning openvas-plugins 1.0.4 release
In-Reply-To: <200810281345.51474.hanno@hboeck.de>
References: <200810271204.56684.michael.wiegand@intevation.de>
	<200810281345.51474.hanno@hboeck.de>
Message-ID: <200810281408.45636.michael.wiegand@intevation.de>

[Tuesday 28 October 2008 - 12:45:51] Hanno B?ck <hanno at hboeck.de>:
> Am Montag 27 Oktober 2008 schrieb Michael Wiegand:
> My patch, sent on 2008-09-17, for respecting ldflags, didn't get in yet.

I was under the impression that Tim included the patch in revision 1370, 
according to 
http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/openvas-plugins/openvas.tmpl.in?rev=1370&root=openvas&view=log.

Could you check if this is the case? Thank you!

Regards,

Michael


-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From michael.wiegand at intevation.de  Thu Oct 30 14:49:31 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Thu, 30 Oct 2008 14:49:31 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0810161004h1e86c9cbr86cd45d8d13ced1c@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<200810152145.12441.timb@nth-dimension.org.uk>
	<4d7b043c0810161004h1e86c9cbr86cd45d8d13ced1c@mail.gmail.com>
Message-ID: <200810301449.31262.michael.wiegand@intevation.de>

[Thursday 16 October 2008 - 19:04:55] "Stjepan Gros" <sgros.ml at gmail.com>:
> Ok, I went throught the code and included GLib in those subsystems that
> didn't use it yet. I then inserted GPOINTER_TO_SIZE instead of (int) and
> GSIZE_TO_POINTER instead of (void *). Furthermore, every occurence of
> sizeof(int) I changed into sizeof(gpointer). There were few places where
> sizeof(variable) was used, but I converted them also to sizeof(gpointer) as
> it's the real size that is handed into the function. Few other omissions
> were also corrected (but look into patches for them). 

Hello Stjepan,

thank you very much for your patch; I'm sorry it took me a few days to get a 
good look at it.

I've just finished going through you patch for -client and it looks very good 
so far. I would like to commit it to the SVN trunk soon, there are only a few 
minor issues:

- I have noticed that you did not only fix the 64bit issue, but other issues 
as well. While this is definitely a great thing and more than welcome, it 
would be easier for other developers to understand your changes if you could 
split your patch (one patch for 64bit issues, one for others) and describe 
your changes in the appropriate ChangeLog.

- I have noticed that there are a few printf warnings on 32bit now after 
applying your patch, mostly along the lines of "format '%lu' expects 
type 'long unsigned int', but argument 3 has type 'unsigned int'". I'm not 
quite sure as to what would be the best way to solve this; you seem to have 
more experience in this area, any suggestions?

Again, thank you very much for your patch, let me know if you have any 
questions.

Regards,

  Michael

-- 
Michael Wiegand |  OpenPGP key: D7D049EC  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From felix.wolfsteller at intevation.de  Fri Oct 31 14:54:05 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Fri, 31 Oct 2008 14:54:05 +0100
Subject: [Openvas-devel] Latest revision breaks compatibility and forces
	cache- rebuilts
Message-ID: <200810311454.05641.felix.wolfsteller@intevation.de>

Hi
I just commited some patches to get a grip on CR#17 ( 
http://www.openvas.org/openvas-cr-17.html ).
In order to use client and server you will have to update both (and first: 
openvas-libraries).
Old cache-files both on the server-side and on the client- side are useless 
now, but should be rebuilt automatically. Delete or backup them first in case 
of trouble (and send a reply).
There are issues when you use plugins without signatures, in that case plugins 
are understood to be new when the server is started. This is reflected in the 
client as well. Furthermore, OVAL- plugins will most probably not be 
transmitted at the moment. I will fix both issues next week (and add real 
functionality). If you see "FIXME: felix" 's - blame me.
Below the changelogs.
Have a fun weekend
-- Felix

openvas-libraries rev 1654:
----------------------------------
	Steps to an implementation of Change Request #17 
	(http://www.openvas.org/openvas-cr-17.html - "Make NVT signatures 
	available to OpenVAS-Client").
	Adds the new field "sign_key_ids" to plugin-structures and the .desc 
	store. Until soon, just a dummy- string will be saved and eventually
	transmitted by the server.

	IMPORTANT: Breaks compatibility and renders old server .desc- cache 
	files useless.

	* libopenvas/plugutils.c (plug_set_sign_key_ids, plug_get_sign_key_ids):
	Added getter & setter to retrieve key-ids of certificates of a plugin.

	* libopenvas/plugutils.h: Prototypes for plug_set_sign_key_ids and
	plug_get_sign_key_ids added.

	* libopenvas/store_internal.h: Added sign_key_ids field to plugin struct
	 and increased magic number for server-side cache (.desc files)

	* libopenvas/store.c (store_init_sys, store_init_user): Added comments.

	* libopenvas/store.c (store_load_plugin): Check if signature file 
	is new than cache (functionality will be moved), set sign_key_ids 
	according to cache, added comments.

	* libopenvas/store.c (store_plugin): Stores the (dummy) key_id- string.

openvas-server rev 1655:
--------------------------------
	Steps to an implementation of Change Request #17 
	(http://www.openvas.org/openvas-cr-17.html - "Make NVT signatures 
	available to OpenVAS-Client").
	Uses the new field "sign_key_ids" of plugin-structures and the .desc 
	store. Until soon, just a dummy- string will be used and eventually
	transmitted by the server.

	IMPORTANT: Breaks compatibility and renders old server .desc- cache 
	files useless. You will need an openvas-libraries revision >= 1654 in 
	order to compile and a client of revision >= 1654 in order to work with 
	the server. There might be problems with transmitting OVAL plugins to 
	the client.

	* openvasd/nasl_plugins.c (nasl_plugin_add) : Set a dummy key_ids-
	string, improved readability (a bit).

	* openvasd/pluginload.c: Typo in comment fixed.

	* openvasd/oval_plugins.c: Stated a FIXME and removed unreachable NULL
	return.

	* openvasd/otp_1_0.h: Added CREQ_CERTIFICATES symbol.

	* openvasd/otp_1_0.c (otp_1_0_get_client_request,
	otp_1_0_server_send_certificates): Added CREQ_CERTIFICATES parsing and 
	a method stub to send the certificates.

	* openvasd/otp_1_0.c (ntp_11_parse_input): Handling of 
	CREQ_CERTIFICATES added.

	* openvasd/comm.c (send_plug_info): Sends the additional key_ids field.

	* openvasd/comm.c (comm_setup_plugins): Comment and use of symbol 
	instead of numeral.


openvas-client rev 1656:
-------------------------------
	Steps to an implementation of Change Request #17 
	(http://www.openvas.org/openvas-cr-17.html - "Make NVT signatures 
	available to OpenVAS-Client").
	The client now receives the new field "sign_key_ids", adds it to the 
	plugin- structs and the local nvt caches. It is displayed in the
	plugin_info dialog.

	IMPORTANT: Breaks compatibility and renders old nvt- cache 
	files useless. You will only be able to successfully connect to
	openvas-server with revision >= 1655. There might be problems with 
	transmitting OVAL plugins from the server to client.

	* nessus/nessus_plugin.c (nessus_plugin_duplicate, nessus_plugin_new):
	Added new sign_key_ids field.

	* nessus/nessus_plugin.c (nessus_plugin_new): Updated struct, proto.

	* nessus/comm.c (parse_plugin, comm_get_certificates): Comments, 
	goto-removal, use sign_key_id. Method stub to receive certificates.

	* nessus/comm.h: Prototype for comm_get_certificates.

	* nessus/plugin_infos.c (plugin_info_window_setup): Comment, simple
	label to display server trust information.

	* nessus/plugin_cache.c: Increased "max number of items per line" to 
	parse, FILE_FORMAT_VERSION

	* nessus/plugin_cache.c (write_plugin, plugin_cache_read): Read and 
	write the new "key_ids" field.

	* nessus/parser.c (parse_symbol, parse_separator): Comments++ 
	K&R-Style--

	* nessus/context.h: Added HashTables to store certificate information.

-- 
Felix Wolfsteller |  ++49-541-335 08 3451  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From c_edjenguele at yahoo.it  Fri Oct 31 18:04:52 2008
From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE)
Date: Fri, 31 Oct 2008 17:04:52 +0000 (GMT)
Subject: [Openvas-devel] Award for the 2008 OpenVAS Contest
Message-ID: <283346.95843.qm@web28602.mail.ukl.yahoo.com>

Thanks to the?OpenVAS Team, sponsors ad project admins and developers.
It's a beautiful experience be part of the team ad also a pleasure to promote open source
vulnerability scanning?especially and open source technologies in general.
This will be the opportunity to bring my experience and knowledge?to improve openvas?framework.???
Congratulation to Vlatko Kosturjak and Chandrashekhar B.

Again thanks.

Cheers.


?---
Christian Eric Edjenguele
IT Security Software Developer & Researcher 



----- Messaggio originale -----
Da: The OpenVAS Team <timb at openvas.org>
A: openvas-announce at wald.intevation.org
Cc: pen-test at securityfocus.com; full-disclosure at lists.grok.org.uk; bugtraq at securityfocus.com
Inviato: Venerd? 31 ottobre 2008, 0:34:21
Oggetto: 2008 OpenVAS Contest

The 2008 OpenVAS Contest took place from August 23rd to October 15th, 2008. 
With 5 nominees who contributed a large number of improvements to the OpenVAS 
framework and extended the Open Source Network Vulnerability Testing, it was 
a great success. 

During the contest duration the number of OpenVAS Network Vulnerability Tests 
(NVTs) increased dramatically: from 3750 NVTs up to 5736 NVTs (an overall 
increase of over 50%). The most significant number of NVTs, which deliver 
full support for Gentoo and FreeBSD local security checks, were contributed 
by Thomas Reinke who deserves special thanks for his continuing support of 
OpenVAS. 

The OpenVAS developers and the sponsors of the OpenVAS Contest would like to 
thank all developers for their great contributions. The developers have spent 
a considerable amount of time on their submissions and have helped OpenVAS to 
become even better. These contributions will be included in the upcoming 
OpenVAS 2.0 release which will help to make the task of network security 
scanning easier worldwide. 

Since there were only three cash prices available, the OpenVAS steering 
committee and the sponsors decided after long deliberation to award the 
prizes to three new-comers to the OpenVAS team: 

1st place (600 Euro): Vlatko Kosturjak
2nd place (300 Euro): Chandrashekhar B
3rd place (200 Euro): Christian Eric Edjenguele

Congratulations to the winners!

Sponsors

The 2008 OpenVAS Contest was made possible by the following sponsors: 

Intevation GmbH
DN-Systems GmbH
Tim Brown
Jon?s Andradas

Cheers,
The OpenVAS Team
-- 
The OpenVAS Team
<mailto:staff at openvas.org>
<http://www.openvas.org/>



      Unisciti alla community di Io fotografo e video, il nuovo corso di fotografia di Gazzetta dello sport:
http://www.flickr.com/groups/iofotografoevideo

From timb at nth-dimension.org.uk  Fri Oct 31 23:36:55 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Fri, 31 Oct 2008 22:36:55 +0000
Subject: [Openvas-devel] Solaris Local Security Checks
Message-ID: <200810312236.55376.timb@nth-dimension.org.uk>

All,

This evening I committed >1100 Solaris local security checks to the 
openvas-plugins-solaris-local-security-checks branch.  These checks are 
automatically generated from the list of security patches published on 
Sunsolve.  You can check out the branch as follows:

svn checkout 
https://svn.wald.intevation.org/svn/openvas/branches/openvas-plugins-solaris-local-security-checks

Whilst the plugins themselves (and solaris.inc) are, I believe correct, the 
limited testing I have done this far, indicates a problem with 
gather-package-list.nasl which is used to gather the information and set 
knowledge base entries on which these checks depend.  I'm going to be very 
busy with work for the next 5 weeks and so I'd invite any of you that have 
access to Solaris boxes to have a play and see if the problems I experienced 
can be resolved.

I should be contactable via email and I'll be online when I can, so if anyone 
does find the root of the problem, I'm more than happy to merge whatever 
patches are required (or someone else will).  It would be nice to include 
these checks in OpenVAS 2.0.0 so any assistance would be appreciated.

Cheers,
Tim
-- 
Tim Brown
<mailto:timb at nth-dimension.org.uk>
<http://www.nth-dimension.org.uk/>

From marco.fradin at free.fr  Wed Oct 29 05:34:11 2008
From: marco.fradin at free.fr (marco)
Date: Wed, 29 Oct 2008 05:34:11 +0100
Subject: [Openvas-devel] openvas-compendium-1.0.0.rc1 french translation
Message-ID: <200810290534.11512.marco.fradin@free.fr>

Hi everyone,
For information, french translation is about 20.2%. Looks fine.
I hope nobody else is working on it.  Tell me in case someone has done the 
job ;-)

Regards,
Marco (sitepamarco)