From jan-oliver.wagner at intevation.de  Mon Feb  2 10:05:19 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 2 Feb 2009 10:05:19 +0100
Subject: [Openvas-devel] Planning openvas-libraries 2.0.1
Message-ID: <200902021005.22146.jan-oliver.wagner@intevation.de>

Hello,

the SVN has accumulated a number of helpful/interesting
improvements. Namely bug fixes for build environment, code documentation ("make doc").
removal of old/unused code, preparation for new caching technology and for new sub-dirs
feature.
There is one change that has effect to present installations: In .desc/ the filenames
will change from e.g xxx.desc to xxx.nasl.desc. This is to have no conflict with xxx.oval or xxx.nes.
So, users should clean the .desc directory to save some disk space.

Please let us know if you want anything in this module before the release.

It is planned to have the release end of this week or early next week.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++49-541-335083-0  |  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 matt at mundell.ukfsn.org  Tue Feb  3 13:26:57 2009
From: matt at mundell.ukfsn.org (Matthew Mundell)
Date: 03 Feb 2009 12:26:57 GMT
Subject: [Openvas-devel] Updated OMP Specification
In-Reply-To: Message of Thu, 29 Jan 2009 10:24:56 +0100.
	<20090129092456.GB21185@intevation.de>
Message-ID: <20090203122659.87249DEF41@mail.ukfsn.org>

> Main changes include:
> - The unique ID is now assigned by the client; this should help the
>   client to better differntiate between response for multiple new_task
>   requests.

I think this is too complicated for the client, as it requires the client
to keep track of all tasks.  It is also possible that someone could use two
clients to control the same task.  How would the second client know which
tasks the first had created?

I think also that the client is always going to know exactly which response
corresponds to which request.  With direct OMP the client sends a command
and waits for the response, which always applies to the previous command.
Even with OMP over HTTP the client gets the response immediately from the
HTTP server.

> - IDs are included in most responses to improve error handling.

Again, the client is in the process of requesting this command so it should
know exactly which ID is involved.

> - A lot of information has been moved from elements to attributes to
>   improve the OMP structure and to simplify parsing.

This increases the amount of parsing work, as the manager and client now
also need to do attribute parsing, whereas before it was only elements.


> Those decisions are not intended to be final, especially the placement
> of data in elements or attributes. If you have any suggestions, I am
> looking forward to your feedback.
>
> Please do not hesitate to ask questions and to point out
> inconsistencies.

 - Nearly all the commands are named with verbs: start_task, modify_task,
   delete_report, get_nvt_details, etc.  Three are named with nouns:
   new_task, status and omp_version.  The naming could be made consistent.
   Perhaps the three could be renamed to make_task, get_status and
   get_version.

 - The parameters to new_task are entities, while the parameters to
   modify_task are attributes.

 - I think abort_task would match start_task better if abort_task were
   named stop_task.

 - There are many response entities.  Could they be merged into one entity?
   So for example the first new_task_response in CR 28 becomes

	   <response status="201" />

   and the first get_nvt_details_response becomes

	   <response status="200">
		 <nvt_details>
		   <nvt>...</nvt>
		 </nvt_details>
	   </response>

   or even

	   <response status="200">
		 <nvt>...</nvt>
	   </response>


From michael.wiegand at intevation.de  Tue Feb  3 14:54:35 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Tue, 3 Feb 2009 14:54:35 +0100
Subject: [Openvas-devel] Updated OMP Specification
In-Reply-To: <20090203122659.87249DEF41@mail.ukfsn.org>
References: <20090129092456.GB21185@intevation.de>
	<20090203122659.87249DEF41@mail.ukfsn.org>
Message-ID: <20090203135435.GC11660@intevation.de>

* Matthew Mundell [ 3. Feb 2009]:
> > Main changes include:
> > - The unique ID is now assigned by the client; this should help the
> >   client to better differntiate between response for multiple new_task
> >   requests.
> 
> I think this is too complicated for the client, as it requires the client
> to keep track of all tasks.  It is also possible that someone could use two
> clients to control the same task.  How would the second client know which
> tasks the first had created?

Right now, this information is available throught the "status" command.
But I think especially for the scenario that you are describing we will
need a way to retrieve the complete information (NVT selection,
preferences etc.) for a particular task. Before editing a task, a client
should use this command to make sure it is working with the most recent
version of this task.

> I think also that the client is always going to know exactly which response
> corresponds to which request.  With direct OMP the client sends a command
> and waits for the response, which always applies to the previous command.
> Even with OMP over HTTP the client gets the response immediately from the
> HTTP server.

I am a little confused as you yourself brought up this issue in your
response from January 17. I am also pretty optimistic that the client
won't issue so many commands that it would get confused by the
responses, so this ID attribute would act as an additional safeguard.
I'm not 100% certain we really need, so if you could explain what made
you change your mind this would probably be helpful.

> > - IDs are included in most responses to improve error handling.
> 
> Again, the client is in the process of requesting this command so it should
> know exactly which ID is involved.

See above.

> > - A lot of information has been moved from elements to attributes to
> >   improve the OMP structure and to simplify parsing.
> 
> This increases the amount of parsing work, as the manager and client now
> also need to do attribute parsing, whereas before it was only elements.

Well, I think attributes do make more sense in certain places. Thanks to
glib, they are easily parsed, so I think the increase is negligible and
outweighed by the improved readability of both protocol and parsing
code.

>  - Nearly all the commands are named with verbs: start_task, modify_task,
>    delete_report, get_nvt_details, etc.  Three are named with nouns:
>    new_task, status and omp_version.  The naming could be made consistent.
>    Perhaps the three could be renamed to make_task, get_status and
>    get_version.

Agreed.

>  - The parameters to new_task are entities, while the parameters to
>    modify_task are attributes.

Yes; this should be consistent, I will look into that.

>  - I think abort_task would match start_task better if abort_task were
>    named stop_task.

Agreed.

>  - There are many response entities.  Could they be merged into one entity?
>    So for example the first new_task_response in CR 28 becomes
> 
> 	   <response status="201" />
> 
>    and the first get_nvt_details_response becomes
> 
> 	   <response status="200">
> 		 <nvt_details>
> 		   <nvt>...</nvt>
> 		 </nvt_details>
> 	   </response>
> 
>    or even
> 
> 	   <response status="200">
> 		 <nvt>...</nvt>
> 	   </response>

I've been thinking of this a well and am not opposed to it. As you have
mentioned previously, we just have to make sure that the client is able
to match the responses it recieves to the requests it sent out.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090203/3a62aa1e/attachment.pgp

From michael.wiegand at intevation.de  Wed Feb  4 11:43:08 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 4 Feb 2009 11:43:08 +0100
Subject: [Openvas-devel] Updated OMP Specification
In-Reply-To: <20090203122659.87249DEF41@mail.ukfsn.org>
References: <20090129092456.GB21185@intevation.de>
	<20090203122659.87249DEF41@mail.ukfsn.org>
Message-ID: <20090204104308.GE11358@intevation.de>

* Matthew Mundell [ 3. Feb 2009]:
>  - Nearly all the commands are named with verbs: start_task, modify_task,
>    delete_report, get_nvt_details, etc.  Three are named with nouns:
>    new_task, status and omp_version.  The naming could be made consistent.
>    Perhaps the three could be renamed to make_task, get_status and
>    get_version.

I've changed the specification according to your suggestion:
new_task    => create_task
status      => get_status
omp_version => get_version

Thanks for spotting this.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090204/ad8b921f/attachment.pgp

From matt at mundell.ukfsn.org  Wed Feb  4 12:42:40 2009
From: matt at mundell.ukfsn.org (Matthew Mundell)
Date: 04 Feb 2009 11:42:40 GMT
Subject: [Openvas-devel] Updated OMP Specification
In-Reply-To: Message of Tue, 3 Feb 2009 14:54:35 +0100.
	<20090203135435.GC11660@intevation.de>
Message-ID: <20090204114237.27FA2DED99@mail.ukfsn.org>

> > > Main changes include:
> > > - The unique ID is now assigned by the client; this should help the
> > >   client to better differntiate between response for multiple new_task
> > >   requests.
> >
> > I think this is too complicated for the client, as it requires the client
> > to keep track of all tasks.  It is also possible that someone could use two
> > clients to control the same task.  How would the second client know which
> > tasks the first had created?
>
> Right now, this information is available throught the "status" command.
> But I think especially for the scenario that you are describing we will
> need a way to retrieve the complete information (NVT selection,
> preferences etc.) for a particular task. Before editing a task, a client
> should use this command to make sure it is working with the most recent
> version of this task.

I wonder if I understand this correctly.  I think that before every
new_task a client will have to do a status command and read in all the task
IDs to make sure that it chooses a unique ID.  This is because the user may
have created tasks with another client or another instance of the same
client.

> > I think also that the client is always going to know exactly which response
> > corresponds to which request.  With direct OMP the client sends a command
> > and waits for the response, which always applies to the previous command.
> > Even with OMP over HTTP the client gets the response immediately from the
> > HTTP server.
>
> I am a little confused as you yourself brought up this issue in your
> response from January 17. I am also pretty optimistic that the client
> won't issue so many commands that it would get confused by the
> responses, so this ID attribute would act as an additional safeguard.
> I'm not 100% certain we really need, so if you could explain what made
> you change your mind this would probably be helpful.

Sorry for the confusion.

When I brought it up on Jan 17 I was imagining that the manager response
could come in a completely separate message, for example on a completely
new connection.  That made me think that the responses could come out of
order.  Now I'm starting to think that in all cases there will be a
connection that will guarantee that the responses will come back in order.
I'm guessing that if a response can come out of order then there are many
issues to deal with, so we may as well forget it.

Is that any clearer?  Perhaps you understand the setting better than I do.

From michael.wiegand at intevation.de  Wed Feb  4 12:57:45 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 4 Feb 2009 12:57:45 +0100
Subject: [Openvas-devel] Updated OMP Specification
In-Reply-To: <20090204114237.27FA2DED99@mail.ukfsn.org>
References: <20090203135435.GC11660@intevation.de>
	<20090204114237.27FA2DED99@mail.ukfsn.org>
Message-ID: <20090204115745.GF11358@intevation.de>

* Matthew Mundell [ 4. Feb 2009]:
> > Right now, this information is available throught the "status" command.
> > But I think especially for the scenario that you are describing we will
> > need a way to retrieve the complete information (NVT selection,
> > preferences etc.) for a particular task. Before editing a task, a client
> > should use this command to make sure it is working with the most recent
> > version of this task.
> 
> I wonder if I understand this correctly.  I think that before every
> new_task a client will have to do a status command and read in all the task
> IDs to make sure that it chooses a unique ID.  This is because the user may
> have created tasks with another client or another instance of the same
> client.

No, the client can assign an ID without contacting the server. If we
uses random UUIDs (as described in RFC 4122) the client can be
reasonably certain the UUID it has just chosen is universally unique.

I was suggesting that the client should contact the server when updating
an *existing* task for the reason you have mention to prevent it from
accidentally overwrite changes made to this task by another client.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090204/00c75496/attachment.pgp

From matt at mundell.ukfsn.org  Wed Feb  4 13:19:20 2009
From: matt at mundell.ukfsn.org (Matthew Mundell)
Date: 04 Feb 2009 12:19:20 GMT
Subject: [Openvas-devel] Updated OMP Specification
In-Reply-To: Message of Wed, 4 Feb 2009 12:57:45 +0100.
	<20090204115745.GF11358@intevation.de>
Message-ID: <20090204121916.C7978DEDEA@mail.ukfsn.org>

> * Matthew Mundell [ 4. Feb 2009]:
> > > Right now, this information is available throught the "status" command.
> > > But I think especially for the scenario that you are describing we will
> > > need a way to retrieve the complete information (NVT selection,
> > > preferences etc.) for a particular task. Before editing a task, a client
> > > should use this command to make sure it is working with the most recent
> > > version of this task.
> >
> > I wonder if I understand this correctly.  I think that before every
> > new_task a client will have to do a status command and read in all the task
> > IDs to make sure that it chooses a unique ID.  This is because the user may
> > have created tasks with another client or another instance of the same
> > client.
>
> No, the client can assign an ID without contacting the server. If we
> uses random UUIDs (as described in RFC 4122) the client can be
> reasonably certain the UUID it has just chosen is universally unique.

Ah.

> I was suggesting that the client should contact the server when updating
> an *existing* task for the reason you have mention to prevent it from
> accidentally overwrite changes made to this task by another client.

The task could have a version number to make this check easier.

From felix.wolfsteller at intevation.de  Wed Feb  4 13:35:21 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Wed, 4 Feb 2009 13:35:21 +0100
Subject: [Openvas-devel] Updated OMP Specification
In-Reply-To: <20090204115745.GF11358@intevation.de>
References: <20090203135435.GC11660@intevation.de>
	<20090204114237.27FA2DED99@mail.ukfsn.org>
	<20090204115745.GF11358@intevation.de>
Message-ID: <200902041335.21972.felix.wolfsteller@intevation.de>

On Wednesday 04 February 2009 12:57:45 Michael Wiegand wrote:
> * Matthew Mundell [ 4. Feb 2009]:
> > > Right now, this information is available throught the "status" command.
> > > But I think especially for the scenario that you are describing we will
> > > need a way to retrieve the complete information (NVT selection,
> > > preferences etc.) for a particular task. Before editing a task, a
> > > client should use this command to make sure it is working with the most
> > > recent version of this task.
> >
> > I wonder if I understand this correctly.  I think that before every
> > new_task a client will have to do a status command and read in all the
> > task IDs to make sure that it chooses a unique ID.  This is because the
> > user may have created tasks with another client or another instance of
> > the same client.
>
> No, the client can assign an ID without contacting the server. If we
> uses random UUIDs (as described in RFC 4122) the client can be
> reasonably certain the UUID it has just chosen is universally unique.

I might missing something here, but
why cant the name of a task be unique and thats it?

-- 
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 matt at mundell.ukfsn.org  Fri Feb  6 16:00:09 2009
From: matt at mundell.ukfsn.org (Matthew Mundell)
Date: 06 Feb 2009 15:00:09 GMT
Subject: [Openvas-devel] [Openvas-commits] r2423 - in
	trunk/openvas-manager: . doc
In-Reply-To: Message of Fri,  6 Feb 2009 15:15:10 +0100 (CET).
	<20090206141510.D973440755@pyrosoma.intevation.org>
Message-ID: <20090206150008.59521DEBE4@mail.ukfsn.org>

> Author: mwiegand
> Date: 2009-02-06 15:15:09 +0100 (Fri, 06 Feb 2009)
> New Revision: 2423
>
> Modified:
>    trunk/openvas-manager/ChangeLog
>    trunk/openvas-manager/doc/CMakeLists.txt
> Log:
> * doc/CMakeLists.txt: Fixed syntax error which caused the build process
> to fail.

Sorry, should have checked.

From michael.wiegand at intevation.de  Fri Feb  6 16:03:23 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Fri, 6 Feb 2009 16:03:23 +0100
Subject: [Openvas-devel] [Openvas-commits] r2423 -
	in	trunk/openvas-manager: . doc
In-Reply-To: <20090206150008.59521DEBE4@mail.ukfsn.org>
References: <20090206141510.D973440755@pyrosoma.intevation.org>
	<20090206150008.59521DEBE4@mail.ukfsn.org>
Message-ID: <20090206150323.GD23393@intevation.de>

* Matthew Mundell [ 6. Feb 2009]:
> > Log:
> > * doc/CMakeLists.txt: Fixed syntax error which caused the build process
> > to fail.
> 
> Sorry, should have checked.

Don't worry, that has given me the opportunity to understand CMake a
little better. That was worth it for me ... :)

Have a nice weekend,

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090206/76fdef46/attachment.pgp

From jan-oliver.wagner at intevation.de  Fri Feb  6 17:05:56 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 6 Feb 2009 17:05:56 +0100
Subject: [Openvas-devel] Planning openvas-libnasl 2.0.1
Message-ID: <200902061705.58837.jan-oliver.wagner@intevation.de>

Hello,

as the next step, we now need an update of libnasl.
There are only few, minor fixes in SVN since 2.0.0,
but some important changes that prepare
* the sub-dirs feature
* multiple include paths
* variable location of cache folder (will be /var/cache/openvas in the near future
   getting rid of the insane location /var/lib/openvas/plugins/.desc

Please let us know if you want anything in this module before the release.

It is planned to have the release mid to end of next week.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++49-541-335083-0  |  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 Feb  6 21:25:03 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 6 Feb 2009 21:25:03 +0100
Subject: [Openvas-devel] Call for vote on #25 (WMI)
Message-ID: <200902062125.03394.jan-oliver.wagner@intevation.de>

Hi,

I'd like to call for a vote on Change Request #25 (OpenVAS-libnasl: 
Introducing support for WMI).

From side +1

Best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++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 bchandra at secpod.com  Mon Feb  9 08:15:20 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Mon, 9 Feb 2009 12:45:20 +0530
Subject: [Openvas-devel] Call for vote on #25 (WMI)
In-Reply-To: <200902062125.03394.jan-oliver.wagner@intevation.de>
References: <200902062125.03394.jan-oliver.wagner@intevation.de>
Message-ID: <883708B3337D428C8CED551E3F85F7D1@bchandra>



+1 from me :)

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: Saturday, February 07, 2009 1:55 AM
To: OpenVAS Development List
Subject: [Openvas-devel] Call for vote on #25 (WMI)

Hi,

I'd like to call for a vote on Change Request #25 (OpenVAS-libnasl: 
Introducing support for WMI).


From michael.wiegand at intevation.de  Mon Feb  9 08:20:36 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Mon, 9 Feb 2009 08:20:36 +0100
Subject: [Openvas-devel] Call for vote on #25 (WMI)
In-Reply-To: <200902062125.03394.jan-oliver.wagner@intevation.de>
References: <200902062125.03394.jan-oliver.wagner@intevation.de>
Message-ID: <20090209072036.GA1788@intevation.de>

* Jan-Oliver Wagner [ 6. Feb 2009]:
> I'd like to call for a vote on Change Request #25 (OpenVAS-libnasl: 
> Introducing support for WMI).

+1 from me, this will definitely improve the scanning of remote Windows
targets.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090209/ccdaa7a8/attachment.pgp

From felix.wolfsteller at intevation.de  Mon Feb  9 09:15:32 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Mon, 9 Feb 2009 09:15:32 +0100
Subject: [Openvas-devel] Call for vote on #25 (WMI)
In-Reply-To: <200902062125.03394.jan-oliver.wagner@intevation.de>
References: <200902062125.03394.jan-oliver.wagner@intevation.de>
Message-ID: <200902090915.32497.felix.wolfsteller@intevation.de>

On Friday 06 February 2009 21:25:03 Jan-Oliver Wagner wrote:
> Hi,
>
> I'd like to call for a vote on Change Request #25 (OpenVAS-libnasl:
> Introducing support for WMI).
>
> From side +1

+1.
There is a small kind-of-typo in the CR-text, section 'Implementation 
Approach' (first sentence: available... available).

-- 
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 timb at nth-dimension.org.uk  Mon Feb  9 10:59:13 2009
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Mon, 9 Feb 2009 09:59:13 +0000
Subject: [Openvas-devel] Further code checks?
Message-ID: <200902090959.14326.timb@nth-dimension.org.uk>

All,

I've been running cppcheck on the OpenVAS code base for some time now.  Maybe 
we should consider it as an additional metric?

For reference, here's todays output:

tmb at sarpedon:~/Development/Private/Unpublished/OpenVAS/trunk$ 
cppcheck -a -f --unused-functions -q . > bah
[./openvas-client/libnessus/network.c:1381]: (always) Memory leak: b
[./openvas-client/nessus/html_graph_output.c:710]: (always) Memory leak: 
next_name
[./openvas-client/nessus/html_graph_output.c:967]: (always) Resource leak: 
chart
[./openvas-client/nessus/html_graph_output.c:1000]: (always) Resource leak: 
chart
[./openvas-client/nessus/html_graph_output.c:1030]: (always) Resource leak: 
chart
[./openvas-client/nessus/nessus.c:1322]: (always) Memory leak: session_id
[./openvas-client/nessus/parser.c:315]: (always) Memory leak: tmp
[./openvas-libraries/libopenvas/network.c:2509]: (always) Memory leak: b

I haven't had a chance to look at these yet.

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

From labeneator at gmail.com  Mon Feb  9 13:26:41 2009
From: labeneator at gmail.com (Laban Mwangi)
Date: Mon, 09 Feb 2009 15:26:41 +0300
Subject: [Openvas-devel] Further code checks?
In-Reply-To: <200902090959.14326.timb@nth-dimension.org.uk>
References: <200902090959.14326.timb@nth-dimension.org.uk>
Message-ID: <1234182401.4311.39.camel@hyperion.penguinlabs.co.ke>

Hi,
On Mon, 2009-02-09 at 09:59 +0000, Tim Brown wrote:
> All,
> 
> I've been running cppcheck on the OpenVAS code base for some time now.  Maybe 
> we should consider it as an additional metric?
> 
> For reference, here's todays output:
> 
> tmb at sarpedon:~/Development/Private/Unpublished/OpenVAS/trunk$ 
> cppcheck -a -f --unused-functions -q . > bah
> [./openvas-client/libnessus/network.c:1381]: (always) Memory leak: b
Freed in line ./openvas-client/libnessus/network.c:156  when the
connection is closed.
> [./openvas-client/nessus/html_graph_output.c:710]: (always) Memory leak: 
> next_name
False warning. Will always be freed
in ./openvas-client/libnessus/network.c:704
> [./openvas-client/nessus/html_graph_output.c:967]: (always) Resource leak: 
> chart
True. if num is false/0, chart will never be closed. - Fixed
> [./openvas-client/nessus/html_graph_output.c:1000]: (always) Resource leak: 
> chart
Same as above - Fixed
> [./openvas-client/nessus/html_graph_output.c:1030]: (always) Resource leak: 
> chart
Again - Fixed
> [./openvas-client/nessus/nessus.c:1322]: (always) Memory leak: session_id
True. - Fixed
> [./openvas-client/nessus/parser.c:315]: (always) Memory leak: tmp
False positive: Freed at line 731 same file.
> [./openvas-libraries/libopenvas/network.c:2509]: (always) Memory leak: b
> 
Looks like it's related to the first entry
(./openvas-client/libnessus/network.c:1381)
> I haven't had a chance to look at these yet.
> 
> Tim
-------------- 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/20090209/9896019d/attachment.pgp

From jan-oliver.wagner at intevation.de  Tue Feb 10 00:22:44 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Tue, 10 Feb 2009 00:22:44 +0100
Subject: [Openvas-devel] Network Inventory via OpenVAS
Message-ID: <200902100022.44712.jan-oliver.wagner@intevation.de>

Hi,

I'd like to have OpenVAS be able to collect a network inventory and report
it. Actually, sort of a network inventory happens anyway during a scan, so 
this is a natural consequence I guess.

Real nice summaries for the network appear to be a problem as it is
scanning per host.

So, I see a couple of questions from which a discussion might
end up with a good plan for a helpful inventory:

* Would it be possible or sensible to allow for a server side method
   to aggregate network data?
* Or would it be easier / more consistent to do an aggregation in the client?
* Does nmap already the job and should be used directly?
* Do standard network inventory specifications exists or at least some common  
   practice?

All the best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++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 robert.berkowitz at gmail.com  Tue Feb 10 01:53:26 2009
From: robert.berkowitz at gmail.com (Robert Berkowitz)
Date: Mon, 9 Feb 2009 19:53:26 -0500
Subject: [Openvas-devel] Network Inventory via OpenVAS
In-Reply-To: <200902100022.44712.jan-oliver.wagner@intevation.de>
References: <200902100022.44712.jan-oliver.wagner@intevation.de>
Message-ID: <8ce3eb500902091653o63a7f179v4ebe82d90d5fedd@mail.gmail.com>

For a very basic network/host inventory nmap accomplishes this quite
nicely. For more details you could obviously use something like the
SNMP host resource table and/or WMI information for Windows machines.
What sort of aggregation are you talking about in regards to network
inventory? Are you envisioning something grouped by node type, server
type, application type, etc...?

-Robert

On Mon, Feb 9, 2009 at 6:22 PM, Jan-Oliver Wagner
<jan-oliver.wagner at intevation.de> wrote:
> Hi,
>
> I'd like to have OpenVAS be able to collect a network inventory and report
> it. Actually, sort of a network inventory happens anyway during a scan, so
> this is a natural consequence I guess.
>
> Real nice summaries for the network appear to be a problem as it is
> scanning per host.
>
> So, I see a couple of questions from which a discussion might
> end up with a good plan for a helpful inventory:
>
> * Would it be possible or sensible to allow for a server side method
>   to aggregate network data?
> * Or would it be easier / more consistent to do an aggregation in the client?
> * Does nmap already the job and should be used directly?
> * Do standard network inventory specifications exists or at least some common
>   practice?
>
> All the best
>
>        Jan
>
> --
> Dr. Jan-Oliver Wagner | ++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
> _______________________________________________
> Openvas-devel mailing list
> Openvas-devel at wald.intevation.org
> http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
>



-- 
Robert Berkowitz
919.244.5704
robert.berkowitz at gmail.com

From c_edjenguele at yahoo.it  Tue Feb 10 09:23:58 2009
From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE)
Date: Tue, 10 Feb 2009 08:23:58 +0000 (GMT)
Subject: [Openvas-devel] Network Inventory via OpenVAS
References: <200902100022.44712.jan-oliver.wagner@intevation.de>
Message-ID: <478249.66844.qm@web28602.mail.ukl.yahoo.com>

Hello Jan,
I think it would be easier and more efficient to do an aggregation in the client side by implementing some Fingerprint plugins
NMAP works well but sometimes unreliable...
I have experience in low-level OS fingerprint techniques, it should be interesting to combine nmap result with some plugins
to make a very reliable OpenVAS network discovery module.

 ---
Christian Eric Edjenguele
IT Security Software Developer & Researcher
mobile: +39 3408580513



----- Messaggio originale -----
Da: Jan-Oliver Wagner <jan-oliver.wagner at intevation.de>
A: openvas-devel at wald.intevation.org
Inviato: Marted? 10 febbraio 2009, 0:22:44
Oggetto: [Openvas-devel] Network Inventory via OpenVAS

Hi,

I'd like to have OpenVAS be able to collect a network inventory and report
it. Actually, sort of a network inventory happens anyway during a scan, so 
this is a natural consequence I guess.

Real nice summaries for the network appear to be a problem as it is
scanning per host.

So, I see a couple of questions from which a discussion might
end up with a good plan for a helpful inventory:

* Would it be possible or sensible to allow for a server side method
   to aggregate network data?
* Or would it be easier / more consistent to do an aggregation in the client?
* Does nmap already the job and should be used directly?
* Do standard network inventory specifications exists or at least some common  
   practice?

All the best

    Jan

-- 
Dr. Jan-Oliver Wagner | ++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
_______________________________________________
Openvas-devel mailing list
Openvas-devel at wald.intevation..org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel



      Passa a Yahoo! Mail.

La webmail che ti offre GRATIS spazio illimitato, 
antispam e messenger integrato.
http://it.mail.yahoo.com/??????????????


From jan-oliver.wagner at intevation.de  Tue Feb 10 23:18:50 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Tue, 10 Feb 2009 23:18:50 +0100
Subject: [Openvas-devel] Network Inventory via OpenVAS
In-Reply-To: <8ce3eb500902091653o63a7f179v4ebe82d90d5fedd@mail.gmail.com>
References: <200902100022.44712.jan-oliver.wagner@intevation.de>
	<8ce3eb500902091653o63a7f179v4ebe82d90d5fedd@mail.gmail.com>
Message-ID: <200902102318.50784.jan-oliver.wagner@intevation.de>

On Tuesday 10 February 2009 01:53:26 Robert Berkowitz wrote:
> For a very basic network/host inventory nmap accomplishes this quite
> nicely. For more details you could obviously use something like the
> SNMP host resource table and/or WMI information for Windows machines.
> What sort of aggregation are you talking about in regards to network
> inventory? Are you envisioning something grouped by node type, server
> type, application type, etc...?

basically yes. An overview on whats out there on my network.
Later combined with policy preferences like "no NT4 allowed".

Best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++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 jan-oliver.wagner at intevation.de  Tue Feb 10 23:21:48 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Tue, 10 Feb 2009 23:21:48 +0100
Subject: [Openvas-devel] Network Inventory via OpenVAS
In-Reply-To: <478249.66844.qm@web28602.mail.ukl.yahoo.com>
References: <200902100022.44712.jan-oliver.wagner@intevation.de>
	<478249.66844.qm@web28602.mail.ukl.yahoo.com>
Message-ID: <200902102321.48932.jan-oliver.wagner@intevation.de>

On Tuesday 10 February 2009 09:23:58 Christian Eric EDJENGUELE wrote:
> I think it would be easier and more efficient to do an aggregation in the
> client side by implementing some Fingerprint plugins NMAP works well but
> sometimes unreliable...

Currently the client gets only plain text, so we need a format to parse
inventory information.

I try to not invent a new format for this. Are there good network inventory
formats already out there?
 
> I have experience in low-level OS fingerprint techniques, it should be
> interesting to combine nmap result with some plugins to make a very
> reliable OpenVAS network discovery module.

A combination sounds attractive. But how to accomplish this best?

Best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++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 bchandra at secpod.com  Wed Feb 11 08:34:00 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Wed, 11 Feb 2009 13:04:00 +0530
Subject: [Openvas-devel] Network Inventory via OpenVAS
In-Reply-To: <200902100022.44712.jan-oliver.wagner@intevation.de>
References: <200902100022.44712.jan-oliver.wagner@intevation.de>
Message-ID: <B608D13F4DE247538EB9A31A24F61BA2@bchandra>

-----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: Tuesday, February 10, 2009 4:53 AM
To: openvas-devel at wald.intevation.org
Subject: [Openvas-devel] Network Inventory via OpenVAS

> Hi,

> I'd like to have OpenVAS be able to collect a network inventory and report
> it. Actually, sort of a network inventory happens anyway during a scan, so

> this is a natural consequence I guess.

> Real nice summaries for the network appear to be a problem as it is
> scanning per host.

> So, I see a couple of questions from which a discussion might
> end up with a good plan for a helpful inventory:

> * Would it be possible or sensible to allow for a server side method
>   to aggregate network data?
> * Or would it be easier / more consistent to do an aggregation in the 
> client?

Client side would be good for report aggregation as it would be just an
extension to the client and won't interfere with the server. Gathering
information is anyway server's job but, how it is presented should be the
client's work. This would mean, we need to have a method to fetch all KB
items set. 

> * Does nmap already the job and should be used directly?

NMAP can do to an extent: host, port, and remotely accessible services.
Inventory would ideally be exhaustive information and lot of that
information has to be fetched through local checks. 

> * Do standard network inventory specifications exists or at least some 
> common  
>   practice?


Thanks,
Chandra.


From c_edjenguele at yahoo.it  Wed Feb 11 09:05:56 2009
From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE)
Date: Wed, 11 Feb 2009 08:05:56 +0000 (GMT)
Subject: [Openvas-devel] Network Inventory via OpenVAS
References: <200902100022.44712.jan-oliver.wagner@intevation.de>
	<478249.66844.qm@web28602.mail.ukl.yahoo.com>
	<200902102321.48932.jan-oliver.wagner@intevation.de>
Message-ID: <193201.50591.qm@web28611.mail.ukl.yahoo.com>

We can parse the nmap xml output, after scanning with os fingerprint option enabled -O2 

 ---
Christian Eric Edjenguele
IT Security Software Developer & Researcher
mobile: +39 3408580513



----- Messaggio originale -----
Da: Jan-Oliver Wagner <jan-oliver.wagner at intevation.de>
A: openvas-devel at wald.intevation.org
Inviato: Marted? 10 febbraio 2009, 23:21:48
Oggetto: Re: [Openvas-devel] Network Inventory via OpenVAS

On Tuesday 10 February 2009 09:23:58 Christian Eric EDJENGUELE wrote:
> I think it would be easier and more efficient to do an aggregation in the
> client side by implementing some Fingerprint plugins NMAP works well but
> sometimes unreliable...

Currently the client gets only plain text, so we need a format to parse
inventory information.

I try to not invent a new format for this. Are there good network inventory
formats already out there?

> I have experience in low-level OS fingerprint techniques, it should be
> interesting to combine nmap result with some plugins to make a very
> reliable OpenVAS network discovery module.

A combination sounds attractive. But how to accomplish this best?

Best

    Jan

-- 
Dr. Jan-Oliver Wagner | ++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
_______________________________________________
Openvas-devel mailing list
Openvas-devel at wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel



      Passa a Yahoo! Mail.

La webmail che ti offre GRATIS spazio illimitato, 
antispam e messenger integrato.
http://it.mail.yahoo.com/??????????????


From openvas-bugs at wald.intevation.org  Wed Feb 11 10:01:59 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Wed, 11 Feb 2009 10:01:59 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B886=5D_Secret/SSH/?=
	=?utf-8?q?socket_keeps_being_locked=2C_blocks_scan?=
Message-ID: <20090211090159.9378740750@pyrosoma.intevation.org>

Bugs item #886, was opened at 2009-02-11 09:01
Status: Open
Priority: 3
Submitted By: Felix Wolfsteller (felix)
Assigned to: Nobody (None)
Summary: Secret/SSH/socket keeps being locked, blocks scan 
Resolution: None
Severity: major
Version: v2.0
Component: openvas-server
Operating System: Linux
Product: OpenVAS
Hardware: None
URL: 


Initial Comment:
When doing a local check, the first registered socket seems to be blocked forever.
(I suspect a connection to bug 788 (http://bugs.openvas.org/788)
I digged into the code but the origin stays unclear for me (messages in the following extract stem from openvas-server/shared_socket.c)

ssh -v on the target responds:
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f

/var/log/openvas/openvasd.messages shows ("xyz" are sane values):
...
[Wed Feb 11 09:57:33 2009][25572] user xyz starts a new scan. Target(s) : xyz, with max_hosts = 20 and max_checks = 4
[Wed Feb 11 09:57:33 2009][25572] user xyz : testing xyz (xyz) [26846]
[Wed Feb 11 09:57:42 2009][26846] shared_socket: Secret/SSH/socket is unknown
[Wed Feb 11 09:57:44 2009][26846] shared_socket: Secret/SSH/socket is unknown
[Wed Feb 11 09:57:45 2009][26846] shared_socket: Process 26888 registers a shared socket (Secret/SSH/socket)
[Wed Feb 11 09:57:45 2009][26846] shared_socket: Secret/SSH/socket is busy (locked by 26888)
[Wed Feb 11 09:57:46 2009][26846] shared_socket: Secret/SSH/socket is busy (locked by 26888)
[Wed Feb 11 09:57:46 2009][26846] shared_socket: Secret/SSH/socket is busy (locked by 26888)
[Wed Feb 11 09:57:47 2009][26846] shared_socket: Secret/SSH/socket is busy (locked by 26888)
... continues like that ...

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

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

From scannersecurity at live.com  Wed Feb 11 16:53:36 2009
From: scannersecurity at live.com (s a)
Date: Wed, 11 Feb 2009 09:53:36 -0600
Subject: [Openvas-devel] Pcap blocking issue
Message-ID: <BAY114-W22DE18CE23FDD8B486733DD3BA0@phx.gbl>


If I am not mistaken nessus used to package pcap with it, and the pcap was setup to always be non-blocking. Now openvaslibraries uses the pcap that is already installed on the system and is blocking by default. So if you call a function that uses pcap such as Tcp_Ping() on an IP adress that is behind a firewall or down then pcap will block forever waiting on the first port until the plugin just times out. I believe that the uses of pcap in openvas were intended to be non-blocking. For example Looking at bpf_share.c, go to the function bpf_next_tv. Here you see:

 do {
  p = (u_char*)pcap_next(pcaps[bpf], &head);
  *caplen  = head.caplen;
  if ( p != NULL ) break;
  gettimeofday(&now, NULL);
 } while ( !((now.tv_sec > timeout.tv_sec) ||
             (now.tv_sec == timeout.tv_sec && now.tv_usec >= timeout.tv_usec ) ));

The function has built in timeout checks so that if the port has not responded in the given time it times out, so that tcp_ping for example can then try the next port in the list. With pcap being blocking that call to pcap_next blocks forever. The fix is simple and just requires calling pcap_setnonblock on the pcap device. So, the question is does openvas require pcap to be blocking or non blocking? Settting it as non-blocking doesnt appear to break anything. Thoughts?

_________________________________________________________________
Windows Live?: Keep your life in sync. 
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090211/3212d02e/attachment.htm

From jan-oliver.wagner at intevation.de  Thu Feb 12 16:32:30 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 12 Feb 2009 16:32:30 +0100
Subject: [Openvas-devel] Planning openvas-server 2.0.1
Message-ID: <200902121632.32190.jan-oliver.wagner@intevation.de>

Hello,

as the next step after new openvas-libraries and openvas-libnasl, we now need
an update of openvas-server to finally get into effect some new features
and to prepare further ones that will be usable with new OpenVAS-Client and
new NASL scripts respectively.

Changes that take effect:

* New default port: 9390 (as assigned by IANA)
* Bug-fix: now during startup, openvasd will show the correct
   total number of plugins and not count the *.asc signature files
   anymore. 
* user-specific cache not initialized anymore (.desc in
  /var/lib/openvas/users/USER/plugins/ not created anymore)
* It is not mandatory to be root for stating openvasd anymore.
   This makes testing the server a lot easier for developers/.
   Of course, when started as low-privileged user not all
   features can be executed by openvasd.
* New server preference "cache_folder" allows to define the location
   of the cache (so far it was ($plugins_folder/.desc).
   Default for new openvasd.conf is now /var/cache/openvas
   Existing installations need to add cache_folder = /var/cache/openvas
   manually to openvasd.conf and take care the directory exists.
* Having a directory structure in $plugin_folder is now supported. openvasd
   will recurse into the sub directories.
* New option for openvasd.conf "include_folders" allows to specify
   search paths for NASL include directive. This aids the use of
   subdirectories for plugins. By default it is $plugins_folder to be
   compatible with old flat(all in one directory) style 

Note: The OpenVAS NVT feed will not use the new features for subdirs and include paths
as long as the OpenVAS 1.0.x and OpenVAS 2.0.0 releases are supported.
An exception might be OVAL-support.

Changes that prepare features:

* per-target SSH credentials settings (needs new client and new ssh_authorization.nasl)
* openvasd-config offers some more options (sysconfdir). This will allows add-on tools
   to learn about the OpenVAS installation without guessing.

Please let us know if you want anything in this module before the release.

It is planned to have the release mid to end of next week.

Best

        Jan

-- 
Dr. Jan-Oliver Wagner | ++49-541-335083-0  |  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 d.jagdmann at dn-systems.de  Fri Feb 13 23:09:05 2009
From: d.jagdmann at dn-systems.de (Dirk Jagdmann)
Date: Fri, 13 Feb 2009 14:09:05 -0800
Subject: [Openvas-devel] Wald SVN and Tortoise SVN
Message-ID: <4995EF81.1050905@dn-systems.de>

Hello developers,

has somebody managed to access the developer SVN on wald.intevation.org
with the Windows Tortoise SVN client?

So far I have created a SSH-Key with putty and could authenticate on
svn.wald.intevation.org, but I could not login into a UNIX shell (but I
think this is intended). However when using the following URL in
Tortoise SVN svn+ssh://doj at svn.wald.intevation.org/openvas/trunk it
makes a connection to the server, but fails with "no supported
authentication methods available".

I can access the SVN with a second SSH-Key and standard OpenSSH and SVN
from Linux without problems.

-- 
Dirk Jagdmann <d.jagdmann at dn-systems.de> : Coder
Tel. +49-5121-28989-15
--
DN-Systems Enterprise Internet Solutions GmbH
Hornemannstr. 11 31137 Hildesheim, Germany
Tel. +49-5121-28989-0 Fax. +49-5121-28989-11
Handelsregister HRB-3213 Amtsgericht Hildesheim
Gesch?ftsf?hrer: Lukas Grunwald

From jan-oliver.wagner at intevation.de  Sun Feb 15 20:25:30 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Sun, 15 Feb 2009 20:25:30 +0100
Subject: [Openvas-devel] Wald SVN and Tortoise SVN
In-Reply-To: <4995EF81.1050905@dn-systems.de>
References: <4995EF81.1050905@dn-systems.de>
Message-ID: <200902152025.30616.jan-oliver.wagner@intevation.de>

On Friday 13 February 2009 23:09:05 Dirk Jagdmann wrote:
> has somebody managed to access the developer SVN on wald.intevation.org
> with the Windows Tortoise SVN client?

I know that several people use Tortoise for other projects managed on Wald.
So, at least for some cases it works.
But honestly, I have no idea about Tortoise and why it might fail.

Best

	Jan
 
-- 
Dr. Jan-Oliver Wagner | ++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 openvas-bugs at wald.intevation.org  Mon Feb 16 14:53:06 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Mon, 16 Feb 2009 14:53:06 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B888=5D_Impossible_?=
	=?utf-8?q?to_override_LDFLAGS_which_breaks_builds_on_Mandriva_2009?=
Message-ID: <20090216135306.7CC6240719@pyrosoma.intevation.org>

Bugs item #888, was opened at 2009-02-16 13:53
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: Impossible to override LDFLAGS which breaks builds on Mandriva 2009 
Resolution: None
Severity: None
Version: v2.0
Component: openvas-libraries
Operating System: Linux
Product: OpenVAS
Hardware: None
URL: 


Initial Comment:
The standard LDFLAGS on Mandriva 2009 are "-Wl,--as-needed -Wl,--no-undefined" of which "-Wl,--no-undefined" causes the build failing because it can't find the gnutls libraries (which obviously are installed).

Manually removing "-Wl,--no-undefined" makes it build just fine but doesn't really help since it is for some unknown reason impossible to override the LDFLAGS definition.

This could be related to another bug where normal "make && make install" compiles it actually 3 times and non-standard CFLAGS is only respected during the first build.

Attached is the build log on Mandriva 2009. In line #761 you can see the standard LDFLAGS definition and line #765 proves that it got successfully overridden but still the original definition is used as you can see in line #883.

Please have a look at your makefiles and fix this.

PS: That surely is no chroot issue since rpmbuild on a real Mandriva 2009 system throws the exact same error.

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

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

From openvas-bugs at wald.intevation.org  Mon Feb 16 15:11:19 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Mon, 16 Feb 2009 15:11:19 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?b?W29wZW52YXMtQnVnc11bODg5XSBtYWtlICYm?=
	=?utf-8?q?_make_install_compiles_stuff_3_times?=
Message-ID: <20090216141119.9511640719@pyrosoma.intevation.org>

Bugs item #889, was opened at 2009-02-16 14:11
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: make && make install compiles stuff 3 times 
Resolution: None
Severity: None
Version: v2.0
Component: openvas-libraries
Operating System: Linux
Product: OpenVAS
Hardware: None
URL: 


Initial Comment:
Some time ago I noticed that a standard "make && make install" results in _3_ compilation runs and only the first one respects a set CFLAGS environment variable. The first run is normally triggered by "make" and the other two result from the global "make install" and the "make install" calls within the library subdirectories.

Attached is the build log from openSUSE 10.3. The normal run starts at line #633 and uses correct CFLAGS. The other two start in line #792 & # 929 and don't respect the custom CFLAGS setting.

The attached patch removes the build dependency for the install calls but this is NOT the correct way since make should notice that the stuff is already build (it is just a crude hack that allows me to package it correctly atm).

This might be related to bug #888 which breaks builds on Mandriva 2009 because it doesn't respect overridden LDFLAGS.

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

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

From openvas at markwallis.id.au  Tue Feb 17 07:46:58 2009
From: openvas at markwallis.id.au (Mark Wallis)
Date: Tue, 17 Feb 2009 17:46:58 +1100
Subject: [Openvas-devel] [RFC PATCH] Allowing filtering of issues during
	report export
Message-ID: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>

Hi everyone,

Please find attached a patch for comment. The patch adds a new feature  
that allows a user to filter events during report export based on  
their severity. This gives users the freedom to export reports that  
only contain high severity, high and medium severity or all severity  
events. I find this useful when I want to provide a report to upper  
management and wish to exclude all the 'Security Note' data which  
isn't going to provide them much value.

Would appreciate any comments and I'm more than happy to update the  
patch with any recommendations (especially around coding style). If  
someone has a better way todo this then that is even better :-)

Regards,
Mark Wallis
mwallis at serialmonkey.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090217/fa6cb180/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-client-report-filterontype.patch
Type: application/octet-stream
Size: 9905 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090217/fa6cb180/openvas-client-report-filterontype.obj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090217/fa6cb180/attachment-0001.htm

From jan-oliver.wagner at intevation.de  Tue Feb 17 08:51:36 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Tue, 17 Feb 2009 08:51:36 +0100
Subject: [Openvas-devel] [RFC PATCH] Allowing filtering of issues during
	report export
In-Reply-To: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>
References: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>
Message-ID: <200902170851.37860.jan-oliver.wagner@intevation.de>

Hi Mark,

On Dienstag, 17. Februar 2009, Mark Wallis wrote:
> Please find attached a patch for comment. The patch adds a new feature  
> that allows a user to filter events during report export based on  
> their severity. This gives users the freedom to export reports that  
> only contain high severity, high and medium severity or all severity  
> events. I find this useful when I want to provide a report to upper  
> management and wish to exclude all the 'Security Note' data which  
> isn't going to provide them much value.
> 
> Would appreciate any comments and I'm more than happy to update the  
> patch with any recommendations (especially around coding style). If  
> someone has a better way todo this then that is even better :-)

thanks a lot for your patch. We'll try out.

Are you aware of Change Request #18 which is aiming at a similar issue?

  http://www.openvas.org/openvas-cr-18.html

(It introduces filters for severity and is half-implemented in current SVN.)

Best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++49-541-335083-0  |  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 Feb 17 09:16:15 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Tue, 17 Feb 2009 09:16:15 +0100
Subject: [Openvas-devel] [RFC PATCH] Allowing filtering of issues during
	report export
In-Reply-To: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>
References: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>
Message-ID: <200902170916.15896.felix.wolfsteller@intevation.de>

Hi Mark
Looks nice to me.

> Would appreciate any comments and I'm more than happy to update the
> patch with any recommendations (especially around coding style). If
> someone has a better way todo this then that is even better :-)
In a refreshingly peaceful discussion we settled on the GNU Coding Standards 
(http://www.openvas.org/openvas-cr-19.html) and doxygen documentation blocks.
Otherwise I think you took the shortest way possible.

Note that you are welcome in the IRC channel 
(http://www.openvas.org/online-chat.html). There are some statistics showing 
that you might not meet too many people from your timezone there, though. 
(btw, are the statistics based on GMT?)

--felix

On Tuesday 17 February 2009 07:46:58 Mark Wallis wrote:
> Hi everyone,
>
> Please find attached a patch for comment. The patch adds a new feature
> that allows a user to filter events during report export based on
> their severity. This gives users the freedom to export reports that
> only contain high severity, high and medium severity or all severity
> events. I find this useful when I want to provide a report to upper
> management and wish to exclude all the 'Security Note' data which
> isn't going to provide them much value.
>
> Would appreciate any comments and I'm more than happy to update the
> patch with any recommendations (especially around coding style). If
> someone has a better way todo this then that is even better :-)
>
> Regards,
> Mark Wallis
> mwallis at serialmonkey.com


-- 
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 openvas at markwallis.id.au  Tue Feb 17 13:13:38 2009
From: openvas at markwallis.id.au (Mark Wallis)
Date: Tue, 17 Feb 2009 23:13:38 +1100
Subject: [Openvas-devel] [RFC PATCH] Allowing filtering of issues during
	report export
In-Reply-To: <200902170851.37860.jan-oliver.wagner@intevation.de>
References: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>
	<200902170851.37860.jan-oliver.wagner@intevation.de>
Message-ID: <453C6A09-261A-4EF3-ABD6-14FA21F7EB9B@markwallis.id.au>

Hi Jan,

On 17/02/2009, at 6:51 PM, Jan-Oliver Wagner wrote:

> Are you aware of Change Request #18 which is aiming at a similar  
> issue?
>
>  http://www.openvas.org/openvas-cr-18.html
>
> (It introduces filters for severity and is half-implemented in  
> current SVN.)

I wasn't aware of that CR, thanks for the link. I agree those features  
would be fantastic - but it's not 100% what I was after. I like to be  
able to produce a 'high risk only' report to give people to focus on  
without having to 'downgrade' all the other alerts. In a way, I would  
like to be able to keep the scan results and the report formatting  
separated. I understand though that my needs are probably the edge- 
case here.

If there are any changes you want me to make to the patch let me know,  
otherwise I might have a look through the other existing change  
requests and see if there is anything I can investigate.

Thanks,
Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090217/701a5523/attachment.html

From matt at mundell.ukfsn.org  Tue Feb 17 15:10:16 2009
From: matt at mundell.ukfsn.org (Matthew Mundell)
Date: 17 Feb 2009 14:10:16 GMT
Subject: [Openvas-devel] Updated OMP Specification
In-Reply-To: Message of Thu, 29 Jan 2009 10:24:56 +0100.
	<20090129092456.GB21185@intevation.de>
Message-ID: <20090217141001.E658CDEB8A@mail.ukfsn.org>

> - The get_nvt_details_oid and get_nvt_details_all commands have been
>   merged into the get_nvt_details command which now takes an optional
>   oid attribute.

How about merging get_nvt_details and get_nvt_all into a single command?

	<get_nvt oid="1.3.6.1.4.1.25623.1.7.13005" details="t" />

From openvas-bugs at wald.intevation.org  Wed Feb 18 11:10:43 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Wed, 18 Feb 2009 11:10:43 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B891=5D_Client_segf?=
	=?utf-8?q?aults_when_reconnecting_to_a_changed_server?=
Message-ID: <20090218101043.B4ECF40732@pyrosoma.intevation.org>

Bugs item #891, was opened at 2009-02-18 11:10
Status: Open
Priority: 3
Submitted By: Michael Wiegand (mwiegand)
Assigned to: Nobody (None)
Summary: Client segfaults when reconnecting to a changed server 
Resolution: Accepted As Bug
Severity: minor
Version: v2.0
Component: openvas-client
Operating System: Linux
Product: OpenVAS
Hardware: PC
URL: 


Initial Comment:
I've been finally able to get a backtrace for a segfault in the client I've been observing for quite a while. See the attached file for the backtrace.

What I did:
1) Start the server.
2) Start the client.
3) Connect to the server.
4) Disconnect from the server, leave client running.
5) Kill server.
6) Perform a minimal change in the server code; in my case, commenting out one line in openvasd/oval_plugins.c
7) Start the server.
8) Connect to the server using the previous scope.

The client opens the "Connecting..." window and immediately segfaults.

The backtrace looks like the bug might be Gtk-related.

This bug will hardly be an issue in a non-developer environment, this is why I'm setting the severity to "minor".

Has anybody else observed this bug? Questions and suggestions are welcome.

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

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

From sgros.ml at gmail.com  Thu Feb 19 08:51:06 2009
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Thu, 19 Feb 2009 08:51:06 +0100
Subject: [Openvas-devel] Next steps...
Message-ID: <499D0F6A.7090903@gmail.com>

Well, after patch for plugins has been integrated, I suppose I could try 
to do something else. There are three possibilities:

1. there are places where word nessus is still mentioned (licenses 
excluded). this should be relatively easily to change and it would be a 
short term task

2. i could start with IPv6 implementation. this is a longer term task 
and it would require first that we agree on how to abstract IPv4/IPv6 
specific code from the majority of the openvas

3. starting to phase out openvas internal implementation of basic 
algorithms and data structures and replace them with glib's structures. 
this is the most complex task of the three.

I could start with 1, as it is the easiest task. Is that ok?

Stjepan

From jan-oliver.wagner at intevation.de  Thu Feb 19 09:09:44 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 19 Feb 2009 09:09:44 +0100
Subject: [Openvas-devel] Next steps...
In-Reply-To: <499D0F6A.7090903@gmail.com>
References: <499D0F6A.7090903@gmail.com>
Message-ID: <200902190909.47359.jan-oliver.wagner@intevation.de>

On Donnerstag, 19. Februar 2009, Stjepan Gros wrote:
> Well, after patch for plugins has been integrated, I suppose I could try 
> to do something else. There are three possibilities:
> 
> 1. there are places where word nessus is still mentioned (licenses 
> excluded). this should be relatively easily to change and it would be a 
> short term task

I prefer to have this done for the next major release.
There are many function names etc. that contain "nessus".
Renaming them would mean to break API.
So, probably it is better to begin the tabula rasa after the 2.0 series is
branched and trunk heading for 3.0.

> 2. i could start with IPv6 implementation. this is a longer term task 
> and it would require first that we agree on how to abstract IPv4/IPv6 
> specific code from the majority of the openvas

That'll be a good new feature. You could start with further analysis and
first small patches (please keep them as small at possible ;-).

> 3. starting to phase out openvas internal implementation of basic 
> algorithms and data structures and replace them with glib's structures. 
> this is the most complex task of the three.

I am moving my mind here and have the idea to start another
library inside openvas-libraries: "libopenvascommon".
My hope is to have a sample and RFC within the next weeks.

However, other aspects come immediatley to my mind that
could be done independent of larger strategies:
For example
* use the glib ini-file API for all .conf files.
* have timestamps for the openvasd.dump file

> I could start with 1, as it is the easiest task. Is that ok?

Most intersting/challenging is probably 2.
3 allows for some simpler, "programming" tasks.
1 should be postponed. 

Of course we like to have all of them to be worked on :-)

Best

	Jan
-- 
Dr. Jan-Oliver Wagner | ++49-541-335083-0  |  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  Thu Feb 19 09:57:39 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 19 Feb 2009 09:57:39 +0100
Subject: [Openvas-devel] Planning openvas-client 2.0.2
Message-ID: <200902190957.41483.jan-oliver.wagner@intevation.de>

Hello,

now that the server modules are updated, it is also time to release
a new version of the openvas-client with all the accumulated fixes
and improvements.

I'd like to have the new release happen in February.

We need you for:
* translations (please simply ask how to do it if you don't know and
   let us know anyway if you start to work on a specific translation to avoid
   doubled effords)
* testing, testing, testing - as usual ;-)

Most shiny new feature:
* The SSH key management and its use for ssh_authorization
   (I will send a separate email to describe how to use it)

What might still be done before actual release:
* integer widgets ("spinners") for further values where integer is requested
* perhaps: the GUI for false positive management (which would be the second
   shiny new feature then :-)
* Anything I forgot?


Changes that happened so far:

* Improved buggy timeout-setting functionality
  (made the timout setting robust against misuse (only integers allowed now)
  and moved it into the plugin details dialog in order to avoid extra-clicks
  and in order to allow for a more holistic overview on a plugin.
* Added counter column for log messages.
* Fixed bug #867 	(http://bugs.openvas.org/867) which caused a corrupted protocol
  attribute when service names contained slashes. This also fixes another
  bug which caused service names to show up in the protocol attribute.
  NB: This causes some port elements to have empty protocol attributes
  when the protocol information was not sent correctly by the server. This
  appens when then messages does not relate to a specific port, but to
  the attacked host in general (port 0 in NASL).
* First step for false positives management (according to CR#18,
  http://www.openvas.org/openvas-cr-18.html).
  You will notice a column "FP", but there is no GUI yet that allows
  for easy management of False Positives.
* Fixed bug: When no_nasl_check==no, signatures were not found due to
  sometimes different "fingerprint" length.
* Fixed bug: Server preference setting did (and partially still does) not
  override values local to the client, making it impossible to read the real
  servers value. Fixed for nasl_no_signature_check.
* Fixed bug: unknown nvt signatures were not always listed in plugin info dialog
* Made the SSH key manager dialog ready for production mode (a new ssh_authorization.nasl is
   required for this feature which will be send to this list shortly)
   This relates to CR#20 (http://www.openvas.org/openvas-cr-20.html)
* Default port changed from 1241 to 9390 (which was recently assigned by IANA) 
* Numerous code cleanups and code documentations effords
* Automated source code documentation procedure via doxygen
* Fixed bug #858 	(http://bugs.openvas.org/858) which cause a segmentation fault when
   trying to list preferences or plugins without enabling batch mode. 


Please let us know if you want anything in this module before the release.

It is planned to have the release by end of february.

Best

        Jan

-- 
Dr. Jan-Oliver Wagner | ++49-541-335083-0  |  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  Thu Feb 19 11:34:15 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 19 Feb 2009 11:34:15 +0100
Subject: [Openvas-devel] About the new SSH management and per-target feature
	and its effects
Message-ID: <200902191134.17394.jan-oliver.wagner@intevation.de>

Hi,

with the upcoming 2.0.2 release of openvas-client we will
introduce a shiny new feature: the SSH key managment
according to CR#20, http://www.openvas.org/openvas-cr-20.html.

It is in SVN already of course.

The server side (openvas-server 2.0.1) is already prepared for the
new plugin preferences.

Whats missing is a new "ssh_authorization.nasl".
It is attached to this email but not yet checked in.

!!!!!!!!!!
It is highly appreciated if some of you could test this feature,
preferable those of you who do local security checks.
And especially those who use also direct login/password methods.
!!!!!!!!!!

Can we live with the effects of this new version?

Effects for OpenVAS 1.0 users:
The client plugin prefrences for ssh_authorization have a additional parameter
"Use per-target login information". In case they check it, local security checks won't
work anymore.

Effects for openvas-server <= 2.0.0 and OpenVAS-Client <= 2.0.1 users:
The client will pop up warnings about an unknown preference type.
And also the same is true as for OpenVAS 1.0 users.

Effects for openvas-server >=2.0.1 and OpenVAS-Client >= 2.0.2 users:
You can check "Use per-target login information" and then use the SSH keys
configured in the OpenVAS SSH-key manager (accessible via File->Preferences).

Note for login/password users (i.e. no key-based log-in): This currently conflicts
with the SSH-key-based per-host method. You need to decide whether
to use direct login or to use key-base login - you can't mix the methods

Best

	Jan
-- 
Dr. Jan-Oliver Wagner | ++49-541-335083-0  |  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: ssh_authorization.nasl
Type: text/x-java
Size: 4049 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090219/cd51a8b3/ssh_authorization.java

From jan-oliver.wagner at intevation.de  Thu Feb 19 14:28:29 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu, 19 Feb 2009 14:28:29 +0100
Subject: [Openvas-devel] Patch to overcome store failures
Message-ID: <200902191428.35234.jan-oliver.wagner@intevation.de>

Hi,

attached is a simple patch (that I never tried!) to allow to use
a script that exceeds some of the size limits of the store.

Sample case is that you have required_keys (in total!) exceed 128
characters.

Perhaps it helps. Let me know.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++49-541-335083-0  |  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: openvasd-overcome-store-failure.patch
Type: text/x-diff
Size: 659 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090219/aeed3bf2/openvasd-overcome-store-failure.bin

From openvas-bugs at wald.intevation.org  Fri Feb 20 09:27:16 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Feb 2009 09:27:16 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B893=5D_openvasd_do?=
	=?utf-8?q?es_not_warn_about_missing_certificate_started_in_daemon_?=
	=?utf-8?q?mode?=
Message-ID: <20090220082716.EE64C4077A@pyrosoma.intevation.org>

Bugs item #893, was opened at 2009-02-20 08:27
Status: Open
Priority: 3
Submitted By: Felix Wolfsteller (felix)
Assigned to: Nobody (None)
Summary: openvasd does not warn about missing certificate started in daemon mode 
Resolution: None
Severity: trivial
Version: v2.0
Component: None
Operating System: Linux
Product: OpenVAS
Hardware: None
URL: 


Initial Comment:
1) install fresh server, but no certificate or user
2) start in daemon mode
| user at host:~# openvasd -D
| All plugins loaded
3) server is not actually running, warning appears only in non-daemon mode
| user at host:~# openvasd
| All plugins loaded
| *** 'ca_file' is not set - did you run openvas-mkcert?

That behaviour is a bit misleading, openvas-server should emit warning about missing ca_file also in daemon mode and in both cases make clear that it cant live without.


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

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

From meyer at strato-rz.de  Sun Feb 22 16:45:49 2009
From: meyer at strato-rz.de (Michael Meyer)
Date: Sun, 22 Feb 2009 16:45:49 +0100
Subject: [Openvas-devel] [openvas-libraries] www_funcs.c -> httpver is
	reduced
Message-ID: <20090222154549.GA22543@strato-rz.de>

Hello,

,---[ openvas-libnasl/nasl/nasl_http.c
| [...]
| 127 url = build_encode_URL(script_infos, keyword, NULL, item, "HTTP/1.1");
| [...]
| 144 url = build_encode_URL(script_infos, keyword, NULL, item, "HTTP/1.0\r\n");
| [...]
`---|

This sets HTTP-Version to 1.1 or 1.0. So far so good.

,---[ test.nasl ]
| [...]
| url = string(dir, "/index.php"); 
| req = http_get(item:url, port:port);
| buf = http_keepalive_send_recv(port:port, data:req, bodyonly:FALSE); 
| display(req, "-->\n", buf);
| [...]
`---|

,---[ openvas-nasl -X -t ... test.nasl ]
| GET /index.php HTTP/1.
| Connection: Close
| Host: xxxxxxxxxxx.xx
| Pragma: no-cache
| User-Agent: Mozilla/4.75 [en] (X11, U; Nessus)
| Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
| Accept-Language: en
| Accept-Charset: iso-8859-1,*,utf-8
| -->
| HTTP/1.1 400 Bad Request
| Date: Sun, 22 Feb 2009 15:15:22 GMT
| Server: Apache
| Connection: close
| Content-Type: text/html; charset=iso-8859-1
|
| <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
| <HTML><HEAD>
| <TITLE>400 Bad Request</TITLE>
| </HEAD><BODY>
| <H1>Bad Request</H1>
| Your browser sent a request that this server could not understand.<P>
| The request line contained invalid characters following the protocol string.<P>
| <P>
|</BODY></HTML>
`---|

As you can see, HTTP-Version is reduced from "HTTP/1.1" to "HTTP/1.". On some webservers
this leads in a "400 Bad Request".

###########################################################################################
--- openvas-libraries-2.0.1/libopenvas/www_funcs.c      2009-01-26 08:21:07.000000000 +0100
+++ openvas-libraries-2.0.1.1/libopenvas/www_funcs.c
2009-02-22 15:37:55.000000000 +0100
@@ -467,7 +467,7 @@
          fprintf(stderr, "NIDS/HTTP/protocol_string = %s\n", s);
	   #endif
          }
-      l += strlen(httpver) + 1;
+      l += strlen(httpver) + 2;
     }
###########################################################################################

I have not really an idea why (;-)), but this patch helps to solve this issue.

Micha

From d.jagdmann at dn-systems.de  Sun Feb 22 16:58:48 2009
From: d.jagdmann at dn-systems.de (Dirk Jagdmann)
Date: Sun, 22 Feb 2009 07:58:48 -0800
Subject: [Openvas-devel] [openvas-libraries] www_funcs.c -> httpver is
 reduced
In-Reply-To: <20090222154549.GA22543@strato-rz.de>
References: <20090222154549.GA22543@strato-rz.de>
Message-ID: <49A17638.5020304@dn-systems.de>

> ###########################################################################################
> --- openvas-libraries-2.0.1/libopenvas/www_funcs.c      2009-01-26 08:21:07.000000000 +0100
> +++ openvas-libraries-2.0.1.1/libopenvas/www_funcs.c
> 2009-02-22 15:37:55.000000000 +0100
> @@ -467,7 +467,7 @@
>           fprintf(stderr, "NIDS/HTTP/protocol_string = %s\n", s);
> 	   #endif
>           }
> -      l += strlen(httpver) + 1;
> +      l += strlen(httpver) + 2;
>      }
> ###########################################################################################
> 
> I have not really an idea why (;-)), but this patch helps to solve this issue.

I guest because \r\n will be added to the request line.

-- 
Dirk Jagdmann <d.jagdmann at dn-systems.de> : Coder
Tel. +49-5121-28989-15
-- 
DN-Systems Enterprise Internet Solutions GmbH
Hornemannstr. 11 31137 Hildesheim, Germany
Tel. +49-5121-28989-0 Fax. +49-5121-28989-11
Handelsregister HRB-3213 Amtsgericht Hildesheim
Gesch?ftsf?hrer: Lukas Grunwald

From jan-oliver.wagner at intevation.de  Sun Feb 22 18:55:03 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Sun, 22 Feb 2009 18:55:03 +0100
Subject: [Openvas-devel] [openvas-libraries] www_funcs.c -> httpver is
	reduced
In-Reply-To: <20090222154549.GA22543@strato-rz.de>
References: <20090222154549.GA22543@strato-rz.de>
Message-ID: <200902221855.03493.jan-oliver.wagner@intevation.de>

On Sunday 22 February 2009 16:45:49 Michael Meyer wrote:
> I have not really an idea why (;-)), but this patch helps to solve this
> issue.

well, it is not the first time such a wrong length calculation is detected
in the old Nessus code. Thanks for spotting this!

Best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++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 felix.wolfsteller at intevation.de  Mon Feb 23 10:33:37 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Mon, 23 Feb 2009 10:33:37 +0100
Subject: [Openvas-devel] [RFC PATCH] Allowing filtering of issues during
	report export
In-Reply-To: <453C6A09-261A-4EF3-ABD6-14FA21F7EB9B@markwallis.id.au>
References: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>
	<200902170851.37860.jan-oliver.wagner@intevation.de>
	<453C6A09-261A-4EF3-ABD6-14FA21F7EB9B@markwallis.id.au>
Message-ID: <200902231033.37382.felix.wolfsteller@intevation.de>

Hi Mark
I took a quick, second look at your patch.

What is missing imho:
* The filter does not effect nbe and pdf export if i am not mistaken. Quite 
important.
* A solution with bit sets instead of defines (SAVE_DETAIL_ALL, 
SAVE_DETAIL_HIGHMED) might make it easier to incorporate other levels at a 
later stage. This could be reflected in the GUI by checkboxes (so that you 
could en/disable every level for itself), but I find atm the combobox work 
equally fine. I was sure that the GLib brings a handy support for bit 
sets/masks, but I do not find it right now.

Other than that I find its a nice feature.
But I also see that report generation needs a lot of care.

-- felix

On Tuesday 17 February 2009 13:13:38 Mark Wallis wrote:
> Hi Jan,
>
> On 17/02/2009, at 6:51 PM, Jan-Oliver Wagner wrote:
> > Are you aware of Change Request #18 which is aiming at a similar
> > issue?
> >
> >  http://www.openvas.org/openvas-cr-18.html
> >
> > (It introduces filters for severity and is half-implemented in
> > current SVN.)
>
> I wasn't aware of that CR, thanks for the link. I agree those features
> would be fantastic - but it's not 100% what I was after. I like to be
> able to produce a 'high risk only' report to give people to focus on
> without having to 'downgrade' all the other alerts. In a way, I would
> like to be able to keep the scan results and the report formatting
> separated. I understand though that my needs are probably the edge-
> case here.
>
> If there are any changes you want me to make to the patch let me know,
> otherwise I might have a look through the other existing change
> requests and see if there is anything I can investigate.
>
> Thanks,
> Mark.


-- 
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 openvas at markwallis.id.au  Tue Feb 24 14:05:52 2009
From: openvas at markwallis.id.au (Mark Wallis)
Date: Wed, 25 Feb 2009 00:05:52 +1100
Subject: [Openvas-devel] [RFC PATCH] Allowing filtering of issues during
	report export
In-Reply-To: <200902231033.37382.felix.wolfsteller@intevation.de>
References: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>
	<200902170851.37860.jan-oliver.wagner@intevation.de>
	<453C6A09-261A-4EF3-ABD6-14FA21F7EB9B@markwallis.id.au>
	<200902231033.37382.felix.wolfsteller@intevation.de>
Message-ID: <3289CBE5-7B13-4FC4-9C5C-7D266D4D58F5@markwallis.id.au>

On 23/02/2009, at 8:33 PM, Felix Wolfsteller wrote:

> I took a quick, second look at your patch.

Thanks Felix.

> What is missing imho:
> * The filter does not effect nbe and pdf export if i am not  
> mistaken. Quite
> important.

The filter as it stands does not affect NBE, XML or PDF. I agree that  
I should get this working for PDF.

For NBE/XML though I feel these are a special case. The format types,  
to me, can be broken into two groups.

HTML, Latex, Text, HTML_Graph and PDF all represents "reports" that  
can you generate from the data.

NBE and XML though represent exports of the data itself into another  
raw format.

I'm thinking, perhaps we should be breaking these into two separate  
menu items. A 'Report' feature and an 'Export' feature. I cannot see  
the business case where filtering data out of an NBE/XML export would  
be beneficial.

Worst case, perhaps I should gray the new combo box out when NBE or  
XML is selected as the format ?

> * A solution with bit sets instead of defines (SAVE_DETAIL_ALL,
> SAVE_DETAIL_HIGHMED) might make it easier to incorporate other  
> levels at a
> later stage. This could be reflected in the GUI by checkboxes (so  
> that you
> could en/disable every level for itself), but I find atm the  
> combobox work
> equally fine. I was sure that the GLib brings a handy support for bit
> sets/masks, but I do not find it right now.

Good idea. I can rework things to use bitmasks behind the scene's. I  
suggest though leaving the combo box as is rather than replacing it  
with a list of check box's. At this stage, with only three levels of  
detail, I think the dropdown box is usable enough without making the  
page any more cluttered.

> But I also see that report generation needs a lot of care.

The switch() in report-save.c:file_save_ok_callback does seem a little  
confusing to me in the way that each report type is generated slightly  
differently. For example, the HTML and latex types both use the  
backend_convert function and then pass the returned arglist through  
another function which does the formatting. The XML_NG clause though  
uses a specialised backend_to_xml_ng function, and the PDF clause uses  
a completely different method all together.

Perhaps there is a way that we can clean this area of code up to allow  
us to easily add new report types down the track ?

Regards,
Mark Wallis
mwallis at serialmonkey.com

From jan-oliver.wagner at intevation.de  Tue Feb 24 20:10:25 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Tue, 24 Feb 2009 20:10:25 +0100
Subject: [Openvas-devel] [RFC PATCH] Allowing filtering of issues during
	report export
In-Reply-To: <3289CBE5-7B13-4FC4-9C5C-7D266D4D58F5@markwallis.id.au>
References: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>
	<200902231033.37382.felix.wolfsteller@intevation.de>
	<3289CBE5-7B13-4FC4-9C5C-7D266D4D58F5@markwallis.id.au>
Message-ID: <200902242010.29019.jan-oliver.wagner@intevation.de>

On Dienstag, 24. Februar 2009, Mark Wallis wrote:
> The switch() in report-save.c:file_save_ok_callback does seem a little ?
> confusing to me in the way that each report type is generated slightly ?
> differently. For example, the HTML and latex types both use the ?
> backend_convert function and then pass the returned arglist through ?
> another function which does the formatting. The XML_NG clause though ?
> uses a specialised backend_to_xml_ng function, and the PDF clause uses ?
> a completely different method all together.
> 
> Perhaps there is a way that we can clean this area of code up to allow ?
> us to easily add new report types down the track ?

we inherited this "programming style & design" from Nessus.
Cleaning up, improving, generalizing are all very welcome
activities :-)

Best

	Jan

-- 
Dr. Jan-Oliver Wagner | ++49-541-335083-0  |  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 stripes at tigerlair.com  Wed Feb 25 01:50:59 2009
From: stripes at tigerlair.com (stripes)
Date: Tue, 24 Feb 2009 19:50:59 -0500
Subject: [Openvas-devel] Any doc work needed?
Message-ID: <20090224195059.A14058@tigerlair.com>

Hi everyone,

I'm willing to lend a hand with the documentation. Is there anything you need help with?

Cheers,

-Anne
--
Gomez: I have seen the unholy     (\`--/') _ _______ .-r-.  
maggots which feast in the dark    >.~.\ `` ` `,`,`. ,'_'~`.
recesses of the human soul!       (v_," ; `,-\ ; : ; \/,-~) \  
Morticia: They're at camp.         `--'_..),-/ ' ' '_.>-' )`.`.__.')
stripes at tigerlair dot com      ((,((,__..'~~~~~~((,__..'  `-..-'fL    

From michael.wiegand at intevation.de  Wed Feb 25 08:52:58 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 25 Feb 2009 08:52:58 +0100
Subject: [Openvas-devel] Any doc work needed?
In-Reply-To: <20090224195059.A14058@tigerlair.com>
References: <20090224195059.A14058@tigerlair.com>
Message-ID: <20090225075258.GB28021@intevation.de>

* stripes [25. Feb 2009]:
> Hi everyone,
> 
> I'm willing to lend a hand with the documentation. Is there anything you need help with?

Thank you very much for your offer! :)

One area where we could definitely use help is the English version of
the compendium. The English version was written by Felix and myself and
even though it seems to get the message across, proofreading by a native
speaker would certainly improve the quality.

Other areas would include updating the section on OpenVAS-Client with
the new features and making sure the client documentation actually makes
sense from an user perspective -- the existing documentation suffers
from our developer POV in some places.

Does that sound like something you would like to do? If you have any
questions or areas where you'd rather work on, feel free to let me know.

Again, thanks a lot for your offer.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090225/9f7a32e6/attachment.pgp

From felix.wolfsteller at intevation.de  Wed Feb 25 09:57:02 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Wed, 25 Feb 2009 09:57:02 +0100
Subject: [Openvas-devel] [RFC PATCH] Allowing filtering of issues during
	report export
In-Reply-To: <200902242010.29019.jan-oliver.wagner@intevation.de>
References: <EEEDA23D-C666-42E8-8AC4-D5F88FE58109@markwallis.id.au>
	<3289CBE5-7B13-4FC4-9C5C-7D266D4D58F5@markwallis.id.au>
	<200902242010.29019.jan-oliver.wagner@intevation.de>
Message-ID: <200902250957.02361.felix.wolfsteller@intevation.de>

> On Dienstag, 24. Februar 2009, Mark Wallis wrote:
> > The switch() in report-save.c:file_save_ok_callback does seem a little ?
> > confusing to me in the way that each report type is generated slightly ?
> > differently. For example, the HTML and latex types both use the ?
> > backend_convert function and then pass the returned arglist through ?
> > another function which does the formatting. The XML_NG clause though ?
> > uses a specialised backend_to_xml_ng function, and the PDF clause uses ?
> > a completely different method all together.
> >
> > Perhaps there is a way that we can clean this area of code up to allow ?
> > us to easily add new report types down the track ?
Definately.

A couple of unordered words from my side:

Besides code and report consistency issues I also find the current export- 
dialog quite unhandy, as it does not memorize the type selection or location 
and will e.g. create "report.pdf.nbe" if you forgot to select pdf as type.

Imho the direction to go is to generate all reports from one 'base' format but 
using syntactical rules only. The wording should be kept exchangable (look 
e.g. at the latex_output's introductions, I see no reason for that being 
hard-wired in the latex_output module).

Apparently quite some users rely on the nbe format so that we cannot drop 
support for it. Otherwise I would go for using xml as standard format.

Your point about 'data' and 'report' is correct, although I think we could 
easily generate fancy reports from xml using xslt (and afaict filter them as 
well!).

Maybe an extended menu (but keeping the old item items) would make sense, too:
* export as
* export -> pdf- report
              -> html-report
              -> ...
              -> nbe-data
              -> xml-data

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 michael.wiegand at intevation.de  Thu Feb 26 07:59:58 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Thu, 26 Feb 2009 07:59:58 +0100
Subject: [Openvas-devel] Any doc work needed?
In-Reply-To: <D3A02341AEE23242A4188BDA5AD854A87105A6@bounty.CASTLEGARDE.COM>
References: <20090224195059.A14058@tigerlair.com>
	<20090225075258.GB28021@intevation.de>
	<D3A02341AEE23242A4188BDA5AD854A87105A6@bounty.CASTLEGARDE.COM>
Message-ID: <20090226065958.GA7863@intevation.de>

* Jon Bebeau [25. Feb 2009]:
> Hi,
> 
> I can help proof the copy too.  I'm a US native and write well (at least IMHO).

Thank you as well for your offer, your help is appreciated! You might
want to coordinate your efforts with Anne so you two don't do the same
work twice.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090226/928b0728/attachment.pgp

From michael.wiegand at intevation.de  Thu Feb 26 08:06:15 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Thu, 26 Feb 2009 08:06:15 +0100
Subject: [Openvas-devel] Any doc work needed?
In-Reply-To: <20090225115604.A12746@tigerlair.com>
References: <20090224195059.A14058@tigerlair.com>
	<20090225075258.GB28021@intevation.de>
	<20090225115604.A12746@tigerlair.com>
Message-ID: <20090226070615.GB7863@intevation.de>

* stripes [25. Feb 2009]:
> On Wed, Feb 25, 2009 at 08:52:58AM +0100, Michael Wiegand wrote:
> > Does that sound like something you would like to do? If you have any
> > questions or areas where you'd rather work on, feel free to let me know.
> 
> Absolutely! Thanks. I have a significant amount of experience with
> Nessus. Since I'm not writing proprietary plugins and I finally have
> the time, I can help with the documents here.

Sounds great! The compendium itself is in (Hyper)LaTeX, you can edit it
directly if you are comfortable with that -- but you can send us your
suggestion in any other way as well, just use what is easiest for 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090226/77cce449/attachment.pgp

From labeneator at gmail.com  Thu Feb 26 09:21:46 2009
From: labeneator at gmail.com (Laban Mwangi)
Date: Thu, 26 Feb 2009 11:21:46 +0300
Subject: [Openvas-devel] [Patch for 828]
Message-ID: <1235636506.3866.9.camel@hyperion.penguinlabs.co.ke>

Hi all,
  Please find a patch for bugid: 828. It essentially stores the client
certifcate hash against a hostname,port pair instead of just the
hostname. This allows one to run multiple OpenVASd instances each with
different certificates.   I didn't want to commit because it will prompt
clients about "new certificates" i.e. the current .openvasrc.cert data
is invalidated. While we are applying this, can we also move .openvasrc
and .openvasrc.cert to .openvas directory?

Regards,
-- 
Laban
-------------- 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/20090226/e3ebffd1/attachment.pgp

From labeneator at gmail.com  Thu Feb 26 09:28:41 2009
From: labeneator at gmail.com (Laban Mwangi)
Date: Thu, 26 Feb 2009 11:28:41 +0300
Subject: [Openvas-devel] [Patch for 828] - Resend
Message-ID: <1235636921.3866.11.camel@hyperion.penguinlabs.co.ke>

Hi all,
  Please find a patch for bugid: 828. It essentially stores the client
certifcate hash against a hostname,port pair instead of just the
hostname. This allows one to run multiple OpenVASd instances each with
different certificates.   I didn't want to commit because it will prompt
clients about "new certificates" i.e. the current .openvasrc.cert data
is invalidated. While we are applying this, can we also move .openvasrc
and .openvasrc.cert to .openvas directory?

Regards,
-- 
Laban
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 828.patch
Type: text/x-patch
Size: 1570 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090226/aaf6ddb2/828.bin
-------------- 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/20090226/aaf6ddb2/attachment.pgp