From michael.wiegand at intevation.de  Wed Nov  5 09:40:39 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 5 Nov 2008 09:40:39 +0100
Subject: [Openvas-devel] Removing getopt Dependency from OpenVAS
Message-ID: <200811050940.39449.michael.wiegand@intevation.de>

Hello,

as a preparation for OpenVAS 2.0, I have begun to eliminate all traces of 
getopt from the OpenVAS source code, starting with the now obsolete local 
copies in openvas-libraries.

As a reminder, command line parsing in -server, -client and the openvas-nasl 
standalone interpreter has been switched to glib as announced in CR #9 and CR 
#11 (see http://www.openvas.org/openvas-cr-9.html and 
http://www.openvas.org/openvas-cr-11.html).

However, I have found two small programs which are still using getopt:
openvas-libraries/libopenvas_hg/test.c and
openvas-server/openvasd/openvas-check-signature.c.

test.c in libopenvas_hg uses the getopt from unistd.h, which should remain 
available. Since it seems to be an example app, I don't have any issues with 
the getopt use there.

openvas-check-signature.c on the other hand uses the getopt_long which used to 
be provided by the local getopt copy in openvas-libraries. Since I am about 
to remove this copy and don't want to add an dependency on an external 
getopt, this would break due to my change.

I don't think openvas-check-signature.c is needed anymore, since signature 
verification can be simply done with "gpg --verify". I'd rather remove it 
than switch it to glib if this the case, but I don't know if any of you is 
still using this file or has plans for it.

So if you want to keep this file around for whatever reason, please let me 
know; otherwise I will remove it with my getopt removal commit.

Regards,

Michael

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

From hanno at hboeck.de  Wed Nov  5 10:42:16 2008
From: hanno at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=)
Date: Wed, 5 Nov 2008 10:42:16 +0100
Subject: [Openvas-devel] Planning openvas-plugins 1.0.4 release
In-Reply-To: <200810281408.45636.michael.wiegand@intevation.de>
References: <200810271204.56684.michael.wiegand@intevation.de>
	<200810281345.51474.hanno@hboeck.de>
	<200810281408.45636.michael.wiegand@intevation.de>
Message-ID: <200811051042.16473.hanno@hboeck.de>

Seems parts of my patch have been included, but not everything (?).

Attached is a patch on 1.0.4.

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

http://x1000malquer.de/ - ab 8.11. Atomtransporte stoppen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-plugins-1.0.4-respect-ldflags.diff
Type: text/x-diff
Size: 7427 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081105/bbbc1637/openvas-plugins-1.0.4-respect-ldflags.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/20081105/bbbc1637/attachment.pgp

From michael.wiegand at intevation.de  Wed Nov  5 10:56:32 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 5 Nov 2008 10:56:32 +0100
Subject: [Openvas-devel] Planning openvas-plugins 1.0.4 release
In-Reply-To: <200811051042.16473.hanno@hboeck.de>
References: <200810271204.56684.michael.wiegand@intevation.de>
	<200810281408.45636.michael.wiegand@intevation.de>
	<200811051042.16473.hanno@hboeck.de>
Message-ID: <200811051056.32809.michael.wiegand@intevation.de>

[Wednesday 05 November 2008 - 10:42:16] Hanno B?ck <hanno at hboeck.de>:
> Seems parts of my patch have been included, but not everything (?).
>
> Attached is a patch on 1.0.4.

Yes, I see what you mean, this seems to have been the case. Sorry for that!

I'm about to commit the remaining changes to the SVN repository, thank you for 
your contribution!

Regards,

Michael

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

From jan-oliver.wagner at intevation.de  Wed Nov  5 14:27:36 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Wed, 5 Nov 2008 14:27:36 +0100
Subject: [Openvas-devel] Removing getopt Dependency from OpenVAS
In-Reply-To: <200811050940.39449.michael.wiegand@intevation.de>
References: <200811050940.39449.michael.wiegand@intevation.de>
Message-ID: <200811051427.37939.jan-oliver.wagner@intevation.de>

Hello Michael,

On Mittwoch, 5. November 2008, Michael Wiegand wrote:
> openvas-check-signature.c on the other hand uses the getopt_long which used to 
> be provided by the local getopt copy in openvas-libraries. Since I am about 
> to remove this copy and don't want to add an dependency on an external 
> getopt, this would break due to my change.
>
> I don't think openvas-check-signature.c is needed anymore, since signature 
> verification can be simply done with "gpg --verify". I'd rather remove it 
> than switch it to glib if this the case, but I don't know if any of you is 
> still using this file or has plans for it.
> 
> So if you want to keep this file around for whatever reason, please let me 
> know; otherwise I will remove it with my getopt removal commit.

I see no reason why we should keep this program. The OpenVAS project does not
apply any x509 signatures. In case we eventually do, we can use gpgsm --verify.

Also note, that removing the .c-file is not sufficient. Changes upto the packaging
files are likley due.

Best

	Jan

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

From felix.wolfsteller at intevation.de  Wed Nov  5 15:27:04 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Wed, 5 Nov 2008 15:27:04 +0100
Subject: [Openvas-devel] Upcoming commits (this week)
Message-ID: <200811051527.04711.felix.wolfsteller@intevation.de>

Hi
Working on CR#17 ( http://www.openvas.org/openvas-cr-17.html - "OTP: Make NVT 
signatures available to OpenVAS-Client" ), I will soon commit some patches. 
As the new code spans over all modules, you will need the latest revisions of 
all modules to have a compilable and (hopefully) stable version of OpenVAS.

Furthermore, the server and client cache files (server: .desc/* in plugin 
folder, client: ~/.openvas* ) should get rebuilt automatically.
If you encounter any trouble with the latest revisions, the first thing to 
check might be to (backup &) delete these files.

This somewhat unsteady state of the repository version will continue until 
completion of CR#17.

Hope it works well though,
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  Fri Nov  7 15:54:59 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Fri, 7 Nov 2008 15:54:59 +0100
Subject: [Openvas-devel] The Road to 2.0.0
Message-ID: <200811071554.59653.michael.wiegand@intevation.de>

Hello,

seeing the progress we have made during the last few weeks, I would like to 
get the ball rolling towards a final release for 2.0.0 and propose a -beta2.

The 2.0-beta2 release should include all features intended for 2.0, so I'd 
like all of you to think about what remains to be done and post it here.

Things I would like to be in 2.0-beta2 include:
- Ensure 64-bit cleanliness:
The patches from Stepjan should get us a big step in this direction. So far, I 
have tested the patch for -client, but have since been busy elsewhere. 
Testers for the remaining patches are more than welcome.

- Get rid of getopt:
As I've said in my mail from 20081105, this is almost done and will be 
committed on Monday if there are no objections.

- Make the client interface more consistent:
Large parts of the compendium already talk about NVTs, while the client 
interface still uses the more generic "plugin" inherited from Nessus. This is 
likely to confuse users, it would be nice to have the client interface 
use "NVT" consistently.

- Improve OVAL support:
I'm currently working on improving the OVAL support for 2.0, like dropping 
privileges when launching ovaldi. This should be done early next week as 
well.

These are the four major issues in my mind; I'm sure you can think of more. :)

Thank you and 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

From jan-oliver.wagner at intevation.de  Sat Nov  8 21:17:57 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Sat, 8 Nov 2008 21:17:57 +0100
Subject: [Openvas-devel] The Road to 2.0.0
In-Reply-To: <200811071554.59653.michael.wiegand@intevation.de>
References: <200811071554.59653.michael.wiegand@intevation.de>
Message-ID: <200811082118.01935.jan-oliver.wagner@intevation.de>

On Friday 07 November 2008 15:54, Michael Wiegand wrote:
> Things I would like to be in 2.0-beta2 include:

what about the feature Felix is working on (CR17)? Should be in beta2 release
if possible.

Anyone something in mind what the final 2.0 release should cover
apart from the current plans?

Best

	Jan

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

From sgros.ml at gmail.com  Sun Nov  9 15:09:35 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Sun, 9 Nov 2008 15:09:35 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<200810152145.12441.timb@nth-dimension.org.uk>
	<4d7b043c0810161004h1e86c9cbr86cd45d8d13ced1c@mail.gmail.com>
	<200810301449.31262.michael.wiegand@intevation.de>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
Message-ID: <4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>

Hi,

I saw this mail just a few days ago but was unable to respond sooner because
I'm busy  lately with my everyday job. Comments are below.

On Thu, Oct 30, 2008 at 2:49 PM, Michael Wiegand <
michael.wiegand at intevation.de> wrote:

> [Thursday 16 October 2008 - 19:04:55] "Stjepan Gros" <sgros.ml at gmail.com>:
> > Ok, I went throught the code and included GLib in those subsystems that
> > didn't use it yet. I then inserted GPOINTER_TO_SIZE instead of (int) and
> > GSIZE_TO_POINTER instead of (void *). Furthermore, every occurence of
> > sizeof(int) I changed into sizeof(gpointer). There were few places where
> > sizeof(variable) was used, but I converted them also to sizeof(gpointer)
> as
> > it's the real size that is handed into the function. Few other omissions
> > were also corrected (but look into patches for them).
>
> Hello Stjepan,
>
> thank you very much for your patch; I'm sorry it took me a few days to get
> a
> good look at it.
>
> I've just finished going through you patch for -client and it looks very
> good
> so far. I would like to commit it to the SVN trunk soon, there are only a
> few
> minor issues:
>
> - I have noticed that you did not only fix the 64bit issue, but other
> issues
> as well. While this is definitely a great thing and more than welcome, it
> would be easier for other developers to understand your changes if you
> could
> split your patch (one patch for 64bit issues, one for others) and describe
> your changes in the appropriate ChangeLog.


I added ChangeLog entry. Also, I removed few non-64bit related changes whose
sole purpose was to get rid of some additional warnings. I'm going to send
those later, when this is applied, because it becomes hard for me to keep
all the changes I've done in sync with newest trunk.

Attached is patch for openvas-client only. If this is OK, then I'll send
patches for other subsystems as well.

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


I totally forgot that it's going to generate warnings on 32-bit platforms.
Unfortunatelly, I don't know openvas so well to know how to definitely
resolve this issue. What I did now is that I added cast to change each
integer either 64-bit or 32-bit to 32-bit value. This is under the
assumption that those values will never be larger.


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


Well, actually I do. What about those patches to move plugins into separate
subdirectory?

Stjepan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081109/5a165d2a/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-client-64bit-v01.patch
Type: text/x-patch
Size: 23100 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081109/5a165d2a/openvas-client-64bit-v01-0001.bin

From jan-oliver.wagner at intevation.de  Mon Nov 10 09:55:43 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 10 Nov 2008 09:55:43 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
Message-ID: <200811100955.44755.jan-oliver.wagner@intevation.de>

On Sonntag, 9. November 2008, Stjepan Gros wrote:
> What about those patches to move plugins into separate
> subdirectory?

unfortunately we can't fork just like openvasd can ;-)

Your patch promises a very, very important feature
and will definitely be reviewed soon.

Best

	Jan

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

From kost at linux.hr  Mon Nov 10 10:00:17 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Mon, 10 Nov 2008 10:00:17 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>	<200810152145.12441.timb@nth-dimension.org.uk>	<4d7b043c0810161004h1e86c9cbr86cd45d8d13ced1c@mail.gmail.com>	<200810301449.31262.michael.wiegand@intevation.de>	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
Message-ID: <4917F821.4030600@linux.hr>

> Well, actually I do. What about those patches to move plugins into
> separate subdirectory?

Didn't take a deeper look at the patch. I'm concerned about issue I see;
I'm not sure how include files will be handled?

Kost

From sgros.ml at gmail.com  Mon Nov 10 11:38:48 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Mon, 10 Nov 2008 11:38:48 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4917F821.4030600@linux.hr>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<200810152145.12441.timb@nth-dimension.org.uk>
	<4d7b043c0810161004h1e86c9cbr86cd45d8d13ced1c@mail.gmail.com>
	<200810301449.31262.michael.wiegand@intevation.de>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
	<4917F821.4030600@linux.hr>
Message-ID: <4d7b043c0811100238pa220aafj93cef8823f452627@mail.gmail.com>

On Mon, Nov 10, 2008 at 10:00 AM, Vlatko Kosturjak <kost at linux.hr> wrote:
>> Well, actually I do. What about those patches to move plugins into
>> separate subdirectory?
>
> Didn't take a deeper look at the patch. I'm concerned about issue I see;
> I'm not sure how include files will be handled?

Can you elaborate a bit more?

Anyway, it seems that latest changes in trunk cause conflicts with the
patch I sent so I'll have to do that again. But this time I'll wait
until trunk is open for new changes.

S

From kost at linux.hr  Mon Nov 10 11:42:09 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Mon, 10 Nov 2008 11:42:09 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0811100238pa220aafj93cef8823f452627@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>	
	<200810152145.12441.timb@nth-dimension.org.uk>	
	<4d7b043c0810161004h1e86c9cbr86cd45d8d13ced1c@mail.gmail.com>	
	<200810301449.31262.michael.wiegand@intevation.de>	
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>	
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>	
	<4917F821.4030600@linux.hr>
	<4d7b043c0811100238pa220aafj93cef8823f452627@mail.gmail.com>
Message-ID: <49181001.9080505@linux.hr>

Stjepan Gros wrote:
> On Mon, Nov 10, 2008 at 10:00 AM, Vlatko Kosturjak <kost at linux.hr> wrote:
>>> Well, actually I do. What about those patches to move plugins into
>>> separate subdirectory?
>> Didn't take a deeper look at the patch. I'm concerned about issue I see;
>> I'm not sure how include files will be handled?
> Can you elaborate a bit more?
> Anyway, it seems that latest changes in trunk cause conflicts with the
> patch I sent so I'll have to do that again. But this time I'll wait
> until trunk is open for new changes.

http_trace.nasl check, for example, includes the following inc file
through following directive:
include("http_func.inc");

Kost

BTW Pozdravi Zagara :o)

From michael.wiegand at intevation.de  Mon Nov 10 11:53:16 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Mon, 10 Nov 2008 11:53:16 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
Message-ID: <200811101153.17094.michael.wiegand@intevation.de>

[Sunday 09 November 2008 - 15:09:35] "Stjepan Gros" <sgros.ml at gmail.com>:
> I added ChangeLog entry. Also, I removed few non-64bit related changes
> whose sole purpose was to get rid of some additional warnings. I'm going to
> send those later, when this is applied, because it becomes hard for me to
> keep all the changes I've done in sync with newest trunk.
>
> Attached is patch for openvas-client only. If this is OK, then I'll send
> patches for other subsystems as well.

The patch looks good to me, I'm about to run a few tests with it and intend to 
commit it to trunk later today.

Once this is done, I'm ready to take a look at your other patches, so please 
do send them once they are ready. Thank you!

> I totally forgot that it's going to generate warnings on 32-bit platforms.
> Unfortunatelly, I don't know openvas so well to know how to definitely
> resolve this issue. What I did now is that I added cast to change each
> integer either 64-bit or 32-bit to 32-bit value. This is under the
> assumption that those values will never be larger.

I just compiled it on a 32-bit system, looks good so far, no more warning 
regarding this. I think we can live with that.

Regards,

Michael


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

From sgros.ml at gmail.com  Mon Nov 10 12:08:50 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Mon, 10 Nov 2008 12:08:50 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <49181001.9080505@linux.hr>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<200810152145.12441.timb@nth-dimension.org.uk>
	<4d7b043c0810161004h1e86c9cbr86cd45d8d13ced1c@mail.gmail.com>
	<200810301449.31262.michael.wiegand@intevation.de>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
	<4917F821.4030600@linux.hr>
	<4d7b043c0811100238pa220aafj93cef8823f452627@mail.gmail.com>
	<49181001.9080505@linux.hr>
Message-ID: <4d7b043c0811100308i695b8f6ald6ccecf4bb6914c6@mail.gmail.com>

On Mon, Nov 10, 2008 at 11:42 AM, Vlatko Kosturjak <kost at linux.hr> wrote:
> Stjepan Gros wrote:
>> On Mon, Nov 10, 2008 at 10:00 AM, Vlatko Kosturjak <kost at linux.hr> wrote:
>>>> Well, actually I do. What about those patches to move plugins into
>>>> separate subdirectory?
>>> Didn't take a deeper look at the patch. I'm concerned about issue I see;
>>> I'm not sure how include files will be handled?
>> Can you elaborate a bit more?
>> Anyway, it seems that latest changes in trunk cause conflicts with the
>> patch I sent so I'll have to do that again. But this time I'll wait
>> until trunk is open for new changes.
>
> http_trace.nasl check, for example, includes the following inc file
> through following directive:
> include("http_func.inc");

This is already handled in the patch. Two include paths are implicitly
defined for each nasl script that is opened:

1. the directory where nasl file itself is placed

2. the main directory from which recursive descent started

Added to that are all include directories specified in configuration
file, if any.

I think that in that way there will be no problems with existing scripts/setups.

Stjepan

From michael.wiegand at intevation.de  Mon Nov 10 12:58:53 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Mon, 10 Nov 2008 12:58:53 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
Message-ID: <200811101258.53840.michael.wiegand@intevation.de>

[Sunday 09 November 2008 - 15:09:35] "Stjepan Gros" <sgros.ml at gmail.com>:
> Attached is patch for openvas-client only. If this is OK, then I'll send
> patches for other subsystems as well.

FYI: I have just committed your patch to the SVN repository with revision 
1688. Thanks!

Regards,

Michael

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

From sgros.ml at gmail.com  Tue Nov 11 10:16:12 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Tue, 11 Nov 2008 10:16:12 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <200811101258.53840.michael.wiegand@intevation.de>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
	<200811101258.53840.michael.wiegand@intevation.de>
Message-ID: <4d7b043c0811110116w29b40fb6v2847d714a649b730@mail.gmail.com>

Ok, attached are the remaining patches to remove warnings caused by
32/64 bit conversions. I removed all the other changes which I'm going
to send later and I'm not going to split it across subsystems because
it causes me more work to have. Hope it's not the problem.

Stjepan

On Mon, Nov 10, 2008 at 12:58 PM, Michael Wiegand
<michael.wiegand at intevation.de> wrote:
> [Sunday 09 November 2008 - 15:09:35] "Stjepan Gros" <sgros.ml at gmail.com>:
>> Attached is patch for openvas-client only. If this is OK, then I'll send
>> patches for other subsystems as well.
>
> FYI: I have just committed your patch to the SVN repository with revision
> 1688. Thanks!
>
> 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: openvas-libnasl-64bit-v01.patch
Type: text/x-patch
Size: 6362 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081111/d91f4668/openvas-libnasl-64bit-v01-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-libraries-64bit-v01.patch
Type: text/x-patch
Size: 19052 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081111/d91f4668/openvas-libraries-64bit-v01-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-plugins-64bit-v01.patch
Type: text/x-patch
Size: 13480 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081111/d91f4668/openvas-plugins-64bit-v01-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-server-64bit-v01.patch
Type: text/x-patch
Size: 18099 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081111/d91f4668/openvas-server-64bit-v01-0001.bin

From jan-oliver.wagner at intevation.de  Tue Nov 11 21:44:49 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Tue, 11 Nov 2008 21:44:49 +0100
Subject: [Openvas-devel] openvas-compendium-1.0.0.rc1 french translation
In-Reply-To: <200810290534.11512.marco.fradin@free.fr>
References: <200810290534.11512.marco.fradin@free.fr>
Message-ID: <200811112144.49149.jan-oliver.wagner@intevation.de>

Hello Marco,

Am Wednesday 29 October 2008 05:34:11 schrieb marco:
> For information, french translation is about 20.2%. Looks fine.
> I hope nobody else is working on it.  Tell me in case someone has done the
> job ;-)

sounds very good! I am not aware of anyone else working
on this.

Please note there was a rc2 release in the mean time.

Best

	Jan



From michael.wiegand at intevation.de  Wed Nov 12 13:08:55 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 12 Nov 2008 13:08:55 +0100
Subject: [Openvas-devel] AC_PREREQ directive
In-Reply-To: <20081112113215.9A6C740711@pyrosoma.intevation.org>
References: <20081112113215.9A6C740711@pyrosoma.intevation.org>
Message-ID: <20081112120855.GA16244@intevation.de>

Hello,

as you have probably noticed, I have just added an AC_PREREQ directive
to all configure.in scripts.

The reason behind this is that the "autoconf" command does not always
call autoconf directly, but (for example in Debian) rather calls a
wrapper which then decides whether autoconf 2.13 or 2.50(or newer)
should be called.

At least in Debian, this wrapped decided that 2.13 would be appropriate,
which had the effect that different components were using different
autoconf versions, depending on who had last generated the configure
file. This caused issues with some autoconf defaults that had changed
between the versions and caused unnecessary large svn diffs.

The AC_PREREQ directive should now cause the correct autoconf version to be
used under all circumstances; please let me know if you observe any side effects.

Ultimately, it would probably make sense to remove the "configure" files
from the SVN and create them at build-time, wouldn't it?

Regards,

Michael

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

From sgros.ml at gmail.com  Wed Nov 12 14:28:10 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Wed, 12 Nov 2008 14:28:10 +0100
Subject: [Openvas-devel] AC_PREREQ directive
In-Reply-To: <20081112120855.GA16244@intevation.de>
References: <20081112113215.9A6C740711@pyrosoma.intevation.org>
	<20081112120855.GA16244@intevation.de>
Message-ID: <4d7b043c0811120528p138244dlcf683255afc1ca1b@mail.gmail.com>

On Wed, Nov 12, 2008 at 1:08 PM, Michael Wiegand
<michael.wiegand at intevation.de> wrote:

> Ultimately, it would probably make sense to remove the "configure" files
> from the SVN and create them at build-time, wouldn't it?

I think automatically build files are rearly included into subversion.
There is no need to track their changes. Also, many projects include a
script into source, usually called autogen.sh, that generates build
files for sources pulled from subversion/cvs.

My $.02..

Stjepan

From michael.wiegand at intevation.de  Wed Nov 12 15:55:51 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 12 Nov 2008 15:55:51 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0811110116w29b40fb6v2847d714a649b730@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
	<200811101258.53840.michael.wiegand@intevation.de>
	<4d7b043c0811110116w29b40fb6v2847d714a649b730@mail.gmail.com>
Message-ID: <20081112145551.GC16244@intevation.de>

* Stjepan Gros [11. Nov 2008]:
> Ok, attached are the remaining patches to remove warnings caused by
> 32/64 bit conversions. I removed all the other changes which I'm going
> to send later and I'm not going to split it across subsystems because
> it causes me more work to have. Hope it's not the problem.

I've just finished testing and committing your patches, great work!

I'm looking forward to your other patches; usually patches should be
limited to one subsystem at a time. But if you have already prepared
your patch, please do send it, I'll split it up when I commit.

If you want to do your own commits in the future, please consider
creating an account on http://wald.intevation.org and join the OpenVAS
project. You should get SVN write access pretty quickly.

Regards,

Michael

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

From michael.wiegand at intevation.de  Thu Nov 13 14:09:15 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Thu, 13 Nov 2008 14:09:15 +0100
Subject: [Openvas-devel] Planning 2.0-beta2 release
Message-ID: <20081113130914.GD14078@intevation.de>

Hello,

as a follow-up to my mail regarding the road to 2.0, I would like to
start planning for the 2.0-beta2 release of openvas-libraries,
openvas-libnasl, openvas-server and openvas-client.

We are almost done with the proposed changes for 2.0; especially over
the last few days, we were able to eliminate quite a number of bugs. I
think it is time we get -beta2 out and give it a last round of testing
before we finally release 2.0.

As I mentioned before, 2.0-beta2 is intended to be feature-complete,
meaning all features intended for 2.0 are supposed to be in the code
of -beta2 to allow enough time for testing before we relase the final
version.

If there is anything you would like to add before -beta2 is released or
if you have other objections to this release schedule, please let me
know as soon as possible.

If there are no more obstacles, I would like to do the release in the
next few days, possibly as early as Friday.

Regards,

  Michael

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

From sgros.ml at gmail.com  Fri Nov 14 08:36:32 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Fri, 14 Nov 2008 08:36:32 +0100
Subject: [Openvas-devel] Fwd:  64 bit cleanless
In-Reply-To: <4d7b043c0811121327r60fa3a86o23b50f2870651e7a@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
	<200811101258.53840.michael.wiegand@intevation.de>
	<4d7b043c0811110116w29b40fb6v2847d714a649b730@mail.gmail.com>
	<20081112145551.GC16244@intevation.de>
	<4d7b043c0811121327r60fa3a86o23b50f2870651e7a@mail.gmail.com>
Message-ID: <4d7b043c0811132336m74d08392n63cd8a49259774ec@mail.gmail.com>

Two days ago I sent this mail but it was (still is?) held for
moderator aprovall because of the size. I'm resending it again, but
this time in two parts.

Is it possible to raise a limit on mail message size?

Stjepan


---------- Forwarded message ----------
From: Stjepan Gros <sgros.ml at gmail.com>
Date: Wed, Nov 12, 2008 at 10:27 PM
Subject: Re: [Openvas-devel] 64 bit cleanless
To: openvas-devel at wald.intevation.org


On Wed, Nov 12, 2008 at 3:55 PM, Michael Wiegand
<michael.wiegand at intevation.de> wrote:

> I'm looking forward to your other patches; usually patches should be
> limited to one subsystem at a time. But if you have already prepared
> your patch, please do send it, I'll split it up when I commit.

Attached is a last set of patches. Some of them purely cosmetic, but
majority to remove compiler warnings. Also, I removed --enable-install
option in plugins because I don't see a reason to require root
privileges to install plugins. This requires configure to be
regenerated (which is not included in the patch).

> If you want to do your own commits in the future, please consider
> creating an account on http://wald.intevation.org and join the OpenVAS
> project. You should get SVN write access pretty quickly.

I already created, my username is sgros

And two questions:

1. when patches for plugin directory change will be acceptable?

2. (almost) the same files are in openvas-client/libnessus and
openvas-libraries/libopenvas. could it be possible to remove the
duplicates in openvas-client and then require openvas-libraries to be
installed before openvas-client can be installed?

Stjepan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-client-misc-v00.patch
Type: text/x-patch
Size: 3143 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081114/f342f2d2/openvas-client-misc-v00.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-libraries-misc-v00.patch
Type: text/x-patch
Size: 1518 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081114/f342f2d2/openvas-libraries-misc-v00.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-plugins-misc-v00.patch
Type: text/x-patch
Size: 2403 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081114/f342f2d2/openvas-plugins-misc-v00.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-server-misc-v00.patch
Type: text/x-patch
Size: 5503 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081114/f342f2d2/openvas-server-misc-v00.bin

From sgros.ml at gmail.com  Fri Nov 14 08:40:16 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Fri, 14 Nov 2008 08:40:16 +0100
Subject: [Openvas-devel] 64 bit cleanless
In-Reply-To: <4d7b043c0811132336m74d08392n63cd8a49259774ec@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
	<200811101258.53840.michael.wiegand@intevation.de>
	<4d7b043c0811110116w29b40fb6v2847d714a649b730@mail.gmail.com>
	<20081112145551.GC16244@intevation.de>
	<4d7b043c0811121327r60fa3a86o23b50f2870651e7a@mail.gmail.com>
	<4d7b043c0811132336m74d08392n63cd8a49259774ec@mail.gmail.com>
Message-ID: <4d7b043c0811132340y48126894mb4c806d71349c193@mail.gmail.com>

No lack... the second part is larger than 40kB and is also held for an
approval...

Stjepan

On Fri, Nov 14, 2008 at 8:36 AM, Stjepan Gros <sgros.ml at gmail.com> wrote:
> Two days ago I sent this mail but it was (still is?) held for
> moderator aprovall because of the size. I'm resending it again, but
> this time in two parts.
>
> Is it possible to raise a limit on mail message size?
>
> Stjepan
>
>
> ---------- Forwarded message ----------
> From: Stjepan Gros <sgros.ml at gmail.com>
> Date: Wed, Nov 12, 2008 at 10:27 PM
> Subject: Re: [Openvas-devel] 64 bit cleanless
> To: openvas-devel at wald.intevation.org
>
>
> On Wed, Nov 12, 2008 at 3:55 PM, Michael Wiegand
> <michael.wiegand at intevation.de> wrote:
>
>> I'm looking forward to your other patches; usually patches should be
>> limited to one subsystem at a time. But if you have already prepared
>> your patch, please do send it, I'll split it up when I commit.
>
> Attached is a last set of patches. Some of them purely cosmetic, but
> majority to remove compiler warnings. Also, I removed --enable-install
> option in plugins because I don't see a reason to require root
> privileges to install plugins. This requires configure to be
> regenerated (which is not included in the patch).
>
>> If you want to do your own commits in the future, please consider
>> creating an account on http://wald.intevation.org and join the OpenVAS
>> project. You should get SVN write access pretty quickly.
>
> I already created, my username is sgros
>
> And two questions:
>
> 1. when patches for plugin directory change will be acceptable?
>
> 2. (almost) the same files are in openvas-client/libnessus and
> openvas-libraries/libopenvas. could it be possible to remove the
> duplicates in openvas-client and then require openvas-libraries to be
> installed before openvas-client can be installed?
>
> Stjepan
>

From michael.wiegand at intevation.de  Fri Nov 14 09:00:40 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Fri, 14 Nov 2008 09:00:40 +0100
Subject: [Openvas-devel] Fwd:  64 bit cleanless
In-Reply-To: <4d7b043c0811132336m74d08392n63cd8a49259774ec@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811090558g2dd97e1m62a81d1643533511@mail.gmail.com>
	<4d7b043c0811090609u4d72eec9r1b187b003c52650@mail.gmail.com>
	<200811101258.53840.michael.wiegand@intevation.de>
	<4d7b043c0811110116w29b40fb6v2847d714a649b730@mail.gmail.com>
	<20081112145551.GC16244@intevation.de>
	<4d7b043c0811121327r60fa3a86o23b50f2870651e7a@mail.gmail.com>
	<4d7b043c0811132336m74d08392n63cd8a49259774ec@mail.gmail.com>
Message-ID: <20081114080040.GA1847@intevation.de>

* Stjepan Gros [14. Nov 2008]:
> Two days ago I sent this mail but it was (still is?) held for
> moderator aprovall because of the size. I'm resending it again, but
> this time in two parts.

Oh, sorry for that. Jan-Oliver runs the openvas-devel list, but he was
out of town the last two days. I'm sure he will approve it today.
 
> Is it possible to raise a limit on mail message size?

This is a very good idea. Jan-Oliver, what do you think?

> Attached is a last set of patches. Some of them purely cosmetic, but
> majority to remove compiler warnings. Also, I removed --enable-install
> option in plugins because I don't see a reason to require root
> privileges to install plugins. This requires configure to be
> regenerated (which is not included in the patch).

Thank you. I will test the patches as soon as they get through to me.

> 1. when patches for plugin directory change will be acceptable?

I hadn't had time to look at those patches yet, but I think they are a
very important feature which would be very useful to OpenVAS. I've been
busy with the -beta2 release this week but I hope I will have time for
your patches once the release is out.

> 2. (almost) the same files are in openvas-client/libnessus and
> openvas-libraries/libopenvas. could it be possible to remove the
> duplicates in openvas-client and then require openvas-libraries to be
> installed before openvas-client can be installed?

The reason for this right now is simply that it enables less-experienced
user to just download one package, compile it and be ready to go without
worrying about dependencies to other parts of the code -- since client
and server are not always installed on the same machine.

In the long run your idea certainly makes sense, keeping different
versions of the same code around is something we definitely want to
avoid. But right now we are in the process of cleaning up -client as
well as -libraries, so I would tend to wait with this until this is done
before we merge 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

From jan-oliver.wagner at intevation.de  Fri Nov 14 11:26:50 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 14 Nov 2008 11:26:50 +0100
Subject: [Openvas-devel] Fwd:  64 bit cleanless
In-Reply-To: <20081114080040.GA1847@intevation.de>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811132336m74d08392n63cd8a49259774ec@mail.gmail.com>
	<20081114080040.GA1847@intevation.de>
Message-ID: <200811141126.52892.jan-oliver.wagner@intevation.de>

On Freitag, 14. November 2008, Michael Wiegand wrote:
> The reason for this right now is simply that it enables less-experienced
> user to just download one package, compile it and be ready to go without
> worrying about dependencies to other parts of the code -- since client
> and server are not always installed on the same machine.

another reason is that openvas-libraries as it is present has high
demands regarding dependent libraries (various networking stuff,
the openvas-client does not need at all).
So, a first step would be break up openvas-libaries into more libraries
(internally) and have a flexibl?e autoconf that builds only the simple
ones if the network libraries are missing on the build system.

However, it might be a good idea to wait for this until
these strange data structure (arglists, hargslists) are replaced
by standard ones (from glib) which I guess will even provide better
performance.

Best

	Jan

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

From openvas-bugs at wald.intevation.org  Wed Nov 12 14:14:22 2008
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Wed, 12 Nov 2008 14:14:22 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B825=5D_OpenVAS_SVN?=
	=?utf-8?q?_latest_=28_r1701=29_version_crashes_on_BackTrack3?=
Message-ID: <20081112131422.24F4840727@pyrosoma.intevation.org>

Bugs item #825, was opened at 2008-11-12 14:14
Status: Open
Priority: 3
Submitted By: Vlatko Kosturjak (kost)
Assigned to: Nobody (None)
Summary: OpenVAS SVN latest ( r1701) version crashes on BackTrack3 
Resolution: None
Severity: blocker
Version: None
Component: openvas-server
Operating System: Linux
Product: OpenVAS
Hardware: None
URL: http://www.remote-exploit.orig


Initial Comment:
note that OpenVAS (2.0beta1) does not crash on Backtrack3, while openvas svn version crashes. 

Here's the useful debugging info:

bt ~ # gdb openvasd
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /usr/local/bin/openvasd
Loading the OpenVAS plugins...[5893]() gpgme_engine_check_version failed: GPGME/Invalid crypto engine

Program received signal SIGSEGV, Segmentation fault.
0xb7f6d316 in gpgme_release () from /usr/lib/libgpgme.so.11
(gdb) bt
#0  0xb7f6d316 in gpgme_release () from /usr/lib/libgpgme.so.11
#1  0xb7fa25b9 in init_openvas_gpgme_ctx () at nasl_signature.c:140
#2  0xb7fa2671 in nasl_extract_signature_fprs (
    filename=0xbfe4ffe3 "/opt/openvas-svn-r1701/lib/openvas/plugins/TelSrv_DoS.nasl")
    at nasl_signature.c:251
#3  0x08055f71 in nasl_plugin_add ()
#4  0x08055bf3 in plugins_reload_from_dir ()
#5  0x08055ca8 in plugins_reload ()
#6  0x08055932 in plugins_init ()
#7  0x080596ff in init_openvasd ()
#8  0x08059d83 in main ()
(gdb) i r
eax            0x0      0
ecx            0xffffffff       -1
edx            0xb7d780bc       -1210613572
ebx            0xb7f78478       -1208515464
esp            0xbfe4ef40       0xbfe4ef40
ebp            0xbfe4ef58       0xbfe4ef58
esi            0x0      0
edi            0x8062fea        134623210
eip            0xb7f6d316       0xb7f6d316 <gpgme_release+22>
eflags         0x210286 [ PF SF IF RF ID ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb)



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

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

From openvas-bugs at wald.intevation.org  Wed Nov 12 15:12:33 2008
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Wed, 12 Nov 2008 15:12:33 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B826=5D_Closing_SSL?=
	=?utf-8?q?_Certificate_Window_let_the_client_hang?=
Message-ID: <20081112141233.1E68D40719@pyrosoma.intevation.org>

Bugs item #826, was opened at 2008-11-12 14:12
Status: Open
Priority: 3
Submitted By: Felix Wolfsteller (felix)
Assigned to: Nobody (None)
Summary: Closing SSL Certificate Window let the client hang 
Resolution: None
Severity: normal
Version: None
Component: openvas-client
Operating System: Linux
Product: OpenVAS
Hardware: None
URL: 


Initial Comment:
When starting a fresh client, one is asked to accept the SSL Certificate.
The Certificate is shown in a fancy window ( nessus/sslui.c ) that can be closed.
Either a window closing operation should be prohibited or interpreted as a "No".

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

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

From sgros.ml at gmail.com  Fri Nov 14 08:38:35 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Fri, 14 Nov 2008 08:38:35 +0100
Subject: [Openvas-devel] Fwd:  64 bit cleanless - 2nd part...
Message-ID: <4d7b043c0811132338g78c1c752o28c365f26677c46d@mail.gmail.com>

and the second part...

Stjepan


---------- Forwarded message ----------
From: Stjepan Gros <sgros.ml at gmail.com>
Date: Wed, Nov 12, 2008 at 10:27 PM
Subject: Re: [Openvas-devel] 64 bit cleanless
To: openvas-devel at wald.intevation.org


On Wed, Nov 12, 2008 at 3:55 PM, Michael Wiegand
<michael.wiegand at intevation.de> wrote:

> I'm looking forward to your other patches; usually patches should be
> limited to one subsystem at a time. But if you have already prepared
> your patch, please do send it, I'll split it up when I commit.

Attached is a last set of patches. Some of them purely cosmetic, but
majority to remove compiler warnings. Also, I removed --enable-install
option in plugins because I don't see a reason to require root
privileges to install plugins. This requires configure to be
regenerated (which is not included in the patch).

> If you want to do your own commits in the future, please consider
> creating an account on http://wald.intevation.org and join the OpenVAS
> project. You should get SVN write access pretty quickly.

I already created, my username is sgros

And two questions:

1. when patches for plugin directory change will be acceptable?

2. (almost) the same files are in openvas-client/libnessus and
openvas-libraries/libopenvas. could it be possible to remove the
duplicates in openvas-client and then require openvas-libraries to be
installed before openvas-client can be installed?

Stjepan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-libnasl-misc-v00.patch
Type: text/x-patch
Size: 35041 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081114/b3d13c72/openvas-libnasl-misc-v00-0001.bin

From sgros.ml at gmail.com  Fri Nov 14 12:50:55 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Fri, 14 Nov 2008 12:50:55 +0100
Subject: [Openvas-devel] Fwd: 64 bit cleanless
In-Reply-To: <200811141126.52892.jan-oliver.wagner@intevation.de>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<4d7b043c0811132336m74d08392n63cd8a49259774ec@mail.gmail.com>
	<20081114080040.GA1847@intevation.de>
	<200811141126.52892.jan-oliver.wagner@intevation.de>
Message-ID: <4d7b043c0811140350q23dca959mf298955cf3a2a103@mail.gmail.com>

On Fri, Nov 14, 2008 at 11:26 AM, Jan-Oliver Wagner
<jan-oliver.wagner at intevation.de> wrote:

> However, it might be a good idea to wait for this until
> these strange data structure (arglists, hargslists) are replaced
> by standard ones (from glib) which I guess will even provide better
> performance.

Yes, this is a good idea. Is anybody working on this?

Stjepan

From kost at linux.hr  Fri Nov 14 13:47:45 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Fri, 14 Nov 2008 13:47:45 +0100
Subject: [Openvas-devel] OpenVAS and backtrack
Message-ID: <491D7371.1030400@linux.hr>

As OpenVAS is not in Backtrack 3 by default (yet!). You can download lzm
module or download remastered backtrack3 which includes OpenVAS lzm (it
still fits on 700 Mb CD).

It's good way of testing OpenVAS in case you want to try it out. And
also if you want to write (and test) NASL checks, but you don't have
development enviroment ready.

Read more and download here:
http://www.openvas.org/openvas-bt.html

Hope it helps!

Kost

PS Christian Eric - this is for you ;)

From jan-oliver.wagner at intevation.de  Fri Nov 14 15:28:53 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 14 Nov 2008 15:28:53 +0100
Subject: [Openvas-devel] Fwd: 64 bit cleanless
In-Reply-To: <4d7b043c0811140350q23dca959mf298955cf3a2a103@mail.gmail.com>
References: <4d7b043c0810150324p625aac4fm16c017dfc457ae90@mail.gmail.com>
	<200811141126.52892.jan-oliver.wagner@intevation.de>
	<4d7b043c0811140350q23dca959mf298955cf3a2a103@mail.gmail.com>
Message-ID: <200811141528.55154.jan-oliver.wagner@intevation.de>

On Freitag, 14. November 2008, Stjepan Gros wrote:
> On Fri, Nov 14, 2008 at 11:26 AM, Jan-Oliver Wagner
> > However, it might be a good idea to wait for this until
> > these strange data structure (arglists, hargslists) are replaced
> > by standard ones (from glib) which I guess will even provide better
> > performance.
> 
> Yes, this is a good idea. Is anybody working on this?

I am not aware of anyone approaching this.
It is not a too simple task.

My idea was that we should start with a
struct NVT_Desc {} in OpenVAS-Client and step-by-step
change to this strucure (which members are some Glib Datacontainers)
all over the client. Probably some lessons need to be learned.
Once finished this, the gained experience should be good
enough to approach the server.

In the meantime we'll try to make the server as light as possible
to increase readability of this code ;-)

Best

	Jan


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

From mike at oshean.org  Fri Nov 14 16:31:07 2008
From: mike at oshean.org (Mike Marseglia)
Date: Fri, 14 Nov 2008 10:31:07 -0500
Subject: [Openvas-devel] OpenVAS 2.0 Windows Client
Message-ID: <1dfae14e0811140731oc04133bm974a18a47a1245f1@mail.gmail.com>

Does anyone have a win32 build of the OpenVas 2.0 Windows Client they
could share?

Thank you,

-- 
Mike Marseglia
Systems Administrator, OSHEAN
401-886-0887 x208
401-248-4867
mike at oshean.org

From jan-oliver.wagner at intevation.de  Fri Nov 14 19:56:59 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 14 Nov 2008 19:56:59 +0100
Subject: [Openvas-devel] OpenVAS 2.0 Windows Client
In-Reply-To: <1dfae14e0811140731oc04133bm974a18a47a1245f1@mail.gmail.com>
References: <1dfae14e0811140731oc04133bm974a18a47a1245f1@mail.gmail.com>
Message-ID: <200811141957.00035.jan-oliver.wagner@intevation.de>

Am Friday 14 November 2008 16:31:07 schrieb Mike Marseglia:
> Does anyone have a win32 build of the OpenVas 2.0 Windows Client they
> could share?

currently it is a bit hairy to build the Windows Client (though it is
documented).
It is simply lack of time over here that we do not prepare
the Windows binaries for each realease.

I'd welcome anyone who is familar with the mingw cross compilation
environment to work on a method to build the Windows client on Linux.
Then we could always automatically create the new Windows client with a new 
release.
This method is e.g. applied by the Gpg4win project (www.gpg4win.org).

Best

	Jan


From michael.wiegand at intevation.de  Mon Nov 17 15:12:50 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Mon, 17 Nov 2008 15:12:50 +0100
Subject: [Openvas-devel] Solaris Local Security Checks
In-Reply-To: <200810312236.55376.timb@nth-dimension.org.uk>
References: <200810312236.55376.timb@nth-dimension.org.uk>
Message-ID: <20081117141250.GF21680@intevation.de>

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

Good news everyone,

I found the bug in gather-package-list.nasl and was able to retrieve a
package list from a Solaris box. The checks seem to have been executed as
well, but they don't seem to return a message just yet if I'm not
mistaken.

I've attached a KB of the test run in case anyone is interested.

The cause of the bug was the SuSE detection in gather-package-list.nasl;
it evaluated

("SUSE"><toupper(ssh_cmd(socket:sock, cmd:"cat /etc/SuSE-release"))) 

which is always true on most platforms (hint: Try 'cat
/etc/SuSE-release' on a non-SuSE system, uppercase the output of cat and
compare it to "SUSE"). I have commented out the SuSE test for now, it
would be great if someone with access to a SuSE system could write a
more reliable test.
 
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: solaris-kb.txt.bz2
Type: application/octet-stream
Size: 30076 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081117/bc3b6d74/solaris-kb.txt-0001.obj

From lists at securityspace.com  Mon Nov 17 18:46:08 2008
From: lists at securityspace.com (Thomas Reinke)
Date: Mon, 17 Nov 2008 12:46:08 -0500
Subject: [Openvas-devel] Solaris Local Security Checks
In-Reply-To: <20081117141250.GF21680@intevation.de>
References: <200810312236.55376.timb@nth-dimension.org.uk>
	<20081117141250.GF21680@intevation.de>
Message-ID: <4921ADE0.8030407@securityspace.com>

Michael Wiegand wrote:

 > compare it to "SUSE"). I have commented out the SuSE test for now, it
 > would be great if someone with access to a SuSE system could write a
 > more reliable test.
 >

SuSE has now been re-enabled in gather-package-list.nasl with
updated detection logic properly working.

Thomas


From timb at nth-dimension.org.uk  Mon Nov 17 23:21:53 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Mon, 17 Nov 2008 22:21:53 +0000
Subject: [Openvas-devel] Solaris Local Security Checks
In-Reply-To: <4921ADE0.8030407@securityspace.com>
References: <200810312236.55376.timb@nth-dimension.org.uk>
	<20081117141250.GF21680@intevation.de>
	<4921ADE0.8030407@securityspace.com>
Message-ID: <200811172221.54094.timb@nth-dimension.org.uk>

On Monday 17 November 2008 17:46:08 Thomas Reinke wrote:
> Michael Wiegand wrote:
>  > compare it to "SUSE"). I have commented out the SuSE test for now, it
>  > would be great if someone with access to a SuSE system could write a
>  > more reliable test.
>
> SuSE has now been re-enabled in gather-package-list.nasl with
> updated detection logic properly working.

Cheers Michael and Thomas, but actually that's not the problem :(.  I'd 
actually fixed the SuSE bug in my branch as follows:

< rls = toupper(ssh_cmd(socket:sock, cmd:"cat /etc/SuSE-release"));
< if("SUSE"><rls) {
<     ver = eregmatch(pattern:"VERSION = ([0-9\.]+)", string:rls);
<     if( isnull(ver) ) ver[1] = " ";
<     set_kb_item(name: "ssh/login/release", value: "SUSE"+ver[1]);
<     buf = ssh_cmd(socket:sock, 
cmd:"/bin/rpm -qa --qf '%{NAME}~%{VERSION}~%{RELEASE};\n'");

Obviously your check is an improvement on that ;).  I may have the chance to 
run my scripts on a real world box this week, so I'll see if I can nail down 
where my problem lies.

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

From michael.wiegand at intevation.de  Tue Nov 18 08:00:56 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Tue, 18 Nov 2008 08:00:56 +0100
Subject: [Openvas-devel] [Openvas-plugins] Solaris Local Security	Checks
In-Reply-To: <200811172221.54094.timb@nth-dimension.org.uk>
References: <200810312236.55376.timb@nth-dimension.org.uk>
	<20081117141250.GF21680@intevation.de>
	<4921ADE0.8030407@securityspace.com>
	<200811172221.54094.timb@nth-dimension.org.uk>
Message-ID: <20081118070056.GB15568@intevation.de>

* Tim Brown [17. Nov 2008]:
> Cheers Michael and Thomas, but actually that's not the problem :(. 
> 
> Obviously your check is an improvement on that ;).  I may have the chance to 
> run my scripts on a real world box this week, so I'll see if I can nail down 
> where my problem lies.

That would have probably been too easy. :) Do you have any other hints
as to what the problem might be? What goes wrong? I have access to a
Solaris Box as well, so if there is anything you want me to test, just
let me know.

Regards,

Michael


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


From timb at nth-dimension.org.uk  Wed Nov 19 01:09:03 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Wed, 19 Nov 2008 00:09:03 +0000
Subject: [Openvas-devel]
	=?iso-8859-15?q?=5BOpenvas-plugins=5D_Solaris_Loc?=
	=?iso-8859-15?q?al_Security=09Checks?=
In-Reply-To: <20081118070056.GB15568@intevation.de>
References: <200810312236.55376.timb@nth-dimension.org.uk>
	<200811172221.54094.timb@nth-dimension.org.uk>
	<20081118070056.GB15568@intevation.de>
Message-ID: <200811190009.04748.timb@nth-dimension.org.uk>

On Tuesday 18 November 2008 07:00:56 Michael Wiegand wrote:
> * Tim Brown [17. Nov 2008]:
> > Cheers Michael and Thomas, but actually that's not the problem :(.
> >
> > Obviously your check is an improvement on that ;).  I may have the chance
> > to run my scripts on a real world box this week, so I'll see if I can
> > nail down where my problem lies.
>
> That would have probably been too easy. :) Do you have any other hints
> as to what the problem might be? What goes wrong? I have access to a
> Solaris Box as well, so if there is anything you want me to test, just
> let me know.

Okay, I got the chance to do a bit of debugging this evening.  At the start of 
my copy of gather-package-list.nasl:

uname = ssh_cmd(socket:sock, cmd:"uname -a");

is called.  This successfully results in uname being set to "SunOS obfuscated 
5.o Generic_oooooo-oo sun4u sparc SUNW,UltraSPARC-IIi-cEngine".  Then at the 
end of the script, if uname is detected as starting with "SunOS ", then some 
more commands are run:

security_note(port:port, data:uname);
osversion = ssh_cmd(socket:sock, cmd:"uname -r");
security_note(port:port, data:osversion);
set_kb_item(name: "ssh/login/solosversion", value:osversion);
hardwaretype = ssh_cmd(socket:sock, cmd:"uname -p");
security_note(port:port, data:hardwaretype);
set_kb_item(name: "ssh/login/solhardwaretype", value:hardwaretype);
buf = ssh_cmd(socket:sock, cmd:"pkginfo");
security_note(port:port, data:buf);
set_kb_item(name: "ssh/login/solpackages", value:buf);
buf = ssh_cmd(socket:sock, cmd:"showrev -p");
security_note(port:port, data:buf);
set_kb_item(name: "ssh/login/solpatches", value:buf);

However, it appears that osversion etc never get populated.  Each debug 
security_note results in a hole being noted which contains the following 
data:

"This script will, if given a userid/password or
key to the remote system, login to that system,
determine the OS it is running, and for supported
systems, extract the list of installed packages/rpms."

This is the default value (description) which is used when (I believe) 
security_note is passed a null data parameter.  If I reorder the script so 
that the Solaris checks are carried out directly after the initial uname then 
it works.

In essence, the later ssh_cmd do not appear to run correctly.  I did try your 
patch to libopenvas MIchael, but that didn't seem to resolve it.

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

From michael.wiegand at intevation.de  Wed Nov 19 08:44:01 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 19 Nov 2008 08:44:01 +0100
Subject: [Openvas-devel] [Openvas-plugins] Solaris Local Security	Checks
In-Reply-To: <200811190009.04748.timb@nth-dimension.org.uk>
References: <200810312236.55376.timb@nth-dimension.org.uk>
	<200811172221.54094.timb@nth-dimension.org.uk>
	<20081118070056.GB15568@intevation.de>
	<200811190009.04748.timb@nth-dimension.org.uk>
Message-ID: <20081119074401.GA18497@intevation.de>

* Tim Brown [19. Nov 2008]:
> security_note(port:port, data:uname);
> osversion = ssh_cmd(socket:sock, cmd:"uname -r");
> ...
> 
> However, it appears that osversion etc never get populated. 

Odd. Just to clarify:
- Is osversion *never* populated or *not always*?
- Do uname -r etc yield reasonable output on your target system?

> If I reorder the script so that the Solaris checks are carried out
> directly after the initial uname then it works.
> 
> In essence, the later ssh_cmd do not appear to run correctly.

Yes, I'm suspecting this too. I think it has something to do with the
way ssh_func.inc handles connections in ssh_reuse_connection(). There
were some changes in there which seem to cause problem with ssh_cmd
acquiring the shared ssh socket, but I haven't yet been able to pinpoint
the exact issue.

Could you try your tests with an older version of ssh_func.inc, prior to
rev 1226?

I had the issue that gather-package-list.nasl would sometime correctly
report the remote OS, but on the next run wouldn't report anything at
all. This is probably SSH-related as well, did you observe something
similar?

> I did try your patch to libopenvas MIchael, but that didn't seem to
> resolve it.

Well, it didn't resolve it either for me. ;) But since it was obviously
broken, I decided to fix it before we forget the issue.

Regards,

Michael

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


From felix.wolfsteller at intevation.de  Wed Nov 19 10:55:45 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Wed, 19 Nov 2008 10:55:45 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
Message-ID: <200811191055.45667.felix.wolfsteller@intevation.de>

Hi
I opened CR #19 in the hope that we agree on some formatting and documentation 
rules ( http://www.openvas.org/openvas-cr-19.html ).

As I see it, there are no alternatives to doxygen. If we agree on doxygen we 
further have to agree on a doxygen configuration file (as long as 
documentation is local -> trivial) and on a style for the documentation 
blocks itself, as there are several possibilities ( 
http://www.stack.nl/~dimitri/doxygen/docblocks.html ).
I opt for the javadoc-like style ( e.g. @param ).

Note that I myself will not participate in huge discussions about where to put 
a space, a bracket, a newline etc, as the main aim is that we 1) agree on one 
style and 2) gradually bring a consistent look into the OpenVAS code base and 
3) achieve professional documentation.
That means, I will agree to everybody with a strong opinion.

Attached is a first proposal for an example file. It is based on 
slad_install.c and not intended to be compiled.

I would like to open the voting quite soon (I vote +1).

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: module.c
Type: text/x-csrc
Size: 3648 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081119/1e9738e1/module.c

From joey at infodrom.org  Mon Nov 17 16:53:14 2008
From: joey at infodrom.org (Joey Schulze)
Date: Mon, 17 Nov 2008 16:53:14 +0100
Subject: [Openvas-devel] Voting on Change Request #18
Message-ID: <20081117155314.GE12602@finlandia.home.infodrom.org>

Moin!

I have submitted another change request and would like to ask for
feedback and your votes on this issue.  The change request covers an
Improvement in the handling of false-positives.  It is online at
http://www.openvas.org/openvas-cr-18.html

If implemented this feature will help users recognise false-positives
in generated reports easier.  It will provide a means to re-prioritise
certain tests up to considering them false-positives.  The client GUI
would be improved to display false-positives differently than real
vulnerabilities and offer a way to alter priorities of certain tests.

Regards,

	Joey

-- 
Every use of Linux is a proper use of Linux.  -- Jon 'maddog' Hall

Please always Cc to me when replying to me on the lists.

From openvas-bugs at wald.intevation.org  Tue Nov 18 09:59:35 2008
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Tue, 18 Nov 2008 09:59:35 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B828=5D_Client_save?=
	=?utf-8?q?s_just_one_SSL_Certificate?=
Message-ID: <20081118085935.BEABF40762@pyrosoma.intevation.org>

Bugs item #828, was opened at 2008-11-18 08:59
Status: Open
Priority: 3
Submitted By: Felix Wolfsteller (felix)
Assigned to: Nobody (None)
Summary: Client saves just one SSL Certificate 
Resolution: None
Severity: trivial
Version: None
Component: openvas-client
Operating System: Linux
Product: None
Hardware: None
URL: 


Initial Comment:
Issue leads to accepting already accepted certificates.
Happens e.g. when having two scopes that are dealt with by two different servers.
Connect them alternating, the client shows the certificates, stating  that it has never been shown before. (Client just "knows" the latest).

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

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

From joey at infodrom.org  Wed Nov 19 15:34:28 2008
From: joey at infodrom.org (Joey Schulze)
Date: Wed, 19 Nov 2008 15:34:28 +0100
Subject: [Openvas-devel] Improved error message when trusted_ca does not
	exist
Message-ID: <20081119143427.GA1997@finlandia.home.infodrom.org>

Hi,

during installation and configuration of OpenVAS client and server
from SVN HEAD I stomped over an error message I could not parse.

Scenario:
  - trust level 2 || 3
  - trusted_ca unchanged (i.e. "cacert.pem")
  - file does not exist

This results in

| [24767] SSL_CTX_load_verify_locations: error:02001002:system library:fopen:No such file or directory

sent to stderr and an info box saying:

| Error while setting the trusted CA: cacert.pem\nSSL connections are likely to fail.

Using strace I found out what the problem was.

In order to help other people be able to parse the error message
properly I propose the patch below which emits a proper message
and also alters the paranoia level so that OpenSSL will not emit
errors on stderr.

Please let me know what you think.

Regards,

	Joey

-- 
It's practically impossible to look at a penguin and feel angry.

Please always Cc to me when replying to me on the lists.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas_trusted_ca.patch
Type: text/x-diff
Size: 537 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081119/c4c36f10/openvas_trusted_ca.bin

From sgros.ml at gmail.com  Thu Nov 20 12:46:42 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Thu, 20 Nov 2008 12:46:42 +0100
Subject: [Openvas-devel] Replacing libopenvas with glib...
Message-ID: <4d7b043c0811200346vc2fda16oc3efc00eb5050998@mail.gmail.com>

I changed thread for this topic because it's not related to 64-bit
issues any more...

So, few thoughts/questions about this...

> I am not aware of anyone approaching this.
> It is not a too simple task.

> My idea was that we should start with a
> struct NVT_Desc {} in OpenVAS-Client and step-by-step
> change to this strucure (which members are some Glib Datacontainers)
> all over the client. Probably some lessons need to be learned.
> Once finished this, the gained experience should be good
> enough to approach the server.

I couldn't figure out from this short description what you exactly intend to do.

I was looking a bit into arglists.c and it seems basically to be a
hash table that allows different objects to be stored and quickly
retrieved. The closest data structure in GLib seems to be GHashTable.
The problem is that GHashTable stores pointers so another layer above
it is necessary in order to replace arglists.c. In conclusion, it
would be relatively easy to modify arglists.c to use glib's functions
while the rest of the code stays unchanged.

But, there is still a problem. The layer implemented on top of glib
would be necessary in openvas-client and openvas-libraries, meaning
that the code duplication isn't solved. To solve this problem, two
approaches could be used:

1. Using your solution which I assume integrates parts of the code
into openvas-client itself and totally removes nessus subdirectory?

2. Keeping in code in SVN in on only one place, while before doing
releases duplicate code so that openvas-client is stand alone. In
other words, users who download some (pre)release do just standard
configure, make, make install process, while users who check out from
svn have to install openvas-libraries before client (I assume they are
advanced users per definition).

Note that harglists.c is more complicated than arglists.c and I
haven't looked into it yet.

Stjepan

> In the meantime we'll try to make the server as light as possible
> to increase readability of this code ;-)

From felix.wolfsteller at intevation.de  Thu Nov 20 12:47:05 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Thu, 20 Nov 2008 12:47:05 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <4d7b043c0811200323t3ab992bdxd2c9954a4d51ed66@mail.gmail.com>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<4d7b043c0811200323t3ab992bdxd2c9954a4d51ed66@mail.gmail.com>
Message-ID: <200811201247.05630.felix.wolfsteller@intevation.de>

Hi

On Thursday 20 November 2008 12:23:33 you wrote:
> What I wanted to suggest is that proposed code formatting should be
> based on some other popular open source project. That way it will be
> easier for newcomers to use it, especially if the given style is
> accepted in a large number of projects. For that matter I would
> propose using Linux Kernel guidelines. There is CodingStyle document
> that can be transfferend to OpenVAS.

Do you have a nice reference document for that? A quick search resulted in too  
many documents, each trying to summarize (their own) coding style.

> The second suggestion is that it should be (relatively) easy to do
> automatic reformatting using indent tool. The reason is that it's hard
> to expect that newcomers, but even experienced users, will follow
> closely formatting rules. Using indent the burden of style
> checking/correcting could be automated.

Tim and me had a tiny conversation about that ( 
http://www.linux.hr/openvas/archive/index.php?d=2008-11-19#msg4375 ). 
Reformatting all the old code seems to be a bit destructive to me at the 
moment (should have been done directly at fork times). And for new files I 
would suggest that its up to the devoloper to use one or not. However, we 
could encourage the usage of one or another tool.
But at the end, that is another discussion - whoever wants to summarize and 
give an opinion could open another thread. If the majority opts for 
automation and a specific tool here, I will of course include that in the 
compendium chapter.

-- felix

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

From sgros.ml at gmail.com  Thu Nov 20 12:55:45 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Thu, 20 Nov 2008 12:55:45 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <200811201247.05630.felix.wolfsteller@intevation.de>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<4d7b043c0811200323t3ab992bdxd2c9954a4d51ed66@mail.gmail.com>
	<200811201247.05630.felix.wolfsteller@intevation.de>
Message-ID: <4d7b043c0811200355k7105947cv60c385f7456acea6@mail.gmail.com>

On Thu, Nov 20, 2008 at 12:47 PM, Felix Wolfsteller
<felix.wolfsteller at intevation.de> wrote:
> Hi
>
> On Thursday 20 November 2008 12:23:33 you wrote:
>> What I wanted to suggest is that proposed code formatting should be
>> based on some other popular open source project. That way it will be
>> easier for newcomers to use it, especially if the given style is
>> accepted in a large number of projects. For that matter I would
>> propose using Linux Kernel guidelines. There is CodingStyle document
>> that can be transfferend to OpenVAS.
>
> Do you have a nice reference document for that? A quick search resulted in too
> many documents, each trying to summarize (their own) coding style.

It's included in each kernel release, but here is a link on a version
available on the Internet:

http://lxr.linux.no/linux+v2.6.27.6/Documentation/CodingStyle

And, while I'm at that, LXR is a great tool for cross referencing
source so it might be a good idea to use it on OpenVAS sometime in a
future.

>> The second suggestion is that it should be (relatively) easy to do
>> automatic reformatting using indent tool. The reason is that it's hard
>> to expect that newcomers, but even experienced users, will follow
>> closely formatting rules. Using indent the burden of style
>> checking/correcting could be automated.
>
> Tim and me had a tiny conversation about that (
> http://www.linux.hr/openvas/archive/index.php?d=2008-11-19#msg4375 ).
> Reformatting all the old code seems to be a bit destructive to me at the
> moment (should have been done directly at fork times). And for new files I
> would suggest that its up to the devoloper to use one or not. However, we
> could encourage the usage of one or another tool.
> But at the end, that is another discussion - whoever wants to summarize and
> give an opinion could open another thread. If the majority opts for
> automation and a specific tool here, I will of course include that in the
> compendium chapter.

Yes, it's definitely destructive to change existing code, especially
in a short time period. It will probably take some time unit majority
of the existing code is adjusted.

What I meant is for the new code submissions. Formatting can be
checked using something as:

1. patch source
2. do the copy
3. apply diff
4. see if a diff is too big and/or complex

Now, I know the things don't go so easy in practice, but at least
there is way to try to do it.

And BTW, my experience is that when I was reviewing patches, I was
losing too much time trying to align them to coding guidelines. That's
why I'm suggesting this approach. But them, some are more strict some
less, so it's only my opinion.

Stjepan

From sgros.ml at gmail.com  Thu Nov 20 13:01:06 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Thu, 20 Nov 2008 13:01:06 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <200811191055.45667.felix.wolfsteller@intevation.de>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
Message-ID: <4d7b043c0811200401w10afbeb3g480a6037b81a8317@mail.gmail.com>

I'm reposting this. I mistakenly used Reply instead of 'Reply all'.
Sorry for inconvenience.


Just a few comments/suggestions....

On Wed, Nov 19, 2008 at 10:55 AM, Felix Wolfsteller
<felix.wolfsteller at intevation.de> wrote:
> Hi
> I opened CR #19 in the hope that we agree on some formatting and documentation
> rules ( http://www.openvas.org/openvas-cr-19.html ).
>
> As I see it, there are no alternatives to doxygen. If we agree on doxygen we
> further have to agree on a doxygen configuration file (as long as
> documentation is local -> trivial) and on a style for the documentation
> blocks itself, as there are several possibilities (
> http://www.stack.nl/~dimitri/doxygen/docblocks.html ).
> I opt for the javadoc-like style ( e.g. @param ).
>
> Note that I myself will not participate in huge discussions about where to put
> a space, a bracket, a newline etc, as the main aim is that we 1) agree on one
> style and 2) gradually bring a consistent look into the OpenVAS code base and
> 3) achieve professional documentation.
> That means, I will agree to everybody with a strong opinion.

I have few suggestions regarding formatting style. But first, I have
to say that the biggest problem while trying to change code was the
lack of readability because on some places only one space is used for
indent, while at some other places indenting was wrong.

What I wanted to suggest is that proposed code formatting should be
based on some other popular open source project. That way it will be
easier for newcomers to use it, especially if the given style is
accepted in a large number of projects. For that matter I would
propose using Linux Kernel guidelines. There is CodingStyle document
that can be transfferend to OpenVAS. Additional notes could be placed
in a separate files, or in the same file clearly marked as
differences.

The second suggestion is that it should be (relatively) easy to do
automatic reformatting using indent tool. The reason is that it's hard
to expect that newcomers, but even experienced users, will follow
closely formatting rules. Using indent the burden of style
checking/correcting could be automated.

>
> Attached is a first proposal for an example file. It is based on
> slad_install.c and not intended to be compiled.

The file looks good, even though I would personally do some thing
differently, but it's not so important as long as the code is
readable.

Stjepan

From sgros.ml at gmail.com  Thu Nov 20 13:08:33 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Thu, 20 Nov 2008 13:08:33 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <4d7b043c0811200355k7105947cv60c385f7456acea6@mail.gmail.com>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<4d7b043c0811200323t3ab992bdxd2c9954a4d51ed66@mail.gmail.com>
	<200811201247.05630.felix.wolfsteller@intevation.de>
	<4d7b043c0811200355k7105947cv60c385f7456acea6@mail.gmail.com>
Message-ID: <4d7b043c0811200408t6219232aq56dac6021c8aa295@mail.gmail.com>

On Thu, Nov 20, 2008 at 12:55 PM, Stjepan Gros <sgros.ml at gmail.com> wrote:
> On Thu, Nov 20, 2008 at 12:47 PM, Felix Wolfsteller
> <felix.wolfsteller at intevation.de> wrote:
>> Hi
>>
>> On Thursday 20 November 2008 12:23:33 you wrote:
>>> What I wanted to suggest is that proposed code formatting should be
>>> based on some other popular open source project. That way it will be
>>> easier for newcomers to use it, especially if the given style is
>>> accepted in a large number of projects. For that matter I would
>>> propose using Linux Kernel guidelines. There is CodingStyle document
>>> that can be transfferend to OpenVAS.
>>
>> Do you have a nice reference document for that? A quick search resulted in too
>> many documents, each trying to summarize (their own) coding style.
>
> It's included in each kernel release, but here is a link on a version
> available on the Internet:
>
> http://lxr.linux.no/linux+v2.6.27.6/Documentation/CodingStyle
>
> And, while I'm at that, LXR is a great tool for cross referencing
> source so it might be a good idea to use it on OpenVAS sometime in a
> future.
>
>>> The second suggestion is that it should be (relatively) easy to do
>>> automatic reformatting using indent tool. The reason is that it's hard
>>> to expect that newcomers, but even experienced users, will follow
>>> closely formatting rules. Using indent the burden of style
>>> checking/correcting could be automated.
>>
>> Tim and me had a tiny conversation about that (
>> http://www.linux.hr/openvas/archive/index.php?d=2008-11-19#msg4375 ).
>> Reformatting all the old code seems to be a bit destructive to me at the
>> moment (should have been done directly at fork times). And for new files I
>> would suggest that its up to the devoloper to use one or not. However, we
>> could encourage the usage of one or another tool.
>> But at the end, that is another discussion - whoever wants to summarize and
>> give an opinion could open another thread. If the majority opts for
>> automation and a specific tool here, I will of course include that in the
>> compendium chapter.
>
> Yes, it's definitely destructive to change existing code, especially
> in a short time period. It will probably take some time unit majority
> of the existing code is adjusted.
>
> What I meant is for the new code submissions. Formatting can be
> checked using something as:
>
> 1. patch source
> 2. do the copy
> 3. apply diff
> 4. see if a diff is too big and/or complex

Oops, I have a bug here... The correct steps are:

1. patch source
2. do the copy
3. use ident on one copy
4. do the diff
5. see if a diff is to big and/or complex

>
> Now, I know the things don't go so easy in practice, but at least
> there is way to try to do it.
>
> And BTW, my experience is that when I was reviewing patches, I was
> losing too much time trying to align them to coding guidelines. That's
> why I'm suggesting this approach. But them, some are more strict some
> less, so it's only my opinion.

Stjepan

From michael.wiegand at intevation.de  Fri Nov 21 12:00:16 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Fri, 21 Nov 2008 12:00:16 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <200811191055.45667.felix.wolfsteller@intevation.de>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
Message-ID: <20081121110016.GE24413@intevation.de>

* Felix Wolfsteller [20. Nov 2008]:
> Hi
> I opened CR #19 in the hope that we agree on some formatting and documentation 
> rules ( http://www.openvas.org/openvas-cr-19.html ).
> 
> Attached is a first proposal for an example file. It is based on 
> slad_install.c and not intended to be compiled.
> 
> I would like to open the voting quite soon (I vote +1).

(+1) as well, a consisten documentation format would certainly be
helpful.

Regards,

Michael

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


From jan-oliver.wagner at intevation.de  Fri Nov 21 05:14:04 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 21 Nov 2008 05:14:04 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <200811201247.05630.felix.wolfsteller@intevation.de>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<4d7b043c0811200323t3ab992bdxd2c9954a4d51ed66@mail.gmail.com>
	<200811201247.05630.felix.wolfsteller@intevation.de>
Message-ID: <200811210514.04334.jan-oliver.wagner@intevation.de>

Am Thursday 20 November 2008 12:47:05 schrieb Felix Wolfsteller:
> Reformatting all the old code seems to be a bit destructive to me at the
> moment

I am strictly against reformatting of code where no other changes happen.

> (should have been done directly at fork times).

The intention not to do it was to have Nessus patches still apply to OpenVAS
and vice versa. Well, Tenable rapidly closed down any access to their SVN. So 
it was only for the benefit of Nessus ;-)

> And for new files I  
> would suggest that its up to the devoloper to use one or not. However, we
> could encourage the usage of one or another tool.
> But at the end, that is another discussion - whoever wants to summarize and
> give an opinion could open another thread. If the majority opts for
> automation and a specific tool here, I will of course include that in the
> compendium chapter.

Formatting the code in a specific style (GNU) should be recommended,
but not be mandatory. I'd say we should have few mandatory rules like:
* no tabs, just spaces
* Indention of 2 characters

What I'd like to have mandatory is the documentation of functions.

Best

Jan

From timb at nth-dimension.org.uk  Fri Nov 21 23:41:17 2008
From: timb at nth-dimension.org.uk (Tim Brown)
Date: Fri, 21 Nov 2008 22:41:17 +0000
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <200811210514.04334.jan-oliver.wagner@intevation.de>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<200811201247.05630.felix.wolfsteller@intevation.de>
	<200811210514.04334.jan-oliver.wagner@intevation.de>
Message-ID: <200811212241.17362.timb@nth-dimension.org.uk>

On Friday 21 November 2008 04:14:04 Jan-Oliver Wagner wrote:
> Am Thursday 20 November 2008 12:47:05 schrieb Felix Wolfsteller:
> > Reformatting all the old code seems to be a bit destructive to me at the
> > moment
>
> I am strictly against reformatting of code where no other changes happen.

Agreed, my proposal was to run files through an agreed prettifier when 
substantial changes are made.

*snip*

> Formatting the code in a specific style (GNU) should be recommended,
> but not be mandatory. I'd say we should have few mandatory rules like:
> * no tabs, just spaces
> * Indention of 2 characters

I'd much prefer tabs.  Any sensible editor can be configured to render them as 
required.

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

From sgros.ml at gmail.com  Sat Nov 22 09:36:32 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Sat, 22 Nov 2008 09:36:32 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <200811212241.17362.timb@nth-dimension.org.uk>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<200811201247.05630.felix.wolfsteller@intevation.de>
	<200811210514.04334.jan-oliver.wagner@intevation.de>
	<200811212241.17362.timb@nth-dimension.org.uk>
Message-ID: <4d7b043c0811220036p2fe313e5s27000918b34be1a2@mail.gmail.com>

On Fri, Nov 21, 2008 at 11:41 PM, Tim Brown <timb at nth-dimension.org.uk> wrote:
> On Friday 21 November 2008 04:14:04 Jan-Oliver Wagner wrote:
>> Am Thursday 20 November 2008 12:47:05 schrieb Felix Wolfsteller:
>> > Reformatting all the old code seems to be a bit destructive to me at the
>> > moment
>>
>> I am strictly against reformatting of code where no other changes happen.
>
> Agreed, my proposal was to run files through an agreed prettifier when
> substantial changes are made.
>
> *snip*
>
>> Formatting the code in a specific style (GNU) should be recommended,
>> but not be mandatory. I'd say we should have few mandatory rules like:
>> * no tabs, just spaces
>> * Indention of 2 characters
>
> I'd much prefer tabs.  Any sensible editor can be configured to render them as
> required.

It's easier to type one tab instead of N spaces...

Stjepan

From kost at linux.hr  Sat Nov 22 10:44:41 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Sat, 22 Nov 2008 10:44:41 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <4d7b043c0811220036p2fe313e5s27000918b34be1a2@mail.gmail.com>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<200811201247.05630.felix.wolfsteller@intevation.de>
	<200811210514.04334.jan-oliver.wagner@intevation.de>
	<200811212241.17362.timb@nth-dimension.org.uk>
	<4d7b043c0811220036p2fe313e5s27000918b34be1a2@mail.gmail.com>
Message-ID: <20081122094441.GA26030@griffin.linux.hr>

On Sat, Nov 22, 2008 at 09:36:32AM +0100, Stjepan Gros wrote:
> On Fri, Nov 21, 2008 at 11:41 PM, Tim Brown <timb at nth-dimension.org.uk> wrote:
> >> Formatting the code in a specific style (GNU) should be recommended,
> >> but not be mandatory. I'd say we should have few mandatory rules like:
> >> * no tabs, just spaces
> >> * Indention of 2 characters
> > I'd much prefer tabs.  Any sensible editor can be configured to render them as
> > required.
> It's easier to type one tab instead of N spaces...

One more vote for tab(s)...
-- 
Vlatko Kosturjak - KoSt                                  ICQ: 3631122

From jan-oliver.wagner at intevation.de  Mon Nov 24 09:54:04 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 24 Nov 2008 09:54:04 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <20081122094441.GA26030@griffin.linux.hr>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<4d7b043c0811220036p2fe313e5s27000918b34be1a2@mail.gmail.com>
	<20081122094441.GA26030@griffin.linux.hr>
Message-ID: <200811240954.06072.jan-oliver.wagner@intevation.de>

On Samstag, 22. November 2008, Vlatko Kosturjak wrote:
> On Sat, Nov 22, 2008 at 09:36:32AM +0100, Stjepan Gros wrote:
> > On Fri, Nov 21, 2008 at 11:41 PM, Tim Brown <timb at nth-dimension.org.uk> wrote:
> > >> Formatting the code in a specific style (GNU) should be recommended,
> > >> but not be mandatory. I'd say we should have few mandatory rules like:
> > >> * no tabs, just spaces
> > >> * Indention of 2 characters
> > > I'd much prefer tabs.  Any sensible editor can be configured to render them as
> > > required.
> > It's easier to type one tab instead of N spaces...
> 
> One more vote for tab(s)...

oops ;-)

My rationale why to not use tabs is that in any community development,
you will have different use of tabs (2, 4, 6, 8).
In theory the editor should just show the code in the right way.
But in practice I've never seen  this work, because those who
use e.g. 8 sometime add a few spaces to make the code readable
or who use 2, sometimes they forget about using tab and just apply
2 spaces.
The code ends up less readable (you can easily see this if you
configure your editor to mark tabs explicitely).
The only basis (and the only(!) automatable one!) that can be agreed
on is no tabs. You can configure you editor to do so and will feel just like
you work with tabs.

Best

	Jan

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

From openvas-bugs at wald.intevation.org  Thu Nov 20 10:16:48 2008
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Thu, 20 Nov 2008 10:16:48 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B830=5D_Links_in_cl?=
	=?utf-8?q?ients_HTML_reports_broken?=
Message-ID: <20081120091648.61B4114237@pyrosoma.intevation.org>

Bugs item #830, was opened at 2008-11-20 09:16
Status: Open
Priority: 3
Submitted By: Felix Wolfsteller (felix)
Assigned to: Nobody (None)
Summary: Links in clients HTML reports broken 
Resolution: None
Severity: normal
Version: None
Component: openvas-client
Operating System: None
Product: OpenVAS
Hardware: None
URL: 


Initial Comment:
Links to NVTs point to invalid http://openvas.org/[oid.oid] adress.

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

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

From openvas-bugs at wald.intevation.org  Thu Nov 20 16:32:20 2008
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Thu, 20 Nov 2008 16:32:20 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B832=5D_libnasl_com?=
	=?utf-8?q?pilation_fails?=
Message-ID: <20081120153220.83D794075A@pyrosoma.intevation.org>

Bugs item #832, was opened at 2008-11-20 15:32
Status: Open
Priority: 3
Submitted By: Andrew Simmons (imipak)
Assigned to: Nobody (None)
Summary: libnasl compilation fails 
Resolution: None
Severity: normal
Version: v2.0-beta
Component: openvas-libnasl
Operating System: Linux
Product: OpenVAS
Hardware: Other
URL: 


Initial Comment:
Compilation of libnasl-2.0 beta 2 fails. 

Mandriva 2007.1 on a Lenovo Thinkpad

2.6.17-5mdv #1 SMP Wed Sep 13 14:32:31 EDT 2006 i686 Intel(R) Core(TM)2 CPU         T5600  @ 1.83GHz GNU/Linux

$ make
[...]

nasl_nessusd_glue.o: In function `debug_message':
/home/asimmons/src/openVAS/openvas-libnasl-2.0.0.beta2/nasl/nasl_nessusd_glue.c:916: undefined reference to `post_debug'
/home/asimmons/src/openVAS/openvas-libnasl-2.0.0.beta2/nasl/nasl_nessusd_glue.c:916: undefined reference to `proto_post_debug'
nasl_nessusd_glue.o: In function `log_message':
/home/asimmons/src/openVAS/openvas-libnasl-2.0.0.beta2/nasl/nasl_nessusd_glue.c:911: undefined reference to `post_log'
/home/asimmons/src/openVAS/openvas-libnasl-2.0.0.beta2/nasl/nasl_nessusd_glue.c:911: undefined reference to `proto_post_log'
collect2: ld returned 1 exit status
make[1]: *** [openvas-nasl] Error 1


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

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

From joey at infodrom.org  Sat Nov 22 11:40:32 2008
From: joey at infodrom.org (Joey Schulze)
Date: Sat, 22 Nov 2008 11:40:32 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <200811210514.04334.jan-oliver.wagner@intevation.de>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<4d7b043c0811200323t3ab992bdxd2c9954a4d51ed66@mail.gmail.com>
	<200811201247.05630.felix.wolfsteller@intevation.de>
	<200811210514.04334.jan-oliver.wagner@intevation.de>
Message-ID: <20081122104032.GA32500@finlandia.home.infodrom.org>

Jan-Oliver Wagner wrote:
> Am Thursday 20 November 2008 12:47:05 schrieb Felix Wolfsteller:
> > Reformatting all the old code seems to be a bit destructive to me at the
> > moment
> 
> I am strictly against reformatting of code where no other changes happen.

If the source is being reformatted, reformatting should be committed
to the repository *without* any code changes.  Otherwise code changes
are hidden (burried) within reformatting and are very difficult to detect.

> > (should have been done directly at fork times).
> 
> The intention not to do it was to have Nessus patches still apply to OpenVAS
> and vice versa. Well, Tenable rapidly closed down any access to their SVN. So 
> it was only for the benefit of Nessus ;-)

Hmm... so that's not an argument anymore...

Regards,

	Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book

Please always Cc to me when replying to me on the lists.

From jan-oliver.wagner at intevation.de  Mon Nov 24 12:37:56 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 24 Nov 2008 12:37:56 +0100
Subject: [Openvas-devel] Voting on Change Request #18
In-Reply-To: <20081117155314.GE12602@finlandia.home.infodrom.org>
References: <20081117155314.GE12602@finlandia.home.infodrom.org>
Message-ID: <200811241237.57830.jan-oliver.wagner@intevation.de>

On Montag, 17. November 2008, Joey Schulze wrote:
> I have submitted another change request and would like to ask for
> feedback and your votes on this issue.  The change request covers an
> Improvement in the handling of false-positives.  It is online at
> http://www.openvas.org/openvas-cr-18.html
> 
> If implemented this feature will help users recognise false-positives
> in generated reports easier.  It will provide a means to re-prioritise
> certain tests up to considering them false-positives.  The client GUI
> would be improved to display false-positives differently than real
> vulnerabilities and offer a way to alter priorities of certain tests.

I've rephrased the CR a little bit.

It's adressing an issue from an early survey still described here:
http://www.openvas.org/roadmap.html
("Plugin severity override")

IMHO it is a very important issue and I vote +1 on it.

I added the need to define a format for this filter data.
Specifying this is probably the first thing to start with.

Best

	Jan


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

From jan-oliver.wagner at intevation.de  Mon Nov 24 14:18:33 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 24 Nov 2008 14:18:33 +0100
Subject: [Openvas-devel] Replacing libopenvas with glib...
In-Reply-To: <4d7b043c0811200346vc2fda16oc3efc00eb5050998@mail.gmail.com>
References: <4d7b043c0811200346vc2fda16oc3efc00eb5050998@mail.gmail.com>
Message-ID: <200811241418.35186.jan-oliver.wagner@intevation.de>

On Donnerstag, 20. November 2008, Stjepan Gros wrote:
> > My idea was that we should start with a
> > struct NVT_Desc {} in OpenVAS-Client and step-by-step
> > change to this strucure (which members are some Glib Datacontainers)
> > all over the client. Probably some lessons need to be learned.
> > Once finished this, the gained experience should be good
> > enough to approach the server.
> 
> I couldn't figure out from this short description what you exactly intend to do.
> 
> I was looking a bit into arglists.c and it seems basically to be a
> hash table that allows different objects to be stored and quickly
> retrieved. The closest data structure in GLib seems to be GHashTable.
> The problem is that GHashTable stores pointers so another layer above
> it is necessary in order to replace arglists.c. In conclusion, it
> would be relatively easy to modify arglists.c to use glib's functions
> while the rest of the code stays unchanged.

the main goal of a change towards glib should be to improve
readability of code and to reduce code.
So, while your observation is quite interesting, I am not sure
yet how much source code could be eliminated this way.
Readability probably would not improve.
 
> But, there is still a problem. The layer implemented on top of glib
> would be necessary in openvas-client and openvas-libraries, meaning
> that the code duplication isn't solved. To solve this problem, two
> approaches could be used:

Indeed this problem would remain unsolved.

> 1. Using your solution which I assume integrates parts of the code
> into openvas-client itself and totally removes nessus subdirectory?

> 2. Keeping in code in SVN in on only one place, while before doing
> releases duplicate code so that openvas-client is stand alone. In
> other words, users who download some (pre)release do just standard
> configure, make, make install process, while users who check out from
> svn have to install openvas-libraries before client (I assume they are
> advanced users per definition).

Eventually, nessus subdir should be eliminated. Frankly, I do not expect
this to happen soon.
My appraoch aims at removing arglist, harglist and some other modules
from openvas-client/libnessus/ and replace them by something like
openvas-client/src/core/ovas-data.c
Eventually this module will move into openvas-libraries (at the time,
openvas-client is made dependent on openvas-libraries). And the next step
after this would be to replace arglist & friends from openvas-libraries
by the new methods.
Sorry, that this is still a bit fuzzy. The ideas are not fully developed yet.

Best

	Jan 

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

From joey at infodrom.org  Wed Nov 26 20:32:08 2008
From: joey at infodrom.org (Joey Schulze)
Date: Wed, 26 Nov 2008 20:32:08 +0100
Subject: [Openvas-devel] Voting on Change Request #21: Improved sorting of
	vulnerabilities
Message-ID: <20081126193208.GA23449@finlandia.home.infodrom.org>

Moin!

I have submitted another change request and would like to ask for
feedback and your votes on this issue.  The change request covers an
Improvement in the visibility of discovered vulnerabilities.  It will
soon be online at <http://www.openvas.org/openvas-cr-21.html>.

In my opinion vulnerabilities should be sorted from the most dangerous
vulnerability to least dangerous one.  I.e. High, Medium, Low and not
vice versa as it is currently the case in the main window for report
summaries.  If the window is not large enough, the summary of high
priority vulnerabilities is currently hidden.

Therefore I propose to reverse the order of these three columns in the
main tree view.

Regards,

	Joey

-- 
Long noun chains don't automatically imply security.  -- Bruce Schneier

Please always Cc to me when replying to me on the lists.

From gregdubol at gmail.com  Wed Nov 26 13:53:14 2008
From: gregdubol at gmail.com (greg drap)
Date: Wed, 26 Nov 2008 12:53:14 +0000
Subject: [Openvas-devel] Bug Beta 2
Message-ID: <5f2cd1920811260453k2e1fdf35t663fe15681268509@mail.gmail.com>

Hello,

Thanks for your very good product but I have few problems since this
morning.

I realized a scan,it works perfectly and after that I update my server by
using the command openvas-nvt-sync

Since that update my server doesn't work and show me this error.

Did I do something wrong?

Thanks

bt ~ # openvasd -D
Loading the plugins... 102 (out of 11969)[3136]() gpgme_engine_check_version
failed: GPGME/Invalid crypto engine
Segmentation fault
bt ~ # openvasd -d
This is OpenVAS 2.0.0 for Linux 2.6.21.5
compiled with gcc version 4.1.2
Current setup :
        openvas-libnasl                : 2.0.0.beta2
        openvas-libraries              : 2.0.0.beta2
        SSL is used for client / server communication
        Running as euid                : 0


Include these infos in your bug reports
bt ~ #
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081126/928630b7/attachment.htm

From kost at linux.hr  Thu Nov 27 08:56:32 2008
From: kost at linux.hr (Vlatko Kosturjak)
Date: Thu, 27 Nov 2008 08:56:32 +0100
Subject: [Openvas-devel] Bug Beta 2
In-Reply-To: <5f2cd1920811260453k2e1fdf35t663fe15681268509@mail.gmail.com>
References: <5f2cd1920811260453k2e1fdf35t663fe15681268509@mail.gmail.com>
Message-ID: <492E52B0.3060302@linux.hr>

I see you're using Backtrack with OpenVAS. Backtrack comes with broken
libgpgme library, so you need to compile your own libgpgme library. You
can read about it here:
http://forums.remote-exploit.org/showthread.php?t=18325

But, to be short, we have made lzm package of beta 2 which you can
download here (together with the working libgpgme library):
http://www.openvas.org/openvas-bt.html

Hope it helps!

greg drap wrote:
> Hello,
> 
> Thanks for your very good product but I have few problems since this
> morning.
> 
> I realized a scan,it works perfectly and after that I update my server
> by using the command openvas-nvt-sync
> 
> Since that update my server doesn't work and show me this error.
> 
> Did I do something wrong?
> 
> Thanks
> 
> bt ~ # openvasd -D
> Loading the plugins... 102 (out of 11969)[3136]()
> gpgme_engine_check_version failed: GPGME/Invalid crypto engine
> Segmentation fault
> bt ~ # openvasd -d
> This is OpenVAS 2.0.0 for Linux 2.6.21.5 <http://2.6.21.5>
> compiled with gcc version 4.1.2
> Current setup :
>         openvas-libnasl                : 2.0.0.beta2
>         openvas-libraries              : 2.0.0.beta2
>         SSL is used for client / server communication
>         Running as euid                : 0
> 
> 
> Include these infos in your bug reports
> bt ~ #                                  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openvas-devel mailing list
> Openvas-devel at wald.intevation.org
> http://lists.wald.intevation.org/mailman/listinfo/openvas-devel

From felix.wolfsteller at intevation.de  Thu Nov 27 09:37:34 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Thu, 27 Nov 2008 09:37:34 +0100
Subject: [Openvas-devel] Voting on Change Request #21: Improved sorting
	of vulnerabilities
In-Reply-To: <20081126193208.GA23449@finlandia.home.infodrom.org>
References: <20081126193208.GA23449@finlandia.home.infodrom.org>
Message-ID: <200811270937.34979.felix.wolfsteller@intevation.de>

Sounds good to me, just two remarks that could be included:

1) exported reports (most important pdf, i guess) should follow this scheme as 
well. I guess, this would follow from the changes in nbe/backend, but i am 
not 100% convinced.

2) Of course the priorities-to-be of CR#18 
(http://openvas.org/openvas-cr-18.html) have to be integrated nicely, too.


On Wednesday 26 November 2008 20:32:08 Joey Schulze wrote:
> Moin!
>
> I have submitted another change request and would like to ask for
> feedback and your votes on this issue.  The change request covers an
> Improvement in the visibility of discovered vulnerabilities.  It will
> soon be online at <http://www.openvas.org/openvas-cr-21.html>.
>
> In my opinion vulnerabilities should be sorted from the most dangerous
> vulnerability to least dangerous one.  I.e. High, Medium, Low and not
> vice versa as it is currently the case in the main window for report
> summaries.  If the window is not large enough, the summary of high
> priority vulnerabilities is currently hidden.
>
> Therefore I propose to reverse the order of these three columns in the
> main tree view.
>
> Regards,
>
> 	Joey


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

From felix.wolfsteller at intevation.de  Thu Nov 27 09:40:26 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Thu, 27 Nov 2008 09:40:26 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <200811191055.45667.felix.wolfsteller@intevation.de>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
Message-ID: <200811270940.27063.felix.wolfsteller@intevation.de>

Okay, to refuel the process, I summarize what was said about CR #19
( http://www.openvas.org/openvas-cr-19.html ).
I hope that I did not misunderstood or forgot any comment - correct me if i am 
wrong.

1) Documentation/ Doxygen
Comment from Michael (likes it) and Jan (would like to have it mandatory). No 
disagreement about the need of a documentation. Stepjan proposed to use LXN 
some time in the future.

-> interpretation: pretty much agreed on initial proposal regarding doxygen 
and the associated comment style.

2) Coding Style
* Existing guidelines:
Stjepan and Jan proposed to look at existing guidelines (other big projects/ 
Kernel/ GNU).
* Changing style in existing files:
Changing code format in "old" files is debated. Joey notes that 
changing the style only "when substantial changes are made" would imply 
commits that change style _and_ content, which is to be disliked as the 
changes are hidden and difficult to detect.
* Prettifiers:
Usage of prettifier- tools is debated. Tendency to advocate usage of a tool 
only for new files.
* Tabs/spaces:
Whether to use tabs or spaces seems to be a hot topic. 
tim, vlatko and stjepan would prefer tabs. The pro- arguments so far are that 
it is easier to type and that editors can be configured to display one '\t' 
as n spaces.
jan-oliver favours spaces and argues that as tabs and spaces are often mixed 
and various numbers for spaces are used for one tab, only the use of spaces 
works in practice, and that editors can be configured to insert n spaces per 
tab-key press. 

-> interpretation: if and how old code shall be changed might be decided in 
another change request.  No discussion about the proposed example file, but 
generally a wish to use existing solutions.
Argumentation stronger for spaces, however the majority would like to use 
spaces.

I would like to have a final state of the Change Request soon, so please set 
by the space/tab conflict and add thoughts about the proposed example file or 
references to any guideline that you enjoyed most.

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 joey at infodrom.org  Thu Nov 27 10:43:25 2008
From: joey at infodrom.org (Joey Schulze)
Date: Thu, 27 Nov 2008 10:43:25 +0100
Subject: [Openvas-devel] Voting on Change Request #21: Improved
	sorting	of vulnerabilities
In-Reply-To: <200811270937.34979.felix.wolfsteller@intevation.de>
References: <20081126193208.GA23449@finlandia.home.infodrom.org>
	<200811270937.34979.felix.wolfsteller@intevation.de>
Message-ID: <20081127094325.GZ12602@finlandia.home.infodrom.org>

Felix Wolfsteller wrote:
> Sounds good to me, just two remarks that could be included:
> 
> 1) exported reports (most important pdf, i guess) should follow this scheme as 
> well. I guess, this would follow from the changes in nbe/backend, but i am 
> not 100% convinced.

I haven't yet seen those reports.  If they list vulnerabilities in the
same order I'd expect the output generators to require adjustments as well.

The PDF file already lists "Holes | Warnings | Notes" which seem to be
in the proper order already.

> 2) Of course the priorities-to-be of CR#18 
> (http://openvas.org/openvas-cr-18.html) have to be integrated nicely, too.

That's the least difficult part...

I'd expect a false positive to be less important than a low priority
vulnerability, so it'll be added at the right end of the scale.

Regards,

	Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erd?s

Please always Cc to me when replying to me on the lists.

From felix.wolfsteller at intevation.de  Thu Nov 27 10:58:28 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Thu, 27 Nov 2008 10:58:28 +0100
Subject: [Openvas-devel] Voting on Change Request #21: Improved sorting
	of vulnerabilities
In-Reply-To: <20081127094325.GZ12602@finlandia.home.infodrom.org>
References: <20081126193208.GA23449@finlandia.home.infodrom.org>
	<200811270937.34979.felix.wolfsteller@intevation.de>
	<20081127094325.GZ12602@finlandia.home.infodrom.org>
Message-ID: <200811271058.28709.felix.wolfsteller@intevation.de>

> > 1) exported reports (most important pdf, i guess) should follow this
> > scheme as well. I guess, this would follow from the changes in
> > nbe/backend, but i am not 100% convinced.
>
> I haven't yet seen those reports.  If they list vulnerabilities in the
> same order I'd expect the output generators to require adjustments as well.
>
> The PDF file already lists "Holes | Warnings | Notes" which seem to be
> in the proper order already.

Ya, you're right. Just looked the other way for me, because in the test setup 
there was a vulnerability for the "highest" (in report latests) port, a 
warning for middle one and a note for the first (lowest).

Anyway I vote +1.

-- 
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 joey at infodrom.org  Thu Nov 27 15:17:05 2008
From: joey at infodrom.org (Joey Schulze)
Date: Thu, 27 Nov 2008 15:17:05 +0100
Subject: [Openvas-devel] Voting on Change Request #18
In-Reply-To: <200811241237.57830.jan-oliver.wagner@intevation.de>
References: <20081117155314.GE12602@finlandia.home.infodrom.org>
	<200811241237.57830.jan-oliver.wagner@intevation.de>
Message-ID: <20081127141704.GA32071@finlandia.home.infodrom.org>

Jan-Oliver Wagner wrote:
> On Montag, 17. November 2008, Joey Schulze wrote:
> > I have submitted another change request and would like to ask for
> > feedback and your votes on this issue.  The change request covers an
> > Improvement in the handling of false-positives.  It is online at
> > http://www.openvas.org/openvas-cr-18.html
> > 
> > If implemented this feature will help users recognise false-positives
> > in generated reports easier.  It will provide a means to re-prioritise
> > certain tests up to considering them false-positives.  The client GUI
> > would be improved to display false-positives differently than real
> > vulnerabilities and offer a way to alter priorities of certain tests.
> 
> I've rephrased the CR a little bit.
> 
> It's adressing an issue from an early survey still described here:
> http://www.openvas.org/roadmap.html
> ("Plugin severity override")
> 
> IMHO it is a very important issue and I vote +1 on it.

You're the only one who has voted on this issue.  What to do now?

> I added the need to define a format for this filter data.
> Specifying this is probably the first thing to start with.

Do you see a problem of using the regular place, i.e. the openvasrc
file, for the proper scope?

We only need script_id + host + new priority.  Having this information
in the scope configuration gives us the benefit of having different
scopes for the same task where the user is able to specify priorities
differently.

Regards,

	Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erd?s

Please always Cc to me when replying to me on the lists.

From michael.wiegand at intevation.de  Thu Nov 27 15:31:48 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Thu, 27 Nov 2008 15:31:48 +0100
Subject: [Openvas-devel] Voting on Change Request #18
In-Reply-To: <20081127141704.GA32071@finlandia.home.infodrom.org>
References: <20081117155314.GE12602@finlandia.home.infodrom.org>
	<200811241237.57830.jan-oliver.wagner@intevation.de>
	<20081127141704.GA32071@finlandia.home.infodrom.org>
Message-ID: <20081127143148.GD18591@intevation.de>

* Martin Schulze [27. Nov 2008]:
> > IMHO it is a very important issue and I vote +1 on it.
> 
> You're the only one who has voted on this issue.  What to do now?

Well, it's a positive result, so I'd say the CR is accepted. FWIW, I'd
like to vote +1 as well. I thought I voted already, but that seems to
have been another CR ... sorry for that.

Regards,

Michael

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


From joey at infodrom.org  Thu Nov 27 15:37:20 2008
From: joey at infodrom.org (Joey Schulze)
Date: Thu, 27 Nov 2008 15:37:20 +0100
Subject: [Openvas-devel] Consistent text phrases in reports
Message-ID: <20081127143720.GA2829@finlandia.home.infodrom.org>

Moin,

I've noticed that texts in the reports are not always consistent.

For example in the HTML output the "Analysis of Host" contains for
each port:

 . Security hole found
 . Security warning(s) found
 . Security notes found

Wouldn't it be better if these texts would either be

 a) all singular,
 b) all singular + "(s)", or
 c) all plural

instead of mixing all three of them?  These are static texts in
nessus/html_output.c.

Regards,

	Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erd?s

Please always Cc to me when replying to me on the lists.

From joey at infodrom.org  Thu Nov 27 18:21:11 2008
From: joey at infodrom.org (Joey Schulze)
Date: Thu, 27 Nov 2008 18:21:11 +0100
Subject: [Openvas-devel] Print signature and trust level information
Message-ID: <20081127172111.GA20889@finlandia.home.infodrom.org>

Felix,

I saw this note:

|  * nessus/pdf_output.c : Added printing of signature and trust level
|  information.

Shouldn't this information be added to HTML output, XML output, NBE
output and ASCII output as well?

Regards,

	Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erd?s

Please always Cc to me when replying to me on the lists.

From joey at infodrom.org  Thu Nov 27 21:22:59 2008
From: joey at infodrom.org (Joey Schulze)
Date: Thu, 27 Nov 2008 21:22:59 +0100
Subject: [Openvas-devel] Certificate error after scanning a host
Message-ID: <20081127202259.GE12602@finlandia.home.infodrom.org>

Moin,

for some days I see "report_save() couldn't save the certificate information"
after a scan.  This change is caused by the need to store the certificate and
the possibility to display certificate information.

However, context->signer_fp_certificates == NULL is considered an error
and thus routines fail, resulting in this error message.

Is this really the expected behaviour?

The problem is that (a) signer_fp_certificates is NULL and (b) that
openvas_certificate_file_write is called unconditionally in report.c
(report_save).

The attached patch fixes this.  Please let me know if I should commit it.

Regards,

	Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erd?s

Please always Cc to me when replying to me on the lists.
-------------- next part --------------
Index: nessus/report.c
===================================================================
--- nessus/report.c	(revision 1839)
+++ nessus/report.c	(working copy)
@@ -197,8 +198,8 @@
 
   /* Save the certificate information (as of now) to 
      report_dir/certificate file */
-  gboolean success = openvas_certificate_file_write(context, report_get_certificates_filename(report_context));
-  if(success == FALSE)
+  if (context->signer_fp_certificates != NULL &&
+      openvas_certificate_file_write(context, report_get_certificates_filename(report_context)) == FALSE)
     {
     show_error(_("report_save() couldn't save the certificate information"));
     return;

From jan-oliver.wagner at intevation.de  Fri Nov 28 09:17:05 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 28 Nov 2008 09:17:05 +0100
Subject: [Openvas-devel] Voting on Change Request #18
In-Reply-To: <20081127141704.GA32071@finlandia.home.infodrom.org>
References: <20081117155314.GE12602@finlandia.home.infodrom.org>
	<200811241237.57830.jan-oliver.wagner@intevation.de>
	<20081127141704.GA32071@finlandia.home.infodrom.org>
Message-ID: <200811280917.07503.jan-oliver.wagner@intevation.de>

On Donnerstag, 27. November 2008, Joey Schulze wrote:
> Jan-Oliver Wagner wrote:
> > IMHO it is a very important issue and I vote +1 on it.
> 
> You're the only one who has voted on this issue.  What to do now?

the author usually votes +1 as well ;-)
 
> > I added the need to define a format for this filter data.
> > Specifying this is probably the first thing to start with.
> 
> Do you see a problem of using the regular place, i.e. the openvasrc
> file, for the proper scope?

Basically openvasrc is a good choice.
However, note that there are many of them, for tasks, scopes etc.

So, we have to think about whether the filter rules are global
or per-task or per-scope.
I tend to say global, because if there is a false-positive for a system,
you won't want to see it in any of the reports.

> We only need script_id + host + new priority.

we need port as well.

> Having this information 
> in the scope configuration gives us the benefit of having different
> scopes for the same task where the user is able to specify priorities
> differently.

hm, on the other hand you always need to copy a filter rules set
from one scope to another, possibly leading to inconsistencies in case
you edit rules in various scopes.
I think we (yet) do not gain much benefit from scope-wise rule sets.
What do others think?

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  Fri Nov 28 09:23:19 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 28 Nov 2008 09:23:19 +0100
Subject: [Openvas-devel] Voting on Change Request #21: Improved sorting
	of vulnerabilities
In-Reply-To: <200811271058.28709.felix.wolfsteller@intevation.de>
References: <20081126193208.GA23449@finlandia.home.infodrom.org>
	<20081127094325.GZ12602@finlandia.home.infodrom.org>
	<200811271058.28709.felix.wolfsteller@intevation.de>
Message-ID: <200811280923.26031.jan-oliver.wagner@intevation.de>

On Donnerstag, 27. November 2008, Felix Wolfsteller wrote:
> Anyway I vote +1.

Also vote +1.

Though I do not understand the last sentence in "Design and Implementation".
Are you saying the current counting is incorrect?
Should the only change be a adjustement in the widget?

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  Fri Nov 28 09:26:19 2008
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Fri, 28 Nov 2008 09:26:19 +0100
Subject: [Openvas-devel] Consistent text phrases in reports
In-Reply-To: <20081127143720.GA2829@finlandia.home.infodrom.org>
References: <20081127143720.GA2829@finlandia.home.infodrom.org>
Message-ID: <200811280926.21095.jan-oliver.wagner@intevation.de>

On Donnerstag, 27. November 2008, Joey Schulze wrote:
> I've noticed that texts in the reports are not always consistent.
> 
> For example in the HTML output the "Analysis of Host" contains for
> each port:
> 
>  . Security hole found
>  . Security warning(s) found
>  . Security notes found
> 
> Wouldn't it be better if these texts would either be
> 
>  a) all singular,
>  b) all singular + "(s)", or
>  c) all plural
> 
> instead of mixing all three of them?  These are static texts in
> nessus/html_output.c.

you are right. Guess b) would do best as a quick improvement.

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  Fri Nov 28 09:47:05 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Fri, 28 Nov 2008 09:47:05 +0100
Subject: [Openvas-devel] Voting on Change Request #18
In-Reply-To: <20081127143148.GD18591@intevation.de>
References: <20081117155314.GE12602@finlandia.home.infodrom.org>
	<20081127141704.GA32071@finlandia.home.infodrom.org>
	<20081127143148.GD18591@intevation.de>
Message-ID: <200811280947.05278.felix.wolfsteller@intevation.de>

> > You're the only one who has voted on this issue.  What to do now?
>
> Well, it's a positive result, so I'd say the CR is accepted. FWIW, I'd
> like to vote +1 as well. I thought I voted already, but that seems to
> have been another CR ... sorry for that.
> Michael
I shadow Michael, thought I voted already.
+1

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

From felix.wolfsteller at intevation.de  Fri Nov 28 10:02:21 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Fri, 28 Nov 2008 10:02:21 +0100
Subject: [Openvas-devel] Certificate error after scanning a host
In-Reply-To: <20081127202259.GE12602@finlandia.home.infodrom.org>
References: <20081127202259.GE12602@finlandia.home.infodrom.org>
Message-ID: <200811281002.21366.felix.wolfsteller@intevation.de>

> for some days I see "report_save() couldn't save the certificate
> information" after a scan.  This change is caused by the need to store the
> certificate and the possibility to display certificate information.
>
> However, context->signer_fp_certificates == NULL is considered an error
> and thus routines fail, resulting in this error message.
>
> The problem is that (a) signer_fp_certificates is NULL and (b) that
> openvas_certificate_file_write is called unconditionally in report.c
> (report_save).
>
> The attached patch fixes this.  Please let me know if I should commit it.

Thanks for pointing that out. Does it happen with the graphical client? 
Commit the patch, I might touch error handling afterwards.
cheers
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 joey at infodrom.org  Fri Nov 28 10:10:57 2008
From: joey at infodrom.org (Joey Schulze)
Date: Fri, 28 Nov 2008 10:10:57 +0100
Subject: [Openvas-devel] Certificate error after scanning a host
In-Reply-To: <200811281002.21366.felix.wolfsteller@intevation.de>
References: <20081127202259.GE12602@finlandia.home.infodrom.org>
	<200811281002.21366.felix.wolfsteller@intevation.de>
Message-ID: <20081128091057.GJ12602@finlandia.home.infodrom.org>

Felix Wolfsteller wrote:
> > for some days I see "report_save() couldn't save the certificate
> > information" after a scan.  This change is caused by the need to store the
> > certificate and the possibility to display certificate information.
> >
> > However, context->signer_fp_certificates == NULL is considered an error
> > and thus routines fail, resulting in this error message.
> >
> > The problem is that (a) signer_fp_certificates is NULL and (b) that
> > openvas_certificate_file_write is called unconditionally in report.c
> > (report_save).
> >
> > The attached patch fixes this.  Please let me know if I should commit it.
> 
> Thanks for pointing that out. Does it happen with the graphical client? 

Yes.

> Commit the patch, I might touch error handling afterwards.

Done.

Regards,

	Joey

-- 
If you come from outside of Finland, you live in wrong country.
	-- motd of irc.funet.fi

Please always Cc to me when replying to me on the lists.

From felix.wolfsteller at intevation.de  Fri Nov 28 10:47:40 2008
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Fri, 28 Nov 2008 10:47:40 +0100
Subject: [Openvas-devel] Print signature and trust level information
In-Reply-To: <20081127172111.GA20889@finlandia.home.infodrom.org>
References: <20081127172111.GA20889@finlandia.home.infodrom.org>
Message-ID: <200811281047.40957.felix.wolfsteller@intevation.de>

Yes it should. I do not want to touch the nbe specs, though.
At the moment I understand PDF reports to be the most used ones.
What I see (and you noted and corrected a bit already) is that report 
generation is a bit messy. Where at the moment (non-nbe) reports are 
generated using the NBE+support files, I think in a future change request one 
has to think about a proper "source" format for the reports (and say goodby 
to nbe). What pops to my mind are databases and xml.

felix


On Thursday 27 November 2008 18:21:11 Joey Schulze wrote:
> Felix,
>
> I saw this note:
> |  * nessus/pdf_output.c : Added printing of signature and trust level
> |  information.
>
> Shouldn't this information be added to HTML output, XML output, NBE
> output and ASCII output as well?
>
> Regards,
>
> 	Joey


-- 
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 joey at infodrom.org  Fri Nov 28 11:02:18 2008
From: joey at infodrom.org (Joey Schulze)
Date: Fri, 28 Nov 2008 11:02:18 +0100
Subject: [Openvas-devel] Print signature and trust level information
In-Reply-To: <200811281047.40957.felix.wolfsteller@intevation.de>
References: <20081127172111.GA20889@finlandia.home.infodrom.org>
	<200811281047.40957.felix.wolfsteller@intevation.de>
Message-ID: <20081128100218.GK12602@finlandia.home.infodrom.org>

Felix Wolfsteller wrote:
> Yes it should. I do not want to touch the nbe specs, though.
> At the moment I understand PDF reports to be the most used ones.

Then it's more important for us to keep the generated reports consistant,
imho.  Otherwise the other reports will eventually become totally useless.

> What I see (and you noted and corrected a bit already) is that report 
> generation is a bit messy. Where at the moment (non-nbe) reports are 

Oh yes...

> generated using the NBE+support files, I think in a future change request one 
> has to think about a proper "source" format for the reports (and say goodby 
> to nbe). What pops to my mind are databases and xml.

I thought about a template system.  I don't know one in C, though.

Regards,

	Joey

-- 
If you come from outside of Finland, you live in wrong country.
	-- motd of irc.funet.fi

Please always Cc to me when replying to me on the lists.

From sgros.ml at gmail.com  Fri Nov 28 15:13:52 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Fri, 28 Nov 2008 15:13:52 +0100
Subject: [Openvas-devel] Change Request #19: discussion open
In-Reply-To: <200811270940.27063.felix.wolfsteller@intevation.de>
References: <200811191055.45667.felix.wolfsteller@intevation.de>
	<200811270940.27063.felix.wolfsteller@intevation.de>
Message-ID: <4d7b043c0811280613x2cc123a2je887485fa0a46fb6@mail.gmail.com>

On Thu, Nov 27, 2008 at 9:40 AM, Felix Wolfsteller
<felix.wolfsteller at intevation.de> wrote:
> Okay, to refuel the process, I summarize what was said about CR #19
> ( http://www.openvas.org/openvas-cr-19.html ).
> I hope that I did not misunderstood or forgot any comment - correct me if i am
> wrong.
>
> 1) Documentation/ Doxygen
> Comment from Michael (likes it) and Jan (would like to have it mandatory). No
> disagreement about the need of a documentation. Stepjan proposed to use LXN
> some time in the future.
>
> -> interpretation: pretty much agreed on initial proposal regarding doxygen
> and the associated comment style.
>
> 2) Coding Style
> * Existing guidelines:
> Stjepan and Jan proposed to look at existing guidelines (other big projects/
> Kernel/ GNU).
> * Changing style in existing files:
> Changing code format in "old" files is debated. Joey notes that
> changing the style only "when substantial changes are made" would imply
> commits that change style _and_ content, which is to be disliked as the
> changes are hidden and difficult to detect.
> * Prettifiers:
> Usage of prettifier- tools is debated. Tendency to advocate usage of a tool
> only for new files.
> * Tabs/spaces:
> Whether to use tabs or spaces seems to be a hot topic.
> tim, vlatko and stjepan would prefer tabs. The pro- arguments so far are that
> it is easier to type and that editors can be configured to display one '\t'
> as n spaces.
> jan-oliver favours spaces and argues that as tabs and spaces are often mixed
> and various numbers for spaces are used for one tab, only the use of spaces
> works in practice, and that editors can be configured to insert n spaces per
> tab-key press.
>
> -> interpretation: if and how old code shall be changed might be decided in
> another change request.  No discussion about the proposed example file, but
> generally a wish to use existing solutions.
> Argumentation stronger for spaces, however the majority would like to use
> spaces.
>
> I would like to have a final state of the Change Request soon, so please set
> by the space/tab conflict and add thoughts about the proposed example file or
> references to any guideline that you enjoyed most.


Additional thought about tabs versus spaces. It's easy to see where
are tabs, and where are the spaces in a file, just change rendering of
tabs, i.e. in vi

:set ts=4

:set ts=8

in both cases indentation should be preserved. If it's not, it will be
very obvious where... I use this to check if tabs were used in the
code and to eliminate all the spaces. Obviously, this can also be used
to check the other way around, but personally, I'm more fond of tabs.

And additional thought about number of columns. I think it's good
practice to limit maximum number of characters per line because
otherwise, the person with biggest monitor and/or highest resolution wins.

Stjepan

P.S. I mistakenly (again!) pressed reply instead of 'reply all' so I'm
resending this mail with small clarifications added.

From michael.wiegand at intevation.de  Fri Nov 28 16:23:16 2008
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Fri, 28 Nov 2008 16:23:16 +0100
Subject: [Openvas-devel] CR #22: script_tag command - Call For Votes
Message-ID: <20081128152316.GF4017@intevation.de>

Hello,

I've just uploaded another change request. This one proposes adding a
script_tag command to NASL which would help NVT writers to manage the
properties of their scripts in a more flexible way.

The change request is available at:
http://www.openvas.org/openvas-cr-22.html

I'd like to ask all of you to take a look at it (especially the NASL
developers) and to cast your vote.

Let me know if you have any suggestions or questions. Thank you and have
a great weekend!

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