From felix.wolfsteller at intevation.de Mon Dec 1 09:46:41 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 1 Dec 2008 09:46:41 +0100 Subject: [Openvas-devel] Change Request #19: discussion open In-Reply-To: <4d7b043c0811280613x2cc123a2je887485fa0a46fb6@mail.gmail.com> References: <200811191055.45667.felix.wolfsteller@intevation.de> <200811270940.27063.felix.wolfsteller@intevation.de> <4d7b043c0811280613x2cc123a2je887485fa0a46fb6@mail.gmail.com> Message-ID: <200812010946.41515.felix.wolfsteller@intevation.de> On Friday 28 November 2008 15:13:52 Stjepan Gros wrote: > 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. > And additional thougt 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. A colum maximum is mentioned in the proposed file. I think the quasi-standard of 80 chars should be used. Although imho it does not have to be followed at all costs. 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 bchandra at secpod.com Mon Dec 1 11:46:24 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 1 Dec 2008 16:16:24 +0530 Subject: [Openvas-devel] [Openvas-plugins] CR #22: script_tag command - Call For Votes In-Reply-To: <20081128152316.GF4017@intevation.de> References: <20081128152316.GF4017@intevation.de> Message-ID: <66444E821F9247CD8D07165BF30AD41B@bchandra> Vote +1 Chandra. -----Original Message----- From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Michael Wiegand Sent: Friday, November 28, 2008 8:53 PM To: OpenVAS Development List; OpenVAS Plugins List Subject: [Openvas-plugins] CR #22: script_tag command - Call For Votes 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 _______________________________________________ Openvas-plugins mailing list Openvas-plugins at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins From joey at infodrom.org Mon Dec 1 12:25:51 2008 From: joey at infodrom.org (Joey Schulze) Date: Mon, 1 Dec 2008 12:25:51 +0100 Subject: [Openvas-devel] Consistent text phrases in reports In-Reply-To: <200811280926.21095.jan-oliver.wagner@intevation.de> References: <20081127143720.GA2829@finlandia.home.infodrom.org> <200811280926.21095.jan-oliver.wagner@intevation.de> Message-ID: <20081201112551.GA18521@finlandia.home.infodrom.org> Jan-Oliver Wagner wrote: > > 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. Done. Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds Please always Cc to me when replying to me on the lists. From michael.wiegand at intevation.de Mon Dec 1 12:47:05 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 1 Dec 2008 12:47:05 +0100 Subject: [Openvas-devel] Planning openvas-plugins 1.0.5 release Message-ID: <20081201114705.GA20725@intevation.de> Hello, there has been quite an amount of changes to openvas-plugins since the release of 1.0.4 in October, including improvements in the build environment, 64-bit cleanliness, a large number of new NVTs and updated packaging for Debian. Because of this and to synchronize this package with the SVN ahead of the upcoming 2.0 release of OpenVAS, I'd like to release openvas-plugins 1.0.5 on Wednesday, December 3rd. Please contact me if you have any issues with this plan; if you are planning on packaging openvas-plugins for a distribution, please let me know if there is anything that should be done before the release to make the inclusion of OpenVAS into the distribution of your choice easier. Thank you! Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Mon Dec 1 15:55:46 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 1 Dec 2008 15:55:46 +0100 Subject: [Openvas-devel] Planning OpenVAS 2.0-rc1 Message-ID: <20081201145546.GB20725@intevation.de> Hello, since feedback for the two beta releases has been positive and reported issues have been fixed, I'd like to end the beta phase and release the first release candidate for OpenVAS 2.0. Almost all feature suggested for 2.0 have found their way into the code in the last few weeks or will be added in the next few days. I think it would be a nice conclusion for 2008 if we could release 2.0 this month, so I would like to schedule the releas of OpenVAS 2.0-rc1 for Friday, December 5th. If there are no major issues with this release candidate, it will most likely become the final release, so please do test this version. A special note to the translators: Now is a good time update or complete the translation of OpenVAS-Client into your language. The German translation is almost done, but we still need updated translations for: - Swedish - Hebrew - French - Croatian - Spanish As always, if you see problems with this release schedule, do not hesitate to contact me. Thanks to all contributors for your great work on OpenVAS 2.0-beta! 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 Mon Dec 1 17:03:04 2008 From: joey at infodrom.org (Joey Schulze) Date: Mon, 1 Dec 2008 17:03:04 +0100 Subject: [Openvas-devel] Voting on Change Request #18 In-Reply-To: <200811280917.07503.jan-oliver.wagner@intevation.de> References: <20081117155314.GE12602@finlandia.home.infodrom.org> <200811241237.57830.jan-oliver.wagner@intevation.de> <20081127141704.GA32071@finlandia.home.infodrom.org> <200811280917.07503.jan-oliver.wagner@intevation.de> Message-ID: <20081201160304.GB18521@finlandia.home.infodrom.org> Jan-Oliver Wagner wrote: > > 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. So, a NASL script can operate on different ports? A NASL script can already emit security notes with different priority (hole plus note for example). Regards, Joey -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds Please always Cc to me when replying to me on the lists. From michael.wiegand at intevation.de Tue Dec 2 09:02:14 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 2 Dec 2008 09:02:14 +0100 Subject: [Openvas-devel] Voting on Change Request #18 In-Reply-To: <20081201160304.GB18521@finlandia.home.infodrom.org> References: <20081117155314.GE12602@finlandia.home.infodrom.org> <200811241237.57830.jan-oliver.wagner@intevation.de> <20081127141704.GA32071@finlandia.home.infodrom.org> <200811280917.07503.jan-oliver.wagner@intevation.de> <20081201160304.GB18521@finlandia.home.infodrom.org> Message-ID: <20081202080214.GA17158@intevation.de> * Martin Schulze [ 1. Dec 2008]: > So, a NASL script can operate on different ports? Yes. By its nature, a script is not limited to a specific port. It is simply launched and can send an arbitrary number of messages of different types/priorities to the client. The NASL command is something like this: security_hole(port, msg) where "port" signifies, well, the port and msg stand for the message regarding the issue the script thinks it has found on the port. A port number of 0 signifies that this issue does not affect a particular port, but rather the target system as a whole. But while a NASL script could theoretically contain an arbitrary number of message commands, this is generally considered bad practice. A NASL script should really be as contained and atomic as possible and should try to evaluate only a single vulnerability. > A NASL script can already emit security notes with different priority > (hole plus note for example). Yes. This does happen more often than multiple ports and will increase in the future with the addition of the log_message and debug_message command. A likely case would a vulnerability test which report a security issue and at the same time provides debug information about the script run. 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 bchandra at secpod.com Tue Dec 2 15:59:52 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Tue, 2 Dec 2008 20:29:52 +0530 Subject: [Openvas-devel] Change Request #23: Standardization of Script families Message-ID: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> Hello, I have submitted a new change request towards standardizing the keywords being used in script_family for NVT's. I have listed the currently used family names and also suggesting few changes to the current list. I would like your feedback on the listed changes and also any modification or addition required to the list. The CR is available at, Thanks, Chandra. From lists at securityspace.com Tue Dec 2 17:43:36 2008 From: lists at securityspace.com (Thomas Reinke) Date: Tue, 02 Dec 2008 11:43:36 -0500 Subject: [Openvas-devel] Change Request #23: Standardization of Script families In-Reply-To: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> References: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> Message-ID: <493565B8.2020607@securityspace.com> Hi, Couple of things stand out: 1. If introducing the more general "Malware" category, existing "Backdoors" scripts probably could be discontinued in favour of the malware category. 2. If you are going to add category "Buffer overflow", you may as well remove category "Gain shell remotely." 3. If you are going to add "Priviledge escalation", you may as well remove "Gaining root remotely". 4. CGI abuses with CGI abuses : XSS - collapsing and renaming. to Web application abuse. I see a couple issues: a) Consistency of use b) Whether to have two categories (independent of consistency issue) c) Renaming. a) We absolutely should fix up (if not collapsing) (+1) b) Keeping/collapsing two categories into one (neutral) c) Renaming, to "Web application abuses" is still not going to cover things adequately, iirc, because a number of the scripts in this category are not web application abuses, but are in fact web server vulnerabilities. Not sure thus that the name change is a good one. (-1) 5. As a pre-emptive strike, you may want to allow new families that cover new OS/distributions without a change request process. Thomas Chandrashekhar B wrote: > Hello, > > I have submitted a new change request towards standardizing the keywords > being used in script_family for NVT's. I have listed the currently used > family names and also suggesting few changes to the current list. I would > like your feedback on the listed changes and also any modification or > addition required to the list. The CR is available at, > > > > Thanks, > Chandra. > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel > From bchandra at secpod.com Wed Dec 3 07:19:58 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 3 Dec 2008 11:49:58 +0530 Subject: [Openvas-devel] Change Request #23: Standardization of Script families In-Reply-To: <493565B8.2020607@securityspace.com> References: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> <493565B8.2020607@securityspace.com> Message-ID: Thomas, Thanks for the feedback. Please see my inline comments, -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Thomas Reinke Sent: Tuesday, December 02, 2008 10:14 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] Change Request #23: Standardization of Script families > Hi, > Couple of things stand out: > 1. If introducing the more general "Malware" category, existing > "Backdoors" scripts probably could be discontinued in favour > of the malware category. Agreed, will update the CR. If all backdoors are considered malware, we can do that :) > 2. If you are going to add category "Buffer overflow", you > may as well remove category "Gain shell remotely." Gaining a shell remotely need not be for buffer overflow reasons and hence kept as it is. > 3. If you are going to add "Priviledge escalation", you may > as well remove "Gaining root remotely". Will update the CR. > 4. CGI abuses with CGI abuses : XSS - collapsing and renaming. > to Web application abuse. > I see a couple issues: > a) Consistency of use > b) Whether to have two categories (independent of consistency > issue) > c) Renaming. > a) We absolutely should fix up (if not collapsing) (+1) > b) Keeping/collapsing two categories into one (neutral) > c) Renaming, to "Web application abuses" is still not going > to cover things adequately, iirc, because a number of the scripts > in this category are not web application abuses, but are in fact > web server vulnerabilities. Not sure thus that the name change > is a good one. (-1) We'll have to look at the existing scripts and move them to appropriate family. There's a category for web servers, we can consider moving to that. > 5. As a pre-emptive strike, you may want to allow new families > that cover new OS/distributions without a change request process. Documentation of the new family is necessary. If one can update this page and sends a mail, should be enough. Chandrashekhar B wrote: >> Hello, >> >> I have submitted a new change request towards standardizing the keywords >> being used in script_family for NVT's. I have listed the currently used >> family names and also suggesting few changes to the current list. I would >> like your feedback on the listed changes and also any modification or >> addition required to the list. The CR is available at, >> >> >> >> Thanks, >> Chandra. >> Thanks, Chandra. From felix.wolfsteller at intevation.de Wed Dec 3 10:33:47 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 3 Dec 2008 10:33:47 +0100 Subject: [Openvas-devel] CR #20: ssh credentials - Call for votes Message-ID: <200812031033.47489.felix.wolfsteller@intevation.de> Change Request #20 is open for votes now. The idea in a nutshell: openvas-client should allow ssh login information a) to be managed more easily (graphically) b) to be selected on a per-host basis to simplifiy the process for local checks / SLAD. Greater detail at http://www.openvas.org/openvas-cr-20.html . Feel free to comment and vote. felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Wed Dec 3 11:00:02 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 3 Dec 2008 11:00:02 +0100 Subject: [Openvas-devel] CR #22: script_tag command - Call For Votes In-Reply-To: <20081128152316.GF4017@intevation.de> References: <20081128152316.GF4017@intevation.de> Message-ID: <200812031100.05251.jan-oliver.wagner@intevation.de> On Freitag, 28. November 2008, Michael Wiegand wrote: > 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! +1 -- 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 michael.wiegand at intevation.de Wed Dec 3 11:01:12 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 3 Dec 2008 11:01:12 +0100 Subject: [Openvas-devel] CR #20: ssh credentials - Call for votes In-Reply-To: <200812031033.47489.felix.wolfsteller@intevation.de> References: <200812031033.47489.felix.wolfsteller@intevation.de> Message-ID: <20081203100112.GB27198@intevation.de> * Felix Wolfsteller [ 3. Dec 2008]: > Feel free to comment and vote. I vote +1. 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 Dec 3 11:07:08 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 3 Dec 2008 11:07:08 +0100 Subject: [Openvas-devel] Change Request #23: Standardization of Script families In-Reply-To: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> References: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> Message-ID: <200812031107.10313.jan-oliver.wagner@intevation.de> On Dienstag, 2. Dezember 2008, Chandrashekhar B wrote: > I have submitted a new change request towards standardizing the keywords > being used in script_family for NVT's. I have listed the currently used > family names and also suggesting few changes to the current list. I would > like your feedback on the listed changes and also any modification or > addition required to the list. The CR is available at, > good to address this issue now ... I noticed: "Credentials" appears in changes. But in fact, it should be OK. Is there a special script that looks wrongly assigned this group? 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 Wed Dec 3 11:35:57 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 3 Dec 2008 11:35:57 +0100 Subject: [Openvas-devel] CR #20: ssh credentials - Call for votes In-Reply-To: <200812031033.47489.felix.wolfsteller@intevation.de> References: <200812031033.47489.felix.wolfsteller@intevation.de> Message-ID: <200812031136.00329.jan-oliver.wagner@intevation.de> On Mittwoch, 3. Dezember 2008, Felix Wolfsteller wrote: > Change Request #20 is open for votes now. > > The idea in a nutshell: > openvas-client should allow ssh login information > a) to be managed more easily (graphically) > b) to be selected on a per-host basis > to simplifiy the process for local checks / SLAD. > > Greater detail at http://www.openvas.org/openvas-cr-20.html . > > Feel free to comment and vote. in principle I vote +1 on this very helpful feature. The iterative approach is good. Note that the first step should not end up offering all available key from ~/.ssh We need a separate (OpenVAS-specific) store of these data from the beginning. The second step should then be to have a GUI to manage this store. If OpenVAS-Client would directly access ~/.ssh one could accidently send important private keys. What also comes to my mind: We need to fix up the problem that ssh_funcs needs the public key to work properly. In fact, the public key is not necessary and thus should not be part of the sshcredentials. Next: Are we going to support both uname+pw and uname+key+pw? Or should we drop one of them? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Wed Dec 3 15:11:52 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 3 Dec 2008 19:41:52 +0530 Subject: [Openvas-devel] CR #20: ssh credentials - Call for votes In-Reply-To: <200812031033.47489.felix.wolfsteller@intevation.de> References: <200812031033.47489.felix.wolfsteller@intevation.de> Message-ID: -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Felix Wolfsteller Sent: Wednesday, December 03, 2008 3:04 PM To: openvas-devel at wald.intevation.org Subject: [Openvas-devel] CR #20: ssh credentials - Call for votes > Change Request #20 is open for votes now. > The idea in a nutshell: > openvas-client should allow ssh login information > a) to be managed more easily (graphically) > b) to be selected on a per-host basis > to simplifiy the process for local checks / SLAD. > Greater detail at http://www.openvas.org/openvas-cr-20.html . > Feel free to comment and vote. +1 From bchandra at secpod.com Wed Dec 3 15:13:58 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 3 Dec 2008 19:43:58 +0530 Subject: [Openvas-devel] Change Request #23: Standardization of Scriptfamilies In-Reply-To: <200812031107.10313.jan-oliver.wagner@intevation.de> References: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> <200812031107.10313.jan-oliver.wagner@intevation.de> Message-ID: -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Wednesday, December 03, 2008 3:37 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] Change Request #23: Standardization of Scriptfamilies On Dienstag, 2. Dezember 2008, Chandrashekhar B wrote: >> I have submitted a new change request towards standardizing the keywords >> being used in script_family for NVT's. I have listed the currently used >> family names and also suggesting few changes to the current list. I would >> like your feedback on the listed changes and also any modification or >> addition required to the list. The CR is available at, >> > good to address this issue now ... > I noticed: "Credentials" appears in changes. But in fact, it should be OK. > Is there a special script that looks wrongly assigned this group? There's a family called "Settings" for all preferences settings, thought will move to that. Chandra. From jan-oliver.wagner at intevation.de Thu Dec 4 08:52:18 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 4 Dec 2008 08:52:18 +0100 Subject: [Openvas-devel] Change Request #23: Standardization of Scriptfamilies In-Reply-To: References: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> <200812031107.10313.jan-oliver.wagner@intevation.de> Message-ID: <200812040852.20764.jan-oliver.wagner@intevation.de> On Mittwoch, 3. Dezember 2008, Chandrashekhar B wrote: > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver > Wagner > Sent: Wednesday, December 03, 2008 3:37 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] Change Request #23: Standardization of > Scriptfamilies > > On Dienstag, 2. Dezember 2008, Chandrashekhar B wrote: > >> I have submitted a new change request towards standardizing the keywords > >> being used in script_family for NVT's. I have listed the currently used > >> family names and also suggesting few changes to the current list. I would > >> like your feedback on the listed changes and also any modification or > >> addition required to the list. The CR is available at, > >> > > > good to address this issue now ... > > > I noticed: "Credentials" appears in changes. But in fact, it should be OK. > > Is there a special script that looks wrongly assigned this group? > > There's a family called "Settings" for all preferences settings, thought > will move to that. The family "Credentials" is treated in a special way in OpenVAS-Client. See also here: http://www.openvas.org/openvas-cr-8.html Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Thu Dec 4 09:00:11 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 4 Dec 2008 13:30:11 +0530 Subject: [Openvas-devel] Change Request #23: Standardization ofScriptfamilies In-Reply-To: <200812040852.20764.jan-oliver.wagner@intevation.de> References: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra><200812031107.10313.jan-oliver.wagner@intevation.de> <200812040852.20764.jan-oliver.wagner@intevation.de> Message-ID: -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Thursday, December 04, 2008 1:22 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] Change Request #23: Standardization ofScriptfamilies On Mittwoch, 3. Dezember 2008, Chandrashekhar B wrote: > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver > Wagner > Sent: Wednesday, December 03, 2008 3:37 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] Change Request #23: Standardization of > Scriptfamilies > > On Dienstag, 2. Dezember 2008, Chandrashekhar B wrote: > >> I have submitted a new change request towards standardizing the keywords > >> being used in script_family for NVT's. I have listed the currently used > >> family names and also suggesting few changes to the current list. I would > >> like your feedback on the listed changes and also any modification or > >> addition required to the list. The CR is available at, > >> > > > good to address this issue now ... > > > I noticed: "Credentials" appears in changes. But in fact, it should be OK. > > Is there a special script that looks wrongly assigned this group? >> >> There's a family called "Settings" for all preferences settings, thought >> will move to that. > The family "Credentials" is treated in a special way in OpenVAS-Client. > See also here: http://www.openvas.org/openvas-cr-8.html Ok, will update the CR. Chandra. From felix.wolfsteller at intevation.de Thu Dec 4 09:08:22 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Thu, 4 Dec 2008 09:08:22 +0100 Subject: [Openvas-devel] Change Request #23: Standardization of Script families In-Reply-To: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> References: <7820BE3F3F5F4029AEE5680C8FC1603C@bchandra> Message-ID: <200812040908.22688.felix.wolfsteller@intevation.de> I vote +1 on some standard, although the pure family mechanism to allow easy and fast selection of nvt subsets in the client is imho not sufficient (e.g. no clear semantics of families, and because just one unique family per nvt is possible). Also I would like to note the obvious need to document the "accepted families" on the web page and in the compendium (so far not included in CR text). On Tuesday 02 December 2008 15:59:52 Chandrashekhar B wrote: > Hello, > > I have submitted a new change request towards standardizing the keywords > being used in script_family for NVT's. I have listed the currently used > family names and also suggesting few changes to the current list. I would > like your feedback on the listed changes and also any modification or > addition required to the list. The CR is available at, > > > > Thanks, > Chandra. > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel -- 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 Sat Dec 6 20:52:45 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Sat, 6 Dec 2008 20:52:45 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories Message-ID: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> Hi all, with much help/guidelince from Michael Wiegand I wrote change request towards reorganizing NVTs. There are two goals with this change. One is to be LSB/FHS compliant, while the other is to enable new features by NVT reorganization. The feature specifically mentioned is speeding up load time of openvasd and possiblity to dinamically load (or not to load) plugins. I would like your feedback on the listed changes and also any modification or addition required to the list. The CR is available at, Thanks, Stjepan From michael.wiegand at intevation.de Mon Dec 8 09:02:02 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 8 Dec 2008 09:02:02 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> Message-ID: <20081208080202.GB11603@intevation.de> * Stjepan Gros [ 6. Dec 2008]: > with much help/guidelince from Michael Wiegand I wrote change request > towards reorganizing NVTs. There are two goals with this change. One > is to be LSB/FHS compliant, while the other is to enable new features > by NVT reorganization. The feature specifically mentioned is speeding > up load time of openvasd and possiblity to dinamically load (or not to > load) plugins. I would like your feedback on the listed changes and > also any modification or addition required to the list. It probably won't surprise you that I vote +1 on this one. :) I think there are a few more issues we should discuss: - How will the server admin be able to switch on/off individual subdirectories? Should this happen in the server configuration file? - Should the selection be communicated to the client? And if so, in which way? - You suggested "grammar to include new directives" for the NASL subsystem, is this necessary? Should NVTs be aware that they are in a different subdirectory? Stjepan, maybe you could post your thoughts on these issues. Comments from others are welcome too of course. :) Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Mon Dec 8 16:15:19 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 8 Dec 2008 16:15:19 +0100 Subject: [Openvas-devel] [Openvas-distro] Feedback for RC1 In-Reply-To: References: Message-ID: <20081208151519.GD11603@intevation.de> * Stephan Kleine [ 6. Dec 2008]: > Hello. > > In RC1 the -g flag is correctly added to the compilation flags in > openvas-client. Thanks for this. > > Openvas-libraries still has the same flaws: the library files are > still incorrectly named without explicitly calling "libtoolize > --force" and using that lets the build fail on openSUSE 11.1 & Factory > (without that it builds but the files are incorrectly named). > > Openvas-libnasl still doesn't build with "--disable-static" as > configure option (same error as on beta2). > > IMHO a release candidate not only consists of functionality but should > also imply that the code can be build without any stunts in the .spec > files, which is currently not the case. Therefore it would be great if > you could fix the above for RC2. Stephan, thank you for your feedback! I agree that this situation is unfortunate. I have looked into this issue and I think this is mainly caused by the way the OpenVAS build system is set up at the moment. As far as I understand your mail, these issues do not break functionality, but rather force more or less ugly workarounds, correct? Unfortunately, I have neither the time nor the experience right now to propose a good solution to this problem, so I really would appreciate any patches or suggestions as to how this issue could be solved. I'm crossposting this to -devel, there are probably some folks more knowledgeable regarding the build process than myself. 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 Dec 8 21:02:00 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Mon, 8 Dec 2008 21:02:00 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <20081208080202.GB11603@intevation.de> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <20081208080202.GB11603@intevation.de> Message-ID: <4d7b043c0812081202s779ce94j942e60ba7c0edc04@mail.gmail.com> On Mon, Dec 8, 2008 at 9:02 AM, Michael Wiegand wrote: > * Stjepan Gros [ 6. Dec 2008]: >> with much help/guidelince from Michael Wiegand I wrote change request >> towards reorganizing NVTs. There are two goals with this change. One >> is to be LSB/FHS compliant, while the other is to enable new features >> by NVT reorganization. The feature specifically mentioned is speeding >> up load time of openvasd and possiblity to dinamically load (or not to >> load) plugins. I would like your feedback on the listed changes and >> also any modification or addition required to the list. > > It probably won't surprise you that I vote +1 on this one. :) > > I think there are a few more issues we should discuss: > > - How will the server admin be able to switch on/off individual > subdirectories? Should this happen in the server configuration file? There are few possibilities, from the simplest to the most complex: 1. The simplest way is to restart openvasd. that way it is possible to comment out specific directories in the configuration file. 2. Using SIGHUP to reload configuration file, the same as 1 but more dynamic 3. Via some IPC mechanism that will allow commands to be sent to openvasd and thus, this is fully dynamic scenario A variant of 1 and 2 is to modify openvasd in such a way to load only plugins that have, e.g. executable bit set. it's easy then to disable specific plugin by chmod-ing it. For a start I would suggest 1. Otherwise we could set too ambitious goals which have equally high probability of failing. :) > - Should the selection be communicated to the client? And if so, in > which way? This requires knowledge and modification of the communication protocol between the two, which I don't have. So I would suggest also that in the initial scenario this part is not changed, i.e. client gets a current list of plugins when it connects to the server. In the long term, the answer to this question depends on the uses cases of openvasd+openvasclient. I don't have enough experience to make judgements here. This also influences the previous item about switching on/off specific subdirectories. Maybe success/fail stories would be useful? > - You suggested "grammar to include new directives" for the NASL > subsystem, is this necessary? Should NVTs be aware that they are in a > different subdirectory? No, what I meant was only to introduce three configuration directives to openvasd.conf that will allow administrator to specify where plugins are, where global includes are and where to place caches. I believe there is no point in making NVTs aware of their physical placement. Stjepan From jan-oliver.wagner at intevation.de Tue Dec 9 09:40:17 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 9 Dec 2008 09:40:17 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> Message-ID: <200812090940.20357.jan-oliver.wagner@intevation.de> Hello Stjepan, On Samstag, 6. Dezember 2008, Stjepan Gros wrote: > with much help/guidelince from Michael Wiegand I wrote change request > towards reorganizing NVTs. There are two goals with this change. One > is to be LSB/FHS compliant, while the other is to enable new features > by NVT reorganization. The feature specifically mentioned is speeding > up load time of openvasd and possiblity to dinamically load (or not to > load) plugins. I would like your feedback on the listed changes and > also any modification or addition required to the list. The CR is > available at, > > first thanks for starting to work on this very much desired feature! I have some comments and would be glad if you could consider them for an update of CR#24: * note that there are still some C-plugins (*.nes) in the plugins directory that are platform-dependent. We are working on resolving them, but it will take some time. So, the directory reorganization should consider this in some way. * if you are saying that according to FHS we want the NVTs directory not writable, does this conflict with the aspect that we will have to write new NVTs during a NVT Feed Sync? * last paragraph of rationale: I think this aspect is too ambitious for the moment. Also, we have already a mechanism to switch on/off groups of NVTs: via the detached signatures and trusted signatures. * include_dir: this should allow for a directory structure as well. If you look at http://www.openvas.org/openvas-oids.html there is a special OID space for "Lib" aspired. So, if we associated "iso.org.dod.internet.private.enterprise.OpenVAS" with a special directory, then we have "NVT/lib" as a natural subdirectory where to place inc's and possibly some subdirectories. Another aspect is the search path: will .inc files first searched for in the same directory as the .nasl is? * Design: Yes, I also think that the OID scheme is the best choice to base the dirctory structure on. I propose a careful step-by-step implementation. For example, moving the caching into a separate directory would be a first nice step. There, it could already be realized to have a directory strucure based on the OIDs of the NVTs. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Tue Dec 9 09:44:00 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 9 Dec 2008 09:44:00 +0100 Subject: [Openvas-devel] [Openvas-discuss] Planning OpenVAS Developer Conference #2 (OpenVAS DevCon2) In-Reply-To: <200812041704.13860.jan-oliver.wagner@intevation.de> References: <200812041704.13860.jan-oliver.wagner@intevation.de> Message-ID: <200812090944.02588.jan-oliver.wagner@intevation.de> Hi, I encourage you to send on-list comments :-) Important decisions that should be made during this developer meeting is: * OIDs: final layout, assignment procedure. * how to get rid of the opevas-plugins module (part of design for OpenVAS 3.0) All the best Jan On Donnerstag, 4. Dezember 2008, Jan-Oliver Wagner wrote: > I do see the growing need to meet in real life in order to > > * review the last 2 years of great development > * plan future features > * discuss designs > * discuss how to extend NVT coverage > * discuss professional services and how they relate to > OpenVAS project > * have a beer (or other beverages) with people we see > only rarely or see only as an email address. > > In summary, I'd like to derive a master plan for the next 1-2 years > from this meeting. > > I offer to hold the 2nd OpenVAS Developer Conference in > Osnabr?ck, Germany in the new offices of Intevation. > Potential dates are: > > June 11-14 2009 (Thursday-Sunday) > June 18-21 2009 (Thursday-Sunday) > July 9-12 2009 (Thursday-Sunday) > July 16-19 2009 (Thursday-Sunday) > > Please let me know what you think! > > Who would like to participate? > And already know the dates are OK for him/her? > > If we can gather at least a small group, then > I will prepare a agenda and start into detailed planning > to offer a nice and interesting stay. > > What I am uncertain: should we consider a Users' session prior > to the DevCon with Workshops or alike? Maybe someone wants > to hold a workshop. If we take a small fee we might finance > travel for some developers. > Opinions on this? -- 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 michael.wiegand at intevation.de Tue Dec 9 09:49:01 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 9 Dec 2008 09:49:01 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <4d7b043c0812081202s779ce94j942e60ba7c0edc04@mail.gmail.com> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <20081208080202.GB11603@intevation.de> <4d7b043c0812081202s779ce94j942e60ba7c0edc04@mail.gmail.com> Message-ID: <20081209084901.GB18801@intevation.de> * Stjepan Gros [ 8. Dec 2008]: > > - How will the server admin be able to switch on/off individual > > subdirectories? Should this happen in the server configuration file? > > 1. The simplest way is to restart openvasd. that way it is possible to > comment out specific directories in the configuration file. > 2. Using SIGHUP to reload configuration file, the same as 1 but more dynamic > 3. Via some IPC mechanism that will allow commands to be sent to > openvasd and thus, this is fully dynamic scenario > > A variant of 1 and 2 is to modify openvasd in such a way to load only > plugins that have, e.g. executable bit set. it's easy then to disable > specific plugin by chmod-ing it. > > For a start I would suggest 1. Otherwise we could set too ambitious > goals which have equally high probability of failing. :) I agree. Setting the directories in the config file is a good start and probably the most intuitive way for server admins. > > - Should the selection be communicated to the client? And if so, in > > which way? > > This requires knowledge and modification of the communication protocol > between the two, which I don't have. So I would suggest also that in > the initial scenario this part is not changed, i.e. client gets a > current list of plugins when it connects to the server. > > In the long term, the answer to this question depends on the uses > cases of openvasd+openvasclient. I don't have enough experience to > make judgements here. This also influences the previous item about > switching on/off specific subdirectories. Maybe success/fail stories > would be useful? Same here; what do the others think? I've talked about this with Felix, we think this would require considerable changes in the client as the client is very conservative regarding its own cache file and will probably get confused by disappearing and reappearing NVTs unless client-side caching is changed as well. > > - You suggested "grammar to include new directives" for the NASL > > subsystem, is this necessary? Should NVTs be aware that they are in a > > different subdirectory? > > No, what I meant was only to introduce three configuration directives > to openvasd.conf that will allow administrator to specify where > plugins are, where global includes are and where to place caches. I > believe there is no point in making NVTs aware of their physical > placement. I understand and agree. :) This should only need relatively minor adjustments afaict from reading openvas-server/openvasd/preferences.c. Any other questions or suggestions regarding Stjepans proposal? Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Tue Dec 9 10:44:10 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 9 Dec 2008 10:44:10 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <200812090940.20357.jan-oliver.wagner@intevation.de> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <200812090940.20357.jan-oliver.wagner@intevation.de> Message-ID: <20081209094410.GC18801@intevation.de> * Jan-Oliver Wagner [ 9. Dec 2008]: > * if you are saying that according to FHS we want the NVTs directory > not writable, does this conflict with the aspect that we will have to write > new NVTs during a NVT Feed Sync? I think the point is that this directory should be read-only from the -server perspective. The server itself has no business writing there, it is neither necessary nor desirable for the server to be able to modify NVTs. The Feed Sync and possibly the server admin should be the only ones who modify/create NVTs. While the files or the directory do not need to be read-only on a filesystem level, the server should not be able to do more than read from these directories. > * last paragraph of rationale: I think this aspect is too ambitious for the > moment. Also, we have already a mechanism to switch on/off groups of > NVTs: via the detached signatures and trusted signatures. Well, I guess I'm the one to blame for this paragraph. ;) I agree, this functionality will likely require deeper changes and would probably be a nice-to-have in the future, but is not necessary immediately. 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 Dec 9 18:16:59 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Tue, 9 Dec 2008 18:16:59 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <200812090940.20357.jan-oliver.wagner@intevation.de> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <200812090940.20357.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0812090916k1f178cc0s6a2dd11e4a35b64@mail.gmail.com> Hi, On Tue, Dec 9, 2008 at 9:40 AM, Jan-Oliver Wagner wrote: > Hello Stjepan, > > On Samstag, 6. Dezember 2008, Stjepan Gros wrote: >> with much help/guidelince from Michael Wiegand I wrote change request >> towards reorganizing NVTs. There are two goals with this change. One >> is to be LSB/FHS compliant, while the other is to enable new features >> by NVT reorganization. The feature specifically mentioned is speeding >> up load time of openvasd and possiblity to dinamically load (or not to >> load) plugins. I would like your feedback on the listed changes and >> also any modification or addition required to the list. The CR is >> available at, >> >> > > first thanks for starting to work on this very much desired feature! > > I have some comments and would be glad if you could consider > them for an update of CR#24: > > * note that there are still some C-plugins (*.nes) in the plugins > directory that are platform-dependent. > We are working on resolving them, but it will take some time. > So, the directory reorganization should consider this in some way. This is, as I understand it, short term state, and thus can be ignored because eventually they will be replaced with platform independent versions. Furthermore, what I'm proposing is to introduce appropriate infrastructure into openvas that will allow plugins to be reorganized but in the end, this infrastructure is (almost) independent from the chosen plugin organization. > * if you are saying that according to FHS we want the NVTs directory > not writable, does this conflict with the aspect that we will have to write > new NVTs during a NVT Feed Sync? Michael already answered this and it's what I meant. > * last paragraph of rationale: I think this aspect is too ambitious for the > moment. Also, we have already a mechanism to switch on/off groups of > NVTs: via the detached signatures and trusted signatures. > > * include_dir: this should allow for a directory structure as well. > If you look at http://www.openvas.org/openvas-oids.html > there is a special OID space for "Lib" aspired. > So, if we associated "iso.org.dod.internet.private.enterprise.OpenVAS" > with a special directory, then we have "NVT/lib" as a natural subdirectory where > to place inc's and possibly some subdirectories. The patch, as I wrote it, doesn't care about the exact organization. You could say: plugins_folder=/usr/local/share/openvas/plugins include_folder=/usr/local/share/openvas/plugins/nvt/lib and this would work. What wouldn't work (yet) is cache directory which has to be changed to store cached plugins to follow OIDs. the small problem could be when there is numerical OID without symbolic name. in that case openvas server can use numerical value as a name of directory, but, this can cause some confusion when symbolic name is introduced into the server and now there is numerical as well as symbolic directory. the best place to put numeric to symbolic mapping would be in configuration file, but it will take some time to be implemented and also exact configuration directives have to be defined. maybe i would leave this after the first version works. > Another aspect is the search path: will .inc files first searched for in the same > directory as the .nasl is? I don't have any special opinion about this, both cases are of the same implementation complexity. Maybe one pro for search of the same directory is that in that case include files could be overwritten with the local version. But in the end, I think it's better to ask plugin writers what they want/think about this issue. > * Design: Yes, I also think that the OID scheme is the best choice to base > the dirctory structure on. > > > I propose a careful step-by-step implementation. > For example, moving the caching into a separate directory would be a first nice step. > There, it could already be realized to have a directory strucure based on the OIDs of > the NVTs. This idea is fine with me. I could split patch so that only cache is changed. This could be first iteration. What is not implemented is storing plugins according to OID and to try to implement that part would be the second iteration. Stjepan From jan-oliver.wagner at intevation.de Tue Dec 9 22:39:44 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 9 Dec 2008 22:39:44 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <4d7b043c0812090916k1f178cc0s6a2dd11e4a35b64@mail.gmail.com> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <200812090940.20357.jan-oliver.wagner@intevation.de> <4d7b043c0812090916k1f178cc0s6a2dd11e4a35b64@mail.gmail.com> Message-ID: <200812092239.44901.jan-oliver.wagner@intevation.de> Hello Stjepan, On Tuesday 09 December 2008 18:16:59 Stjepan Gros wrote: > On Tue, Dec 9, 2008 at 9:40 AM, Jan-Oliver Wagner > > * note that there are still some C-plugins (*.nes) in the plugins > > directory that are platform-dependent. > > We are working on resolving them, but it will take some time. > > So, the directory reorganization should consider this in some way. > > This is, as I understand it, short term state, and thus can be ignored > because eventually they will be replaced with platform independent > versions. uh, well, depends on the definition of "short term" :-) In fact I 'd like to get rid of *.nes during 2009. > Furthermore, what I'm proposing is to introduce appropriate > infrastructure into openvas that will allow plugins to be reorganized > but in the end, this infrastructure is (almost) independent from the > chosen plugin organization. Indeed a good plan. > The patch, as I wrote it, doesn't care about the exact organization. > You could say: > > plugins_folder=/usr/local/share/openvas/plugins > include_folder=/usr/local/share/openvas/plugins/nvt/lib correct. > and this would work. What wouldn't work (yet) is cache directory which > has to be changed to store cached plugins to follow OIDs. > the small problem could be when there is numerical OID without > symbolic name. in that case openvas server can use numerical value as > a name of directory, but, this can cause some confusion when symbolic > name is introduced into the server and now there is numerical as well > as symbolic directory. the best place to put numeric to symbolic > mapping would be in configuration file, but it will take some time to > be implemented and also exact configuration directives have to be > defined. maybe i would leave this after the first version works. we could also have symbolic links to have both, the number and name representation. However, I don't think it is a really urgent problem. > > Another aspect is the search path: will .inc files first searched for in > > the same directory as the .nasl is? > > I don't have any special opinion about this, both cases are of the > same implementation complexity. Maybe one pro for search of the same > directory is that in that case include files could be overwritten with > the local version. But in the end, I think it's better to ask plugin > writers what they want/think about this issue. yes. > > I propose a careful step-by-step implementation. > > For example, moving the caching into a separate directory would be a > > first nice step. There, it could already be realized to have a directory > > strucure based on the OIDs of the NVTs. > > This idea is fine with me. I could split patch so that only cache is > changed. This could be first iteration. What is not implemented is > storing plugins according to OID and to try to implement that part > would be the second iteration. that would be just perfect. Best Jan From openvas-bugs at wald.intevation.org Tue Dec 9 21:26:28 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Tue, 9 Dec 2008 21:26:28 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B846=5D_Cannot_conn?= =?utf-8?q?ect_to_openvas-server?= Message-ID: <20081209202628.403F44072A@pyrosoma.intevation.org> Bugs item #846, was opened at 2008-12-09 20:26 Status: Open Priority: 3 Submitted By: Hans Ullrich (vanguard) Assigned to: Nobody (None) Summary: Cannot connect to openvas-server Resolution: None Severity: blocker Version: v2.0-beta Component: openvas-server Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: Dear maintainers, I got some little problems with openvas-client. I am running debian-sid, 64-bit, with openvas-client from the debian repository and selfcompiled openvas-server and libs on the same machine. Compilation worked fine, all plugins get loaded, I added a user, and I created a certificate. But whenever I start the client as a normal user, and want to connect to the server as the created user, it failed. The message is : Invalid Send-plugins-MD5 from server. Strangewise, when I start the openvas-client as root, it works. But only loaded about 5993 plugins instead of 12000. What is wrong ? What should I do ? Maybe some permissions got to be changed ??? I downloaded the plugins several times (using openvas-nvt-sync), and when I understood it correctly, they are once compiled on my system. Maybe this helps: During this compilation of the plugins, I got errors like: smb_func.inc: No such file available. Please feel free to ask for every information you need. Thanks for any help you will send me!!! Best regards Hans ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=846&group_id=29 From bchandra at secpod.com Wed Dec 10 11:02:01 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 10 Dec 2008 15:32:01 +0530 Subject: [Openvas-devel] [Openvas-discuss] Planning OpenVAS DeveloperConference #2 (OpenVAS DevCon2) In-Reply-To: <200812090944.02588.jan-oliver.wagner@intevation.de> References: <200812041704.13860.jan-oliver.wagner@intevation.de> <200812090944.02588.jan-oliver.wagner@intevation.de> Message-ID: <2B6E748AADB64CBEB6D14D635DAE3D5F@bchandra> I'll be happy to attend the conference. I am sure there'll be lot to discuss including the current issues and plans for the future releases. Workshop idea is good too, if there's interest around. - Workshop on OpenVAS administration and deployment Discussion topics: - OVAL with OpenVAS - NVT coverage scope - Walkthrough of all the pending CR's Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Tuesday, December 09, 2008 2:14 PM To: openvas-discuss at wald.intevation.org Cc: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] [Openvas-discuss] Planning OpenVAS DeveloperConference #2 (OpenVAS DevCon2) Hi, I encourage you to send on-list comments :-) Important decisions that should be made during this developer meeting is: * OIDs: final layout, assignment procedure. * how to get rid of the opevas-plugins module (part of design for OpenVAS 3.0) All the best Jan On Donnerstag, 4. Dezember 2008, Jan-Oliver Wagner wrote: > I do see the growing need to meet in real life in order to > > * review the last 2 years of great development > * plan future features > * discuss designs > * discuss how to extend NVT coverage > * discuss professional services and how they relate to > OpenVAS project > * have a beer (or other beverages) with people we see > only rarely or see only as an email address. > > In summary, I'd like to derive a master plan for the next 1-2 years > from this meeting. > > I offer to hold the 2nd OpenVAS Developer Conference in > Osnabr?ck, Germany in the new offices of Intevation. > Potential dates are: > > June 11-14 2009 (Thursday-Sunday) > June 18-21 2009 (Thursday-Sunday) > July 9-12 2009 (Thursday-Sunday) > July 16-19 2009 (Thursday-Sunday) > > Please let me know what you think! > > Who would like to participate? > And already know the dates are OK for him/her? > > If we can gather at least a small group, then > I will prepare a agenda and start into detailed planning > to offer a nice and interesting stay. > > What I am uncertain: should we consider a Users' session prior > to the DevCon with Workshops or alike? Maybe someone wants > to hold a workshop. If we take a small fee we might finance > travel for some developers. > Opinions on this? -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From openvas-bugs at wald.intevation.org Wed Dec 10 13:49:02 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Wed, 10 Dec 2008 13:49:02 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B847=5D_Translation?= =?utf-8?q?_file_fixed?= Message-ID: <20081210124902.45ADF40775@pyrosoma.intevation.org> Bugs item #847, was opened at 2008-12-10 12:49 Status: Open Priority: 3 Submitted By: Hans Ullrich (vanguard) Assigned to: Nobody (None) Summary: Translation file fixed Resolution: Fixed Severity: minor Version: v2.0-beta Component: openvas-client Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: Dear maintainers, I allowed myself to correct some typos in the translation file of openvas-client. The file is derived from the latest svn version and attached below. I am no coder, so just my two cents. Thank you, for your great work ! Regards Hans ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=847&group_id=29 From michael.wiegand at intevation.de Wed Dec 10 15:53:55 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 10 Dec 2008 15:53:55 +0100 Subject: [Openvas-devel] Planning OpenVAS 2.0.0 Message-ID: <20081210145355.GH22004@intevation.de> Hello, I would like to schedule the release of the "real" 2.0.0 for Wednesday, December 17th. The feedback we have received for the 2.0-rc1 release was (mostly) positive and I think OpenVAS is now ready for prime time, just in time for the holidays. :) This release affects openvas-libraries, openvas-libnasl, openvas-server and openvas-client. Not affected are openvas-plugins and openvas-compendium. Please report any bugs which you think need to be fixed before 2.0.0 to the OpenVAS bug tracker at http://bugs.openvas.org/ and let me know if you have problems with the proposed schedule. Translators, Distro Packagers: Please make sure you contributions are in the SVN repository at least one day before the release so we can include the in 2.0.0. Many thanks once again to everybody who has contributed on the way to 2.0. Feel free to contact me if you have any questions or suggestions. Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Thu Dec 11 13:29:19 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 11 Dec 2008 13:29:19 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B848=5D_openvasd_cr?= =?utf-8?q?ashes_at_startup_with_SEGV?= Message-ID: <20081211122919.0A50740776@pyrosoma.intevation.org> Bugs item #848, was opened at 2008-12-11 12:29 Status: Open Priority: 3 Submitted By: Hans Ullrich (vanguard) Assigned to: Nobody (None) Summary: openvasd crashes at startup with SEGV Resolution: None Severity: blocker Version: v2.0-beta Component: openvas-server Operating System: Linux Product: OpenVAS Hardware: PC URL: Initial Comment: Dear maintainers, the latest version of openvas-server still has two bugs. Might be, you already know it, but I name them here again: ------ 1. openvasd is crashing with segfault (SEGV) after the plugins have bee loaded. This bug shall be fixed in the latest version (svn version), but it is definately NOT. This is my hardware (I got only 256MB RAM on a Pentiu with 500MHz running Debian, i386, testing): lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:03.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 05) 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:09.0 Multimedia audio controller: ESS Technology ES1969 Solo-1 Audiodrive (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c) On my 2GHz AMD64X2 with 2GB Ram and debian-amd64, sid, it is running well. ------------ 2. the svn version is still looking at the wrong path! I compiled using ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var and it installed correctly. But it is still looking at the wron path. See this when doing "make install" uit-secure-1:~/trunk/openvas-server# make install cd openvasd && make make[1]: Entering directory `/root/trunk/openvas-server/openvasd' make[1]: F?r das Ziel ?all? ist nichts zu tun. make[1]: Leaving directory `/root/trunk/openvas-server/openvasd' cd ssl && make make[1]: Entering directory `/root/trunk/openvas-server/ssl' make[1]: F?r das Ziel ?all? ist nichts zu tun. make[1]: Leaving directory `/root/trunk/openvas-server/ssl' /usr/bin/install -c -m 755 openvas-mkcert-client /usr/bin/openvas-mkcert-client /usr/bin/install -c -m 755 openvasd-config /usr/bin/openvasd-config /usr/bin/install -c -m 755 ssl/openvas-mkrand /usr/bin/openvas-mkrand /usr/bin/install -c -m 0755 openvasd/openvasd /usr/sbin/openvasd /usr/bin/install -c -m 755 openvas-adduser /usr/sbin/openvas-adduser /usr/bin/install -c -m 755 openvas-rmuser /usr/sbin/openvas-rmuser /usr/bin/install -c -m 755 openvas-mkcert /usr/sbin/openvas-mkcert /usr/bin/install -c -c -m 0444 openvas-services /var/lib/openvas/openvas-services /usr/bin/install -c -c -m 0444 include/includes.h /usr/include/openvas/includes.h /usr/bin/install -c -c -m 0444 include/config.h /usr/include/openvas/config.h /usr/bin/install -c -c -m 0444 include/threadcompat.h /usr/include/openvas/threadcompat.h /usr/bin/install -c -c -m 0444 include/nessusraw.h /usr/include/openvas/nessusraw.h /usr/bin/install -c -c -m 0444 include/nessusip.h /usr/include/openvas/nessusip.h /usr/bin/install -c -c -m 0444 include/nessusicmp.h /usr/include/openvas/nessusicmp.h /usr/bin/install -c -c -m 0444 include/nessustcp.h /usr/include/openvas/nessustcp.h /usr/bin/install -c -c -m 0444 include/nessusudp.h /usr/include/openvas/nessusudp.h installing man pages ... /usr/bin/install -c -c -m 0444 doc/openvasd-config.1 /usr/share/man/man1/openvasd-config.1 /usr/bin/install -c -c -m 0444 doc/openvas-mkrand.1 /usr/share/man/man1/openvas-mkrand.1 /usr/bin/install -c -c -m 0444 doc/openvasd.8 /usr/share/man/man8/openvasd.8 /usr/bin/install -c -c -m 0444 doc/openvas-adduser.8 /usr/share/man/man8/openvas-adduser.8 /usr/bin/install -c -c -m 0444 doc/openvas-rmuser.8 /usr/share/man/man8/openvas-rmuser.8 /usr/bin/install -c -c -m 0444 doc/openvas-mkcert.8 /usr/share/man/man8/openvas-mkcert.8 /usr/bin/install -c -c -m 0444 doc/openvas-mkcert-client.1 /usr/share/man/man1/openvas-mkcert-client.1 -------------------------------------------------------------- openvas-server has been sucessfully installed. Make sure that /usr/bin and /usr/sbin are in your PATH before you continue. openvasd has been installed into /usr/sbin -------------------------------------------------------------- And this is the output, when running openvasd: -------------- snip ----------------- uit-secure-1:~# openvasd All plugins loaded **** /usr/var/lib/openvas/openvas-services could not be found. Install it and try again ----------- snap ---------------- Sorry for the long text, but maybe it helps a little bit. best regards Hans ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=848&group_id=29 From openvas-bugs at wald.intevation.org Thu Dec 11 16:44:21 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 11 Dec 2008 16:44:21 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B850=5D_nikto_canno?= =?utf-8?q?t_be_found_by_openvas-server?= Message-ID: <20081211154421.3427140791@pyrosoma.intevation.org> Bugs item #850, was opened at 2008-12-11 15:44 Status: Open Priority: 3 Submitted By: Hans Ullrich (vanguard) Assigned to: Nobody (None) Summary: nikto cannot be found by openvas-server Resolution: None Severity: minor Version: v2.0-beta Component: openvas-server Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: Dear maintainers, I found a little bug, which can be easily fixed. Bug: openvas-client says, it cannot find nikto, even if nikto is installed. Reason: openvas is looking at "/usr/bin/nikto.pl" but the correct name of the installed system is "/usr/bin/nikto" As I am only using a debian system, maybe on other systems it may work. Solution: My suggestion: let openvas look at both, nikto.pl and nikto, so it will always work. Workaround: Just create a symlink: ln -s /usr/bin/nikto /usr/bin/nikto.pl Thats it! Cheers Hans ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=850&group_id=29 From matt at mundell.ukfsn.org Thu Dec 11 22:41:13 2008 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 11 Dec 2008 21:41:13 GMT Subject: [Openvas-devel] Change Request 19: Style Message-ID: <20081211213703.1D0C0DEF69@mail.ukfsn.org> I've been coding the Manager daemon. I've been following the GNU coding standard. Michael reviewed the code and has asked me to stay close to the style in CR 19. Firstly, the example in CR 19 is quite close to the GNU standard. How about just adopting the GNU standard entirely? Then the documentation could just refer to that standard, and the code format will match at least some code in other projects. In the CR 19 example, this changes: - function type decorations move to the line above the name of the function. This makes it easier to find the name of the function, for people and for editors. - a space is added after primitive and function calls if (... and strlen (... which spreads things out a bit. - conditional and loop blocks are indented. (Is it common practice to indent these blocks in the same way as function definitions, as in the example?) Secondly, how about turning on Doxygen JAVADOC_AUTOBRIEF? This allows forms such as /** Free any server rules. */ void maybe_free_server_rules () ... in place of /** * @brief Free any server rules. */ void maybe_free_server_rules () ... From jan-oliver.wagner at intevation.de Fri Dec 12 09:02:23 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 12 Dec 2008 09:02:23 +0100 Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: <20081211213703.1D0C0DEF69@mail.ukfsn.org> References: <20081211213703.1D0C0DEF69@mail.ukfsn.org> Message-ID: <200812120902.25679.jan-oliver.wagner@intevation.de> On Donnerstag, 11. Dezember 2008, Matthew Mundell wrote: > Secondly, how about turning on Doxygen JAVADOC_AUTOBRIEF? This allows > forms such as > > /** Free any server rules. */ > void > maybe_free_server_rules () > ... > > in place of > > /** > * @brief Free any server rules. > */ > void > maybe_free_server_rules () > ... the latter form clearly says we use doc method to a novice developer. From the first version you don't really know. I always prefer self-explaining approaches. Probably because I am too lazy to read manuals before digging into something ;-) Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Fri Dec 12 12:27:23 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 12 Dec 2008 16:57:23 +0530 Subject: [Openvas-devel] CR-23: Standardization of script_family Message-ID: Hello, I have updated the CR stating that compendium will be updated based on the outcome of CR-23. Also, I have tried to describe the families (some just can't be described :)) Please refer to, http://www.openvas.net/openvas-cr-23.html If there are no more suggestions, we'll start working on the changes and also update the compendium. Thanks, Chandra. From matt at mundell.ukfsn.org Fri Dec 12 13:38:44 2008 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 12 Dec 2008 12:38:44 GMT Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: Message of Fri, 12 Dec 2008 09:02:23 +0100. <200812120902.25679.jan-oliver.wagner@intevation.de> Message-ID: <20081212123428.7545EDF13A@mail.ukfsn.org> > > Secondly, how about turning on Doxygen JAVADOC_AUTOBRIEF? This allows > > forms such as > > > > /** Free any server rules. */ > > void > > maybe_free_server_rules () > > ... > > > > in place of > > > > /** > > * @brief Free any server rules. > > */ > > void > > maybe_free_server_rules () > > ... > > the latter form clearly says we use doc method to a novice developer. > From the first version you don't really know. Very considerate, although the double star should give the novice some clue. Most functions have arguments and/or a return, like /** "Strip" spaces from either end of a string. * * @param[in,out] string The string to strip. * @param[in] end Pointer to the end of the string. * * \return A new pointer into the string. */ char* strip_space (char* string, char* end) { which shows the doc method even with autobrief. > I always prefer self-explaining approaches. Probably because I am too > lazy to read manuals before digging into something ;-) From felix.wolfsteller at intevation.de Fri Dec 12 13:57:14 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 12 Dec 2008 13:57:14 +0100 Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: <20081211213703.1D0C0DEF69@mail.ukfsn.org> References: <20081211213703.1D0C0DEF69@mail.ukfsn.org> Message-ID: <200812121357.14176.felix.wolfsteller@intevation.de> Thanks for your input Matthew. It seems that the only disputed issue regarding style is whether a tab- key press should insert spaces (bullet-proof) or a \t. I wonder that nobody cares about as how wide a \t should be display. It was my mistake that I did not foresee that a consensus for everything that was adressed in CR #20 is not that easy to achieve (although I am impressed by the peacefulness of the discussion). And a "winner-takes-all" by voting is clearly inacceptable within this topic. I guess I will split the CR up. Anyway, I will try to trigger a solution-finding process soon. On Thursday 11 December 2008 22:41:13 Matthew Mundell wrote: > Firstly, the example in CR 19 is quite close to the GNU standard. How > about just adopting the GNU standard entirely? Then the documentation > could just refer to that standard, and the code format will match at least > some code in other projects. Adopting e.g. the GNU coding standards would make things easier to settle. But I find them somewhat strict and personally, I find my example more "aesthetic" than what would follow the GNU guide, but for sake of an agreement I really do not care (tell me you love it and I vote +1). > - conditional and loop blocks are indented. (Is it common practice to > indent these blocks in the same way as function definitions, as in the > example?) I prefer -- func() { //indented -- and -- if() { // indented -- only argument: more pleasant to read (habits, see above). > Secondly, how about turning on Doxygen JAVADOC_AUTOBRIEF? This allows > forms such as > > /** Free any server rules. */ > void > maybe_free_server_rules () > ... > > in place of > > /** > * @brief Free any server rules. > */ > void > maybe_free_server_rules () > ... I have seen you doing it in the Manager. They are non-exclusive, so imho autobrief can be turned on. I think its an ok solution for one-liners. Otherwise i find a -- /** * @brief You get what I do in one sentence. * If not, read me. ...*/ -- easier to grasp - I am just more familiar with it that way. To be honest generally I do not like stuff behind the double star :) . felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Fri Dec 12 14:27:04 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 12 Dec 2008 14:27:04 +0100 Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: <20081212123428.7545EDF13A@mail.ukfsn.org> References: <20081212123428.7545EDF13A@mail.ukfsn.org> Message-ID: <200812121427.06311.jan-oliver.wagner@intevation.de> On Freitag, 12. Dezember 2008, Matthew Mundell wrote: > Most functions have arguments and/or a return, like > > /** "Strip" spaces from either end of a string. > * > * @param[in,out] string The string to strip. > * @param[in] end Pointer to the end of the string. > * > * \return A new pointer into the string. > */ > char* > strip_space (char* string, char* end) > { > > which shows the doc method even with autobrief. Indeed. I don't have a too strong opinion here. Especially since it is automizable to add a "brief" in case we realize we need it urgently. 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 Dec 12 18:56:08 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 12 Dec 2008 18:56:08 +0100 Subject: [Openvas-devel] CR-23: Standardization of script_family In-Reply-To: References: Message-ID: <200812121856.10675.jan-oliver.wagner@intevation.de> Hello Chandra, thanks for the good work! On Freitag, 12. Dezember 2008, Chandrashekhar B wrote: > I have updated the CR stating that compendium will be updated based on the > outcome of CR-23. Also, I have tried to describe the families (some just > can't be described :)) > > Please refer to, > http://www.openvas.net/openvas-cr-23.html > > If there are no more suggestions, we'll start working on the changes and > also update the compendium. We should first call for a vote before starting to work on it. Some suggestions: * Brute force attacks: the definitions sound like this is the group of "dangerous" NVTs. Am I correct with this assumption? We might want to elaborate a bit more in the description. (ah, I see you did similar in Denial of Service, perhaps repeat it for brute force?) * Default Unix Accounts: Shouldn't this be generalized into "Default Accounts"? * there are some families without a description text. Most are self-explanatory. I'd prefer though a short sentence for any of them. However, it is not mandatory yet to find a precise definition as we inherited a inconsistent naming scheme from Nessus. Effects: Assume we adjust names as proposed in openvas-plugins and thus in the feed. What will happen to current users and their tasks/scopes? Should we announce this change before putting into feed to make people not wonder? Design and Implementation: Perhaps add a item, that we implement a little tool that runs though all NVTs and checks for undefined family names? 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 sgros.ml at gmail.com Sun Dec 14 10:44:47 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Sun, 14 Dec 2008 10:44:47 +0100 Subject: [Openvas-devel] CR-23: Standardization of script_family In-Reply-To: References: Message-ID: <4d7b043c0812140144w6b229b1etd2f13fce00d6e45c@mail.gmail.com> On Fri, Dec 12, 2008 at 12:27 PM, Chandrashekhar B wrote: > Hello, > > I have updated the CR stating that compendium will be updated based on the > outcome of CR-23. Also, I have tried to describe the families (some just > can't be described :)) > > Please refer to, > http://www.openvas.net/openvas-cr-23.html > > If there are no more suggestions, we'll start working on the changes and > also update the compendium. It seems to me that what you try to accomplish is related to the following work done by MITRE: http://cwe.mitre.org have you looked at it? SG From sgros.ml at gmail.com Sun Dec 14 10:52:27 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Sun, 14 Dec 2008 10:52:27 +0100 Subject: [Openvas-devel] Few questions about the code... Message-ID: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> After looking into the code I have some comment and questions that someone can answer: 1. Who/where/when and why sets and uses ENABLE_PLUGIN_SERVER. I grep'ed through the code and it's only used, not defined anywere!? 2. The consequence of 1 is that "cache_dir" is never used (it's in plugins directory, .bin subdirectory) and that cache I'm talking about in CR is differently set. 3. What are the rules/recommendations for logging. As I saw, sometimes, printf is used, then fprintf, occasionally perror and finally log_* functions. 4. Why in plugutils there is a function "plug_get_oid" that only calls "_plug_get_oid"? Is there something planned in the future? SG From sgros.ml at gmail.com Sun Dec 14 11:06:10 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Sun, 14 Dec 2008 11:06:10 +0100 Subject: [Openvas-devel] Few questions about the code... In-Reply-To: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> References: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> Message-ID: <4d7b043c0812140206p2283e3e0j3174c29451097a15@mail.gmail.com> One additional note on the doxygen documentation for the functions. Wouldn't it be more readable if there is a new line between different sections, i.e. between description (potentially, between short and long description), input parameters and output value? SG On Sun, Dec 14, 2008 at 10:52 AM, Stjepan Gros wrote: > After looking into the code I have some comment and questions that > someone can answer: > > 1. Who/where/when and why sets and uses ENABLE_PLUGIN_SERVER. I > grep'ed through the code and it's only used, not defined anywere!? > > 2. The consequence of 1 is that "cache_dir" is never used (it's in > plugins directory, .bin subdirectory) and that cache I'm talking about > in CR is differently set. > > 3. What are the rules/recommendations for logging. As I saw, > sometimes, printf is used, then fprintf, occasionally perror and > finally log_* functions. > > 4. Why in plugutils there is a function "plug_get_oid" that only calls > "_plug_get_oid"? Is there something planned in the future? > > SG > From sgros.ml at gmail.com Sun Dec 14 11:37:48 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Sun, 14 Dec 2008 11:37:48 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <200812092239.44901.jan-oliver.wagner@intevation.de> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <200812090940.20357.jan-oliver.wagner@intevation.de> <4d7b043c0812090916k1f178cc0s6a2dd11e4a35b64@mail.gmail.com> <200812092239.44901.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0812140237j470ba506o9c2f3d00754a087@mail.gmail.com> On Tue, Dec 9, 2008 at 10:39 PM, Jan-Oliver Wagner wrote: >> and this would work. What wouldn't work (yet) is cache directory which >> has to be changed to store cached plugins to follow OIDs. > >> the small problem could be when there is numerical OID without >> symbolic name. in that case openvas server can use numerical value as >> a name of directory, but, this can cause some confusion when symbolic >> name is introduced into the server and now there is numerical as well >> as symbolic directory. the best place to put numeric to symbolic >> mapping would be in configuration file, but it will take some time to >> be implemented and also exact configuration directives have to be >> defined. maybe i would leave this after the first version works. > > we could also have symbolic links to have both, the number and name > representation. However, I don't think it is a really urgent problem. It turns out that the function plug_get_oid returns numerical values (in a string) for all the plugins, so maybe numerical values should be used consistently with symbolic names (if necessary at all) being soft links to numercal values. >> > I propose a careful step-by-step implementation. >> > For example, moving the caching into a separate directory would be a >> > first nice step. There, it could already be realized to have a directory >> > strucure based on the OIDs of the NVTs. >> >> This idea is fine with me. I could split patch so that only cache is >> changed. This could be first iteration. What is not implemented is >> storing plugins according to OID and to try to implement that part >> would be the second iteration. > > that would be just perfect. Ok, I started to work on this but stumbled on a problem at a very start. :) Apart from the questions I sent in another mail (they are general enough and do not influence so much the cache reoganization) there is one bigger problem to OID organization of the plugins. Currently, the code functions in such a way that it starts with the name of the plugin and then searches for this name in the cache directory. If it's found then checks are made to determine if the cache is current or not followed by other processing. Now, the idea is to also start with a name but then to look it into the cache _by OID_. But the OID is not known until the source of the plugin is loaded and parsed, which beats the idea of the cache. The possible solution is to pelaod the cache, and than to start loading the sources. Then, the cache can be searched by the full pathname. There are two ways in which this can be implemented: 1. internal to, e.g. nasl_plugin_add. in this case the given fuction checks that cache is already preloaded, and if not preloads it, otherwise, just continues with a "usual" work, or 2. new function pointer is introduced into the pt_class_t structure for "cache warm up", i.e. it is called before loading plugins. The second way of implementing this has additional plus in that it allows for "cache only startup of openvasd", i.e. the caches are only loaded and no sources are checked. What are opinions of the people on this list about this? SG P.S. Should I update CR with this information? From jan-oliver.wagner at intevation.de Sun Dec 14 21:13:28 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sun, 14 Dec 2008 21:13:28 +0100 Subject: [Openvas-devel] Few questions about the code... In-Reply-To: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> References: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> Message-ID: <200812142113.28476.> On Sunday 14 December 2008 10:52:27 Stjepan Gros wrote: > 1. Who/where/when and why sets and uses ENABLE_PLUGIN_SERVER. I > grep'ed through the code and it's only used, not defined anywere!? > > 2. The consequence of 1 is that "cache_dir" is never used (it's in > plugins directory, .bin subdirectory) and that cache I'm talking about > in CR is differently set. I think you spotted yet another portion of code that is unused. I found no place where the "Plugin Server" is enabled or even used. I also fail to understand the code (badly documented) nor can I imagine any reason why a "plugin server" should make sense. Does anyone else have an idea about this feature? > 3. What are the rules/recommendations for logging. As I saw, > sometimes, printf is used, then fprintf, occasionally perror and > finally log_* functions. I think we do not have defined rules yet. > 4. Why in plugutils there is a function "plug_get_oid" that only calls > "_plug_get_oid"? Is there something planned in the future? I guess it is just there because the other methods (e.g. get_cve_id) followed the same scheme. Perhaps yet another place to reduce code base. Best Jan From jan-oliver.wagner at intevation.de Sun Dec 14 21:46:53 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sun, 14 Dec 2008 21:46:53 +0100 Subject: [Openvas-devel] CR-23: Standardization of script_family In-Reply-To: <4d7b043c0812140144w6b229b1etd2f13fce00d6e45c@mail.gmail.com> References: <4d7b043c0812140144w6b229b1etd2f13fce00d6e45c@mail.gmail.com> Message-ID: <200812142146.54083.jan-oliver.wagner@intevation.de> On Sunday 14 December 2008 10:44:47 Stjepan Gros wrote: > On Fri, Dec 12, 2008 at 12:27 PM, Chandrashekhar B wrote: > It seems to me that what you try to accomplish is related to the > following work done by MITRE: > > http://cwe.mitre.org > > have you looked at it? I am aware of CWE, but I have never had contact with people involved there. However, it might be good to extend CR23 with a note that eventually it might make sense to consider CWE for family definition. In a first step CR23 will clean up current situation and provide a reference. This is very helpful already and realtively cheap to gain. CWE will likely be expensive. Best Jan From jan-oliver.wagner at intevation.de Sun Dec 14 21:58:34 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sun, 14 Dec 2008 21:58:34 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <4d7b043c0812140237j470ba506o9c2f3d00754a087@mail.gmail.com> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <200812092239.44901.jan-oliver.wagner@intevation.de> <4d7b043c0812140237j470ba506o9c2f3d00754a087@mail.gmail.com> Message-ID: <200812142158.34423.jan-oliver.wagner@intevation.de> On Sunday 14 December 2008 11:37:48 Stjepan Gros wrote: > It turns out that the function plug_get_oid returns numerical values > (in a string) for all the plugins, so maybe numerical values should be > used consistently with symbolic names (if necessary at all) being soft > links to numercal values. AFAIU, the OID numerical values are the ones that count. > >> > I propose a careful step-by-step implementation. > >> > For example, moving the caching into a separate directory would be a > >> > first nice step. There, it could already be realized to have a > >> > directory strucure based on the OIDs of the NVTs. > >> > >> This idea is fine with me. I could split patch so that only cache is > >> changed. This could be first iteration. What is not implemented is > >> storing plugins according to OID and to try to implement that part > >> would be the second iteration. > > > > that would be just perfect. > > Ok, I started to work on this but stumbled on a problem at a very > start. :) Apart from the questions I sent in another mail (they are > general enough and do not influence so much the cache reoganization) > there is one bigger problem to OID organization of the plugins. > > Currently, the code functions in such a way that it starts with the > name of the plugin and then searches for this name in the cache > directory. If it's found then checks are made to determine if the > cache is current or not followed by other processing. > > Now, the idea is to also start with a name but then to look it into > the cache _by OID_. But the OID is not known until the source of the > plugin is loaded and parsed, which beats the idea of the cache. > > The possible solution is to pelaod the cache, and than to start > loading the sources. Then, the cache can be searched by the full > pathname. There are two ways in which this can be implemented: Wouldn't another solution option be to reorganize the caching as such to be based on OIDs instead of names? > What are opinions of the people on this list about this? I am not 100% sure I understood you proposed solution options. Preloading seems to me (at a very first glance) quite complicated. I confess I did not dig into this code path, but wouldn't it be possible to build the cache in a way that the key for searching is the OID? > P.S. Should I update CR with this information? Sure, CRs are living documents. You may update them whenever it makes sense. Best Jan From sgros.ml at gmail.com Mon Dec 15 08:26:09 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Mon, 15 Dec 2008 08:26:09 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <200812142158.34423.jan-oliver.wagner@intevation.de> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <200812092239.44901.jan-oliver.wagner@intevation.de> <4d7b043c0812140237j470ba506o9c2f3d00754a087@mail.gmail.com> <200812142158.34423.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0812142326t496a8562q2c4dd9184a0a3701@mail.gmail.com> On Sun, Dec 14, 2008 at 9:58 PM, Jan-Oliver Wagner wrote: > On Sunday 14 December 2008 11:37:48 Stjepan Gros wrote: >> It turns out that the function plug_get_oid returns numerical values >> (in a string) for all the plugins, so maybe numerical values should be >> used consistently with symbolic names (if necessary at all) being soft >> links to numercal values. > > AFAIU, the OID numerical values are the ones that count. > >> >> > I propose a careful step-by-step implementation. >> >> > For example, moving the caching into a separate directory would be a >> >> > first nice step. There, it could already be realized to have a >> >> > directory strucure based on the OIDs of the NVTs. >> >> >> >> This idea is fine with me. I could split patch so that only cache is >> >> changed. This could be first iteration. What is not implemented is >> >> storing plugins according to OID and to try to implement that part >> >> would be the second iteration. >> > >> > that would be just perfect. >> >> Ok, I started to work on this but stumbled on a problem at a very >> start. :) Apart from the questions I sent in another mail (they are >> general enough and do not influence so much the cache reoganization) >> there is one bigger problem to OID organization of the plugins. >> >> Currently, the code functions in such a way that it starts with the >> name of the plugin and then searches for this name in the cache >> directory. If it's found then checks are made to determine if the >> cache is current or not followed by other processing. >> >> Now, the idea is to also start with a name but then to look it into >> the cache _by OID_. But the OID is not known until the source of the >> plugin is loaded and parsed, which beats the idea of the cache. >> >> The possible solution is to pelaod the cache, and than to start >> loading the sources. Then, the cache can be searched by the full >> pathname. There are two ways in which this can be implemented: > > Wouldn't another solution option be to reorganize the caching as such > to be based on OIDs instead of names? That is the idea. The problem is that plugins themselves, as source files, are stored in files with descriptive names. Now, when you know the name of the plugin on a disk, you don't know it's OID until you read and parse it. For easier understanding I'll describe this process now, and how it is planned to be implemented, on a plugin named plugin.nasl with an OID 1.2.3.4.5.6.7.8 Current code --------------- Upon openvasd startup it takes plugin, plugin.nasl, loads and parses it and then stores it's cache into PLUGINDIR/.desc/plugin.desc On each other invocation, for a plugin named plugin.nasl, before loading source and parsing it, it loads PLUGINDIR/.desc/plugin.desc (name which is easily constructed from the plugin's name ONLY!) and then checks timestamps on the files to determine if the cache has to be updates. Planned code ---------------- Upon openvasd startup it takes plugin, plugin.nasl, loads and parses it and then stores it's cache into CACHEDIR/1/2/3/4/5/6/7/8/plugin.desc (or something similar). But, on each other invocation, for a plugin named plugin.nasl there is no way for openvasd to know OID, if the plugin.nasl itself is not loaded and parsed and thus, it can not check if there is (for a start) file CACHEDIR/1/2/3/4/5/6/7/8/plugin.desc (or something similar) nor if the source is newer than the cache. Did I better explain the problem? > >> What are opinions of the people on this list about this? > > I am not 100% sure I understood you proposed solution options. > Preloading seems to me (at a very first glance) quite complicated. > I confess I did not dig into this code path, but wouldn't it be possible > to build the cache in a way that the key for searching is the OID? > >> P.S. Should I update CR with this information? > > Sure, CRs are living documents. You may update them whenever it > makes sense. Ok, I'll update it when we reach some consensus about this. Stjepan From sgros.ml at gmail.com Mon Dec 15 08:30:48 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Mon, 15 Dec 2008 08:30:48 +0100 Subject: [Openvas-devel] Few questions about the code... In-Reply-To: <-5891970929835685261@unknownmsgid> References: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> <-5891970929835685261@unknownmsgid> Message-ID: <4d7b043c0812142330x125f871y3c05da92944165e3@mail.gmail.com> On Sun, Dec 14, 2008 at 9:13 PM, Jan-Oliver Wagner wrote: > On Sunday 14 December 2008 10:52:27 Stjepan Gros wrote: >> 1. Who/where/when and why sets and uses ENABLE_PLUGIN_SERVER. I >> grep'ed through the code and it's only used, not defined anywere!? >> >> 2. The consequence of 1 is that "cache_dir" is never used (it's in >> plugins directory, .bin subdirectory) and that cache I'm talking about >> in CR is differently set. > > I think you spotted yet another portion of code that is unused. > I found no place where the "Plugin Server" is enabled or even used. > I also fail to understand the code (badly documented) nor can I > imagine any reason why a "plugin server" should make sense. > > Does anyone else have an idea about this feature? If no one has argument to leave this code in, I can generate a patch to remove it. This should be fairly easy to do. >> 3. What are the rules/recommendations for logging. As I saw, >> sometimes, printf is used, then fprintf, occasionally perror and >> finally log_* functions. > > I think we do not have defined rules yet. Well, it seems like good oportunity for another CR? :) >> 4. Why in plugutils there is a function "plug_get_oid" that only calls >> "_plug_get_oid"? Is there something planned in the future? > > I guess it is just there because the other methods (e.g. get_cve_id) > followed the same scheme. Perhaps yet another place to reduce code base. This one is also fairly easy to change. S From bchandra at secpod.com Mon Dec 15 11:28:30 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 15 Dec 2008 15:58:30 +0530 Subject: [Openvas-devel] CR-23: Standardization of script_family In-Reply-To: <200812121856.10675.jan-oliver.wagner@intevation.de> References: <200812121856.10675.jan-oliver.wagner@intevation.de> Message-ID: -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Friday, December 12, 2008 11:26 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] CR-23: Standardization of script_family > Hello Chandra, > thanks for the good work! On Freitag, 12. Dezember 2008, Chandrashekhar B wrote: >> I have updated the CR stating that compendium will be updated based on the >> outcome of CR-23. Also, I have tried to describe the families (some just >> can't be described :)) >> >> Please refer to, >> http://www.openvas.net/openvas-cr-23.html >> >> If there are no more suggestions, we'll start working on the changes and >> also update the compendium. > We should first call for a vote before starting to work on it. > Some suggestions: > * Brute force attacks: the definitions sound like this is the group of > "dangerous" NVTs. Am I correct with this assumption? > We might want to elaborate a bit more in the description. > (ah, I see you did similar in Denial of Service, perhaps repeat it for > brute force?) All the current set of Plugins trying brute force method using Hydra tool are categorized into this family. I will update the description to mean differently. > * Default Unix Accounts: Shouldn't this be generalized into "Default > Accounts"? You mean, change the name from Default Unix Accounts to Unix Accounts? Will update the CR. > * there are some families without a description text. Most are self- > explanatory. > I'd prefer though a short sentence for any of them. > However, it is not mandatory yet to find a precise definition as we > inherited > a inconsistent naming scheme from Nessus. Most of them are self-explanatory. I'll update. > Effects: Assume we adjust names as proposed in openvas-plugins and thus > in the feed. What will happen to current users and their tasks/scopes? > Should we announce this change before putting into feed to make people not > wonder? I didn't think in this direction, thanks for pointing. I think we should announce. If someone has built products around OpenVAS, depending on how they have treated families, things might break. But, I think we are at early stage. We should definitely announce this. > Design and Implementation: > Perhaps add a item, that we implement a little tool that runs though all > NVTs and checks > for undefined family names? Will update. Thanks, Chandra. From bchandra at secpod.com Mon Dec 15 11:44:23 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 15 Dec 2008 16:14:23 +0530 Subject: [Openvas-devel] CR-23: Standardization of script_family In-Reply-To: <4d7b043c0812140144w6b229b1etd2f13fce00d6e45c@mail.gmail.com> References: <4d7b043c0812140144w6b229b1etd2f13fce00d6e45c@mail.gmail.com> Message-ID: -----Original Message----- From: Stjepan Gros [mailto:sgros.ml at gmail.com] Sent: Sunday, December 14, 2008 3:15 PM To: Chandrashekhar B Cc: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] CR-23: Standardization of script_family On Fri, Dec 12, 2008 at 12:27 PM, Chandrashekhar B wrote: >> Hello, >> >> I have updated the CR stating that compendium will be updated based on the >> outcome of CR-23. Also, I have tried to describe the families (some just >> can't be described :)) >> >> Please refer to, >> http://www.openvas.net/openvas-cr-23.html >> >> If there are no more suggestions, we'll start working on the changes and >> also update the compendium. > It seems to me that what you try to accomplish is related to the > following work done by MITRE: > http://cwe.mitre.org > have you looked at it? Stjepan, Thanks for pointing this out. CWE looks to be very nice idea. But there are about 600+ weaknesses documented already which is very exhaustive. We need to work out some means for NVT developers to make it easy to map to a CWE. With CR #22, it is easy to add a new tag, We can just say script_tag("CWE", "209") But, for now, I think I'll go ahead with referencing this work on CWE and once we get a better understanding of how easily we can map CWE's to NVT's, we can update. Thanks, Chandra. From jan-oliver.wagner at intevation.de Mon Dec 15 11:46:22 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 15 Dec 2008 11:46:22 +0100 Subject: [Openvas-devel] CR-23: Standardization of script_family In-Reply-To: References: <200812121856.10675.jan-oliver.wagner@intevation.de> Message-ID: <200812151146.25169.jan-oliver.wagner@intevation.de> On Montag, 15. Dezember 2008, Chandrashekhar B wrote: > > * Default Unix Accounts: Shouldn't this be generalized into "Default > > Accounts"? > > You mean, change the name from Default Unix Accounts to Unix Accounts? Will > update the CR. No, to "Default Accounts". "Unix" isn't suitable IMHO. Or did I misunderstand something here? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Mon Dec 15 12:21:06 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 15 Dec 2008 16:51:06 +0530 Subject: [Openvas-devel] CR-23: Standardization of script_family In-Reply-To: <200812151146.25169.jan-oliver.wagner@intevation.de> References: <200812121856.10675.jan-oliver.wagner@intevation.de> <200812151146.25169.jan-oliver.wagner@intevation.de> Message-ID: -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Monday, December 15, 2008 4:16 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] CR-23: Standardization of script_family On Montag, 15. Dezember 2008, Chandrashekhar B wrote: >> > * Default Unix Accounts: Shouldn't this be generalized into "Default >> > Accounts"? > >> You mean, change the name from Default Unix Accounts to Unix Accounts? Will >> update the CR. > No, to "Default Accounts". "Unix" isn't suitable IMHO. Or did I > misunderstand something here? Updated to "Default Accounts" Thanks, Chandra. From bchandra at secpod.com Mon Dec 15 13:48:17 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 15 Dec 2008 18:18:17 +0530 Subject: [Openvas-devel] Change Request #25: Integration of SAMBA/WMI to OpenVAS-nasl Message-ID: <81DF4EACE59142E0AEBB292025F55813@bchandra> Hello, I have submitted a change request for integrating the features of SAMBA and/ WMI into OpenVAS space for having better API set for Windows based target systems. OpenVAS will be able to scan Windows Vista, 2008 and 2003 (in its default policy settings) in addition to having new set of API's. I seek your feedback on the approach discussed in the CR and suggest possible improvements. The CR is available at, http://www.openvas.org/openvas-cr-25.html Thanks, Chandra. From bitdealer at gmail.com Mon Dec 15 14:52:41 2008 From: bitdealer at gmail.com (Stephan Kleine) Date: Mon, 15 Dec 2008 14:52:41 +0100 Subject: [Openvas-devel] [Openvas-distro] Feedback for RC1 In-Reply-To: <20081208151519.GD11603@intevation.de> References: <20081208151519.GD11603@intevation.de> Message-ID: > As far as I understand your mail, these issues do not break > functionality, but rather force more or less ugly workarounds, correct? I don't know if it breaks functionality (my guess it doesn't since it builds with said workarounds) but my point simply is that you are currently abusing your build system (as in using it somehow wrong) which normally is a sure way to make it blow up right in your face one the next most unfavourable occasion. > Unfortunately, I have neither the time nor the experience right now to > propose a good solution to this problem, so Neither do I, but since it worked just fine for earlier (1.x) releases it has to be some change you introduced since then. And, since you need only log2(#of commits) - e.g. 1024 commits for -libraries since the latest 1.x release woud require you to check only 10 different revisions - it shouldn't take long to narrow it down to one patchset that broke it. IMHO you better invest that time now instead of having to do it after it completely broke. Besides that, the only thing I noticed is that for some reason appending "-I../libopenvas" to libtool's / gcc's parameters does erase the $CFLAGS variable. Perhaps this helps somehow. regards Stephan From jan-oliver.wagner at intevation.de Mon Dec 15 22:39:36 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 15 Dec 2008 22:39:36 +0100 Subject: [Openvas-devel] Few questions about the code... In-Reply-To: <4d7b043c0812142330x125f871y3c05da92944165e3@mail.gmail.com> References: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> <-5891970929835685261@unknownmsgid> <4d7b043c0812142330x125f871y3c05da92944165e3@mail.gmail.com> Message-ID: <200812152239.37220.jan-oliver.wagner@intevation.de> On Monday 15 December 2008 08:30:48 Stjepan Gros wrote: > On Sun, Dec 14, 2008 at 9:13 PM, Jan-Oliver Wagner > wrote: > > On Sunday 14 December 2008 10:52:27 Stjepan Gros wrote: > >> 1. Who/where/when and why sets and uses ENABLE_PLUGIN_SERVER. I > >> grep'ed through the code and it's only used, not defined anywere!? > >> > >> 2. The consequence of 1 is that "cache_dir" is never used (it's in > >> plugins directory, .bin subdirectory) and that cache I'm talking about > >> in CR is differently set. > > > > I think you spotted yet another portion of code that is unused. > > I found no place where the "Plugin Server" is enabled or even used. > > I also fail to understand the code (badly documented) nor can I > > imagine any reason why a "plugin server" should make sense. > > > > Does anyone else have an idea about this feature? > > If no one has argument to leave this code in, I can generate a patch > to remove it. This should be fairly easy to do. I digged into this further and started to remove it. It is not so easy as thought initially. Re-inventing the wheel 3 times in a row sometimes characterizes the code base ;-) Best Jan From jan-oliver.wagner at intevation.de Tue Dec 16 08:52:21 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 16 Dec 2008 08:52:21 +0100 Subject: [Openvas-devel] Today: Joined efford to solve autotools issues before 2.0.0 - please help Message-ID: <200812160852.24387.jan-oliver.wagner@intevation.de> Hi all, issues have been reported that the configure environment of OpenVAS does not work properly. Michael and myself were not able to reproduce the problem nor to fully understand it. So, please get into a discussion at IRC today to help solving the issue. See http://www.openvas.org/online-chat.html how to get there. Michael and myself will be there and do anything we can do to assist the analysis/understanding/fix of the issue. Since most people did not report problems with rc1, we will release 2.0.0 in case no one joins into the IRC session to discuss. I think that is the best we can do. Delaying the 2.0.0 further is no good option IMHO. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Tue Dec 16 10:15:16 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 16 Dec 2008 10:15:16 +0100 Subject: [Openvas-devel] Change Request #25: Integration of SAMBA/WMI to OpenVAS-nasl In-Reply-To: <81DF4EACE59142E0AEBB292025F55813@bchandra> References: <81DF4EACE59142E0AEBB292025F55813@bchandra> Message-ID: <200812161015.17823.jan-oliver.wagner@intevation.de> Hello Chandra, On Montag, 15. Dezember 2008, Chandrashekhar B wrote: > I have submitted a change request for integrating the features of SAMBA and/ > WMI into OpenVAS space for having better API set for Windows based target > systems. OpenVAS will be able to scan Windows Vista, 2008 and 2003 (in its > default policy settings) in addition to having new set of API's. I seek your > feedback on the approach discussed in the CR and suggest possible > improvements. The CR is available at, > > http://www.openvas.org/openvas-cr-25.html thanks for adessing this very important aspect! I have a spontaneous question: Are high privileges required to run the smb stuff or are lower privileges sufficient. Note: What I am having in mind is a privilege downgrade for openvasd in case of samba based tests to lower security problems. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Tue Dec 16 10:47:08 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 16 Dec 2008 10:47:08 +0100 Subject: [Openvas-devel] Few questions about the code... In-Reply-To: <4d7b043c0812142330x125f871y3c05da92944165e3@mail.gmail.com> References: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> <-5891970929835685261@unknownmsgid> <4d7b043c0812142330x125f871y3c05da92944165e3@mail.gmail.com> Message-ID: <200812161047.10220.jan-oliver.wagner@intevation.de> On Montag, 15. Dezember 2008, Stjepan Gros wrote: > On Sun, Dec 14, 2008 at 9:13 PM, Jan-Oliver Wagner > >> 3. What are the rules/recommendations for logging. As I saw, > >> sometimes, printf is used, then fprintf, occasionally perror and > >> finally log_* functions. > > > > I think we do not have defined rules yet. > > Well, it seems like good oportunity for another CR? :) indeed :-) > >> 4. Why in plugutils there is a function "plug_get_oid" that only calls > >> "_plug_get_oid"? Is there something planned in the future? > > > > I guess it is just there because the other methods (e.g. get_cve_id) > > followed the same scheme. Perhaps yet another place to reduce code base. > > This one is also fairly easy to change. be careful. Sometimes the interdependencies in the code are far more complex than expected (and far more complex than necessary). 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 matt at mundell.ukfsn.org Tue Dec 16 13:34:03 2008 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 16 Dec 2008 12:34:03 GMT Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: Message of Fri, 12 Dec 2008 13:57:14 +0100. <200812121357.14176.felix.wolfsteller@intevation.de> Message-ID: <20081216122937.96CA7DEF48@mail.ukfsn.org> > It seems that the only disputed issue regarding style is whether a tab- key > press should insert spaces (bullet-proof) or a \t. I'm happy with a mandatory space rule. It's more likely to result in consistently formatted code. > On Thursday 11 December 2008 22:41:13 Matthew Mundell wrote: > > Firstly, the example in CR 19 is quite close to the GNU standard. How > > about just adopting the GNU standard entirely? Then the documentation > > could just refer to that standard, and the code format will match at least > > some code in other projects. > Adopting e.g. the GNU coding standards would make things easier to settle. > But I find them somewhat strict and personally, I find my example > more "aesthetic" than what would follow the GNU guide, but for sake of an > agreement I really do not care (tell me you love it and I vote +1). I love it, if only to force the adoption of an existing standard. > > - conditional and loop blocks are indented. (Is it common practice to > > indent these blocks in the same way as function definitions, as in the > > example?) > I prefer > -- > func() > { > //indented > -- > and > -- > if() > { > // indented > -- > only argument: more pleasant to read (habits, see above). I think this is a very rare style, and adopting a more common style has more benefit. > > Secondly, how about turning on Doxygen JAVADOC_AUTOBRIEF? This allows > > forms such as > > > > /** Free any server rules. */ > > void > > maybe_free_server_rules () > > ... > > > > in place of > > > > /** > > * @brief Free any server rules. > > */ > > void > > maybe_free_server_rules () > > ... > > I have seen you doing it in the Manager. > They are non-exclusive, so imho autobrief can be turned on. > I think its an ok solution for one-liners. > Otherwise i find a > -- > /** > * @brief You get what I do in one sentence. > * If not, read me. > ...*/ > -- > easier to grasp - I am just more familiar with it that way. > To be honest generally I do not like stuff behind the double star :) . I think it would be cleaner and more manageable to format every single documentation comment exactly the same way. I'll happily use the @brief style if it's chosen, although I think the autobrief style in neater and easier to read. From matt at mundell.ukfsn.org Tue Dec 16 13:36:54 2008 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 16 Dec 2008 12:36:54 GMT Subject: [Openvas-devel] Few questions about the code... In-Reply-To: Message of Sun, 14 Dec 2008 11:06:10 +0100. <4d7b043c0812140206p2283e3e0j3174c29451097a15@mail.gmail.com> Message-ID: <20081216123228.C260BDEF66@mail.ukfsn.org> > One additional note on the doxygen documentation for the functions. > Wouldn't it be more readable if there is a new line between different > sections, i.e. between description (potentially, between short and > long description), input parameters and output value? Yes, I agree it would. From felix.wolfsteller at intevation.de Tue Dec 16 14:29:16 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 16 Dec 2008 14:29:16 +0100 Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: <20081216122937.96CA7DEF48@mail.ukfsn.org> References: <20081216122937.96CA7DEF48@mail.ukfsn.org> Message-ID: <200812161429.16248.felix.wolfsteller@intevation.de> Thanks Matthew, I have updated the CR (http://www.openvas.org/openvas-cr-19.html) to meet what is adressed in the following. I also included the three changes of your mail of thursday, 11th dec. The file should now follow most of the GNU rules. On Tuesday 16 December 2008 13:34:03 Matthew Mundell wrote: > > It seems that the only disputed issue regarding style is whether a tab- > > key press should insert spaces (bullet-proof) or a \t. > > I'm happy with a mandatory space rule. It's more likely to result in > consistently formatted code. Great. > > Adopting e.g. the GNU coding standards would make things easier to > > settle. But I find them somewhat strict and personally, I find my example > > more "aesthetic" than what would follow the GNU guide, but for sake of an > > agreement I really do not care (tell me you love it and I vote +1). > > I love it, if only to force the adoption of an existing standard. Great. > > > - conditional and loop blocks are indented. (Is it common practice > > > to indent these blocks in the same way as function definitions, as in > > > the example?) > > > > I prefer > > -- > > func() > > { > > //indented > > -- > > and > > -- > > if() > > { > > // indented > > -- > > only argument: more pleasant to read (habits, see above). > > I think this is a very rare style, and adopting a more common style has > more benefit. Accepted. > > > Secondly, how about turning on Doxygen JAVADOC_AUTOBRIEF? This allows > > > forms such as > > > > > > /** Free any server rules. */ > > > void > > > maybe_free_server_rules () > > > ... > > > > > > in place of > > > > > > /** > > > * @brief Free any server rules. > > > */ > > > void > > > maybe_free_server_rules () > > > ... > > > > I have seen you doing it in the Manager. > > They are non-exclusive, so imho autobrief can be turned on. > > I think its an ok solution for one-liners. > > Otherwise i find a > > -- > > /** > > * @brief You get what I do in one sentence. > > * If not, read me. > > ...*/ > > -- > > easier to grasp - I am just more familiar with it that way. > > To be honest generally I do not like stuff behind the double star :) . > > I think it would be cleaner and more manageable to format every single > documentation comment exactly the same way. I'll happily use the @brief > style if it's chosen, although I think the autobrief style in neater and > easier to read. I went with Jan-Olivers comment (@brief more self explanatory then double star). -- 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 Tue Dec 16 14:30:04 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 16 Dec 2008 14:30:04 +0100 Subject: [Openvas-devel] Call for votes CR#19: Agree on a style guideline and on a format for the documentation Message-ID: <200812161430.04101.felix.wolfsteller@intevation.de> I would like new votes for Change Request #19 ("Style") (http://www.openvas.org/openvas-cr-19.html). As more arguments have been issued for an existing standard (GNU), which was already mentioned in the compendium than for anything else, your +1 vote means: Obey GNU Coding Style and use doxygen comments in javadoc style. (http://www.gnu.org/prep/standards/standards.html#Formatting) and (http://www.stack.nl/~dimitri/doxygen/). Please note that the highlighted example on the webpage might not follow all the rules (I tried an automatic formatter but gave up very fast), please have a look at the reference if you want to be sure. If the voting "fails" I will issue new CRs that split the topic into smaller bites. So far, use of doxygen seemed to be fine for everybody, so if you vote -1 please give me at least a comment about doxygen. +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 timb at nth-dimension.org.uk Tue Dec 16 23:45:20 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Tue, 16 Dec 2008 22:45:20 +0000 Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: <200812161429.16248.felix.wolfsteller@intevation.de> References: <20081216122937.96CA7DEF48@mail.ukfsn.org> <200812161429.16248.felix.wolfsteller@intevation.de> Message-ID: <200812162245.20614.timb@nth-dimension.org.uk> I'm happy to go with *any consensus* no matter what it might be, although I'd still prefer tabs to spaces (simply because it means I don't have to do per project configuration on all my development systems). That being said, I see no reason why we can't use spaces. As I said before, any reasonable editor will do both. From my own perspective both Kate[1] and vim[2] can handle either. Tim [1] http://bugs.kde.org/show_bug.cgi?id=67448 [2] http://www.vim.org/htmldoc/indent.html -- Tim Brown From jan-oliver.wagner at intevation.de Wed Dec 17 01:01:21 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 17 Dec 2008 01:01:21 +0100 Subject: [Openvas-devel] Call for votes CR#19: Agree on a style guideline and on a format for the documentation In-Reply-To: <200812161430.04101.felix.wolfsteller@intevation.de> References: <200812161430.04101.felix.wolfsteller@intevation.de> Message-ID: <200812170101.21506.jan-oliver.wagner@intevation.de> On Tuesday 16 December 2008 14:30:04 Felix Wolfsteller wrote: > I would like new votes for Change Request #19 ("Style") > (http://www.openvas.org/openvas-cr-19.html). > > As more arguments have been issued for an existing standard (GNU), which > was already mentioned in the compendium than for anything else, your +1 > vote means: Obey GNU Coding Style and use doxygen comments in javadoc > style. (http://www.gnu.org/prep/standards/standards.html#Formatting) > and > (http://www.stack.nl/~dimitri/doxygen/). > Please note that the highlighted example on the webpage might not follow > all the rules (I tried an automatic formatter but gave up very fast), > please have a look at the reference if you want to be sure. > > If the voting "fails" I will issue new CRs that split the topic into > smaller bites. > > So far, use of doxygen seemed to be fine for everybody, so if you vote -1 > please give me at least a comment about doxygen. > > +1. good work. +1 from my side. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Wed Dec 17 08:08:34 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 17 Dec 2008 12:38:34 +0530 Subject: [Openvas-devel] Change Request #25: Integration of SAMBA/WMI toOpenVAS-nasl In-Reply-To: <200812161015.17823.jan-oliver.wagner@intevation.de> References: <81DF4EACE59142E0AEBB292025F55813@bchandra> <200812161015.17823.jan-oliver.wagner@intevation.de> Message-ID: -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Tuesday, December 16, 2008 2:45 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] Change Request #25: Integration of SAMBA/WMI toOpenVAS-nasl > Hello Chandra, On Montag, 15. Dezember 2008, Chandrashekhar B wrote: >> I have submitted a change request for integrating the features of SAMBA and/ >> WMI into OpenVAS space for having better API set for Windows based target >> systems. OpenVAS will be able to scan Windows Vista, 2008 and 2003 (in its >> default policy settings) in addition to having new set of API's. I seek your >> feedback on the approach discussed in the CR and suggest possible >> improvements. The CR is available at, >> >> http://www.openvas.org/openvas-cr-25.html > thanks for adessing this very important aspect! > I have a spontaneous question: Are high privileges > required to run the smb stuff or are lower privileges sufficient. > Note: What I am having in mind is a privilege downgrade for > openvasd in case of samba based tests to lower security problems. I think it can work as non-root, need to think through how openvasd can downgrade privileges. Most of the Windows checks will be Samba based tests. So whenever Windows based test is selected, openvasd has to identify that and run as non-root. I think it is going to be very complicated. Do you mean security problem because of an external library? Samba is an active project. We can look at the alternative approach I have proposed with WMI. Though it depends again on Samba, the code base it depends on is less. We can maintain that within Openvas space. Thanks, Chandra. From jan-oliver.wagner at intevation.de Wed Dec 17 11:12:55 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 17 Dec 2008 11:12:55 +0100 Subject: [Openvas-devel] Change Request #25: Integration of SAMBA/WMI toOpenVAS-nasl In-Reply-To: References: <81DF4EACE59142E0AEBB292025F55813@bchandra> <200812161015.17823.jan-oliver.wagner@intevation.de> Message-ID: <200812171112.57531.jan-oliver.wagner@intevation.de> Hi Chandra, On Mittwoch, 17. Dezember 2008, Chandrashekhar B wrote: > > I have a spontaneous question: Are high privileges > > required to run the smb stuff or are lower privileges sufficient. > > Note: What I am having in mind is a privilege downgrade for > > openvasd in case of samba based tests to lower security problems. > > I think it can work as non-root, need to think through how openvasd can > downgrade privileges. Michael implemented such a feature for OVAL because we did not want to execute ovaldi stuff with high privileges. So, IMHO it is doable. > Most of the Windows checks will be Samba based tests. > So whenever Windows based test is selected, openvasd has to identify that > and run as non-root. I think it is going to be very complicated. We have to think about it, but I am confident there is a nice solution. > Do you mean security problem because of an external library? Samba is an > active project. We can look at the alternative approach I have proposed with > WMI. Though it depends again on Samba, the code base it depends on is less. > We can maintain that within Openvas space. I have not finally settled with my minds about the options. Let's have some more opinions from the other experts here on this list ;-) 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 matt at mundell.ukfsn.org Wed Dec 17 12:03:31 2008 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 17 Dec 2008 11:03:31 GMT Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: Message of Tue, 16 Dec 2008 14:29:16 +0100. <200812161429.16248.felix.wolfsteller@intevation.de> Message-ID: <20081217105904.3C308DEE98@mail.ukfsn.org> > Thanks Matthew, > I have updated the CR (http://www.openvas.org/openvas-cr-19.html) to meet what > is adressed in the following. > I also included the three changes of your mail of thursday, 11th dec. > The file should now follow most of the GNU rules. Thanks, Felix. If there is agreement on CR 19, then there is the possibility of automatically reformatting the entire codebase. I think a single consistent style over all the code will improve development. For SVN histories, it sounds like the sooner this is done, the better. Perhaps a good opportunity would be immediately after 2.0.0? > I went with Jan-Olivers comment (@brief more self explanatory then double > star). OK, good. From matt at mundell.ukfsn.org Wed Dec 17 12:03:57 2008 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 17 Dec 2008 11:03:57 GMT Subject: [Openvas-devel] Call for votes CR#19: Agree on a style guideline and on a format for the documentation In-Reply-To: Message of Tue, 16 Dec 2008 14:30:04 +0100. <200812161430.04101.felix.wolfsteller@intevation.de> Message-ID: <20081217105930.15D33DEE98@mail.ukfsn.org> > I would like new votes for Change Request #19 ("Style") +1. From bchandra at secpod.com Wed Dec 17 12:01:44 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 17 Dec 2008 16:31:44 +0530 Subject: [Openvas-devel] Call for votes CR#19: Agree on a styleguideline and on a format for the documentation In-Reply-To: <20081217105930.15D33DEE98@mail.ukfsn.org> References: Message of Tue, 16 Dec 2008 14:30:04 +0100.<200812161430.04101.felix.wolfsteller@intevation.de> <20081217105930.15D33DEE98@mail.ukfsn.org> Message-ID: <5C712EF0B4174435A82746FF6A2D72C4@bchandra> +1 :) Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Matthew Mundell Sent: Wednesday, December 17, 2008 4:34 PM To: Felix Wolfsteller Cc: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] Call for votes CR#19: Agree on a styleguideline and on a format for the documentation > I would like new votes for Change Request #19 ("Style") +1. _______________________________________________ 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 Wed Dec 17 12:16:18 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 17 Dec 2008 12:16:18 +0100 Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: <20081217105904.3C308DEE98@mail.ukfsn.org> References: <20081217105904.3C308DEE98@mail.ukfsn.org> Message-ID: <200812171216.19033.felix.wolfsteller@intevation.de> (I understand your "Thanks" as +1) > If there is agreement on CR 19, then there is the possibility of > automatically reformatting the entire codebase. I think a single > consistent style over all the code will improve development. For SVN > histories, it sounds like the sooner this is done, the better. Perhaps a > good opportunity would be immediately after 2.0.0? Automation (and application of "new style" to "old" code) was debated (e.g. follow-ups of http://lists.wald.intevation.org/pipermail/openvas-devel/2008-November/001075.html and in IRC). So far, most people who commented that issue estimated that it brings more difficulties than benefits and should not be done or only under special circumstances. I think this discussion should be made indepent of CR#19. Maybe you want to open a new Change Request? -- 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 felix.wolfsteller at intevation.de Wed Dec 17 12:18:20 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 17 Dec 2008 12:18:20 +0100 Subject: [Openvas-devel] Call for votes CR#19: Agree on a style guideline and on a format for the documentation In-Reply-To: <20081217105930.15D33DEE98@mail.ukfsn.org> References: <20081217105930.15D33DEE98@mail.ukfsn.org> Message-ID: <200812171218.20866.felix.wolfsteller@intevation.de> > > I would like new votes for Change Request #19 ("Style") > > +1. got it. -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Wed Dec 17 12:44:09 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 17 Dec 2008 12:44:09 +0100 Subject: [Openvas-devel] Call for votes CR#19: Agree on a style guideline and on a format for the documentation In-Reply-To: <200812161430.04101.felix.wolfsteller@intevation.de> References: <200812161430.04101.felix.wolfsteller@intevation.de> Message-ID: <20081217114409.GD28795@intevation.de> * Felix Wolfsteller [16. Dec 2008]: > I would like new votes for Change Request #19 ("Style") +1 from me as well. 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 matt at mundell.ukfsn.org Wed Dec 17 13:58:53 2008 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 17 Dec 2008 12:58:53 GMT Subject: [Openvas-devel] Change Request 19: Style In-Reply-To: Message of Wed, 17 Dec 2008 12:16:18 +0100. <200812171216.19033.felix.wolfsteller@intevation.de> Message-ID: <20081217125425.73F66DEF31@mail.ukfsn.org> > (I understand your "Thanks" as +1) > > > If there is agreement on CR 19, then there is the possibility of > > automatically reformatting the entire codebase. I think a single > > consistent style over all the code will improve development. For SVN > > histories, it sounds like the sooner this is done, the better. Perhaps a > > good opportunity would be immediately after 2.0.0? > > Automation (and application of "new style" to "old" code) was debated > (e.g. follow-ups of > http://lists.wald.intevation.org/pipermail/openvas-devel/2008-November/001075.html > and in IRC). > > So far, most people who commented that issue estimated that it brings more > difficulties than benefits and should not be done or only under special > circumstances. I had looked through the mailing list discussion, at least. I guess I've taken the opinions too lightly. > > I think this discussion should be made indepent of CR#19. Yes, it's a separate, follow-on issue. > Maybe you want to open a new Change Request? Perhaps that should wait for the new year. From joey at infodrom.org Wed Dec 17 18:13:16 2008 From: joey at infodrom.org (Joey Schulze) Date: Wed, 17 Dec 2008 18:13:16 +0100 Subject: [Openvas-devel] OpenVAS-client Usability Improvements: Context Menus, Accellerators Message-ID: <20081217171316.GA25418@finlandia.home.infodrom.org> Hi, during work and use of the OpenVAS client I noticed several areas of future improvements. Here are three of them: 1. It would be nice if there would be a context menu (click with right mouse button) in the TreeView on the left and in the Report TreeView in the middle. The benefit is that there would be no need to move the mouse over large distances to reach certain functionalities. For the main TreeView the context menu could contain, among others, Execute, Connect, Delete when a particular report or scope is selected. 2. It would be nice if some functions would be reachable via proper accellerators. I would love to be able to remove a report from the archive by just pressing [Del] when the particular report is selected in the main TreeView. 3. It would be nice if reports in the main TreeView would be sorted by date, i.e. alphabetically. That would help finding an older report easier than now (reports seem to be displayed more or less unsorted (file system order, I'd guess)). 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 Dec 18 08:31:20 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 18 Dec 2008 08:31:20 +0100 Subject: [Openvas-devel] OpenVAS-client Usability Improvements: Context Menus, Accellerators In-Reply-To: <20081217171316.GA25418@finlandia.home.infodrom.org> References: <20081217171316.GA25418@finlandia.home.infodrom.org> Message-ID: <20081218073120.GA8854@intevation.de> * Martin Schulze [17. Dec 2008]: > Hi, > > during work and use of the OpenVAS client I noticed several areas of > future improvements. Here are three of them: > > 1. It would be nice if there would be a context menu (click with right > mouse button) in the TreeView on the left and in the Report > TreeView in the middle. > > 2. It would be nice if some functions would be reachable via proper > accellerators. Both good ideas. I'm not a Gtk expert, but implementing this should be pretty straightforward, shouldn't it? > 3. It would be nice if reports in the main TreeView would be sorted by > date, i.e. alphabetically. That would help finding an older report > easier than now (reports seem to be displayed more or less > unsorted (file system order, I'd guess)). I thought they were sorted, but feel free to prove me wrong. :) If this is the case, other user-selectable sorting schemes could be useful as well, don't you think? Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bitdealer at gmail.com Wed Dec 17 18:28:41 2008 From: bitdealer at gmail.com (Stephan Kleine) Date: Wed, 17 Dec 2008 18:28:41 +0100 Subject: [Openvas-devel] Today: Joined efford to solve autotools issues before 2.0.0 - please help Message-ID: Sorry for not responding earlier but I'm only subscribed to -packaging so I stumbled about it in the archive. Eric Gearhart wrote: > I agree - if no one else is reporting it maybe it's just a fluke in my > install and the other person's install... And that is why it happens in Fedora, Mandriva & openSUSE chroots that get setup & destroyed on demand and work just fine for thousands other packages? I'm sorry, but I beg to differ ... ;P Jan-Oliver Wagner wrote: > Michael and myself were not able to reproduce the problem nor > to fully understand it. That part surprised me a bit since it is actually very easy to reproduce if you use the build service as I explained before. But perhaps you missed it, so let me explain it once more: 1. Go to https://build.opensuse.org/ and create an account (I didn't receive a single spam / advertisement mail in all those years so it is safe). 2. Go to http://download.opensuse.org/repositories/openSUSE:/Tools/ and add the appropriate subdirectory as a repository and install "osc". 3. Run "osc co home:bitshuffler:openvas:unstable openvas-libraries" to get the project files 4. Run "cd home\:bitshuffler\:openvas\:unstable/openvas-libraries/" to get into the proper subdirectory 5. Run e.g. "osc build openSUSE_11.1 i586 openvas-libraries.spec" to build it for openSUSE 11.1 & i586 arch which will download all needed packages and install them into a chroot so your normal system will not be touched in any way. Total spent time <5 minutes (if you don't count the time needed for downloading packages). Perhaps that helps. regards, Stephan From bchandra at secpod.com Thu Dec 18 09:14:21 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 18 Dec 2008 13:44:21 +0530 Subject: [Openvas-devel] CR-23: Standardization of script_family Message-ID: <012054175C7A4178BED066DB209A50D1@bchandra> Hello, I have incorporated all the comments to CR-23, http://www.openvas.net/openvas-cr-23.html Please let me know if there's anything. We can put for final voting before implementing the suggested changes. Thanks, Chandra. From bchandra at secpod.com Thu Dec 18 09:15:50 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 18 Dec 2008 13:45:50 +0530 Subject: [Openvas-devel] Change Request #25: Integration of SAMBA/WMItoOpenVAS-nasl In-Reply-To: <200812171112.57531.jan-oliver.wagner@intevation.de> References: <81DF4EACE59142E0AEBB292025F55813@bchandra><200812161015.17823.jan-oliver.wagner@intevation.de> <200812171112.57531.jan-oliver.wagner@intevation.de> Message-ID: <8418C784B6804FD09A0C4C5DAACC6B3C@bchandra> More thoughts welcome... Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Wednesday, December 17, 2008 3:43 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] Change Request #25: Integration of SAMBA/WMItoOpenVAS-nasl Hi Chandra, On Mittwoch, 17. Dezember 2008, Chandrashekhar B wrote: > > I have a spontaneous question: Are high privileges > > required to run the smb stuff or are lower privileges sufficient. > > Note: What I am having in mind is a privilege downgrade for > > openvasd in case of samba based tests to lower security problems. > > I think it can work as non-root, need to think through how openvasd can > downgrade privileges. Michael implemented such a feature for OVAL because we did not want to execute ovaldi stuff with high privileges. So, IMHO it is doable. > Most of the Windows checks will be Samba based tests. > So whenever Windows based test is selected, openvasd has to identify that > and run as non-root. I think it is going to be very complicated. We have to think about it, but I am confident there is a nice solution. > Do you mean security problem because of an external library? Samba is an > active project. We can look at the alternative approach I have proposed with > WMI. Though it depends again on Samba, the code base it depends on is less. > We can maintain that within Openvas space. I have not finally settled with my minds about the options. Let's have some more opinions from the other experts here on this list ;-) Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From jan-oliver.wagner at intevation.de Thu Dec 18 09:31:25 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 18 Dec 2008 09:31:25 +0100 Subject: [Openvas-devel] CR-23: Standardization of script_family In-Reply-To: <012054175C7A4178BED066DB209A50D1@bchandra> References: <012054175C7A4178BED066DB209A50D1@bchandra> Message-ID: <200812180931.28595.jan-oliver.wagner@intevation.de> On Donnerstag, 18. Dezember 2008, Chandrashekhar B wrote: > I have incorporated all the comments to CR-23, > http://www.openvas.net/openvas-cr-23.html > > Please let me know if there's anything. We can put for final voting before > implementing the suggested changes. the Effects are still unclear. What happens to people who have configured some scopes and now get an updated feed with renamed families? Will the scope change in a way? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Thu Dec 18 10:17:58 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 18 Dec 2008 14:47:58 +0530 Subject: [Openvas-devel] CR-23: Standardization of script_family In-Reply-To: <200812180931.28595.jan-oliver.wagner@intevation.de> References: <012054175C7A4178BED066DB209A50D1@bchandra> <200812180931.28595.jan-oliver.wagner@intevation.de> Message-ID: -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Thursday, December 18, 2008 2:01 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] CR-23: Standardization of script_family On Donnerstag, 18. Dezember 2008, Chandrashekhar B wrote: >> I have incorporated all the comments to CR-23, >> http://www.openvas.net/openvas-cr-23.html >> >> Please let me know if there's anything. We can put for final voting before >> implementing the suggested changes. > the Effects are still unclear. What happens to people who have > configured some scopes and now get an updated feed with renamed > families? Will the scope change in a way? There's no binding either on the OpenVAS-Client or Server side. One possible scenario where things could change is, if someone has built a product or tool around OpenVAS and if they have hardcoded the family names. I can't think of any other scenario. Alternatively we will create only the new families and leave the existing families untouched. Thanks, Chandra. From michael.wiegand at intevation.de Thu Dec 18 10:19:48 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 18 Dec 2008 10:19:48 +0100 Subject: [Openvas-devel] Planning openvas-client 1.0.5 Message-ID: <20081218091948.GA13612@intevation.de> Hello, now that the 2.0.0 release is behind us I would like to do a quick maintenance release for Openvas 1.0.x, namely OpenVAS-Client 1.0.5. Two segfaults and two build issues have been fixed since 1.0.4 was released. Additionally, OpenVAS-Client 1.0.4 may claim to understand OTP/1.0 when trying to talk to an 2.0 series server when indeed it does not. I will look for other fixes in trunk which may be applicable to -client 1.0.4; feel free to point out other things that should be backported before the release. 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 Dec 18 10:59:37 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 18 Dec 2008 10:59:37 +0100 Subject: [Openvas-devel] osc In-Reply-To: References: Message-ID: <20081218095937.GB13612@intevation.de> * Stephan Kleine [18. Dec 2008]: > That part surprised me a bit since it is actually very easy to > reproduce if you use the build service as I explained before. But > perhaps you missed it, so let me explain it once more: > > 1. Go to https://build.opensuse.org/ and create an account (I didn't > receive a single spam / advertisement mail in all those years so it is > safe). > > 2. Go to http://download.opensuse.org/repositories/openSUSE:/Tools/ > and add the appropriate subdirectory as a repository and install > "osc". > > 3. Run "osc co home:bitshuffler:openvas:unstable openvas-libraries" to > get the project files > > 4. Run "cd home\:bitshuffler\:openvas\:unstable/openvas-libraries/" to > get into the proper subdirectory > > 5. Run e.g. "osc build openSUSE_11.1 i586 openvas-libraries.spec" to > build it for openSUSE 11.1 & i586 arch which will download all needed > packages and install them into a chroot so your normal system will not > be touched in any way. > > Total spent time <5 minutes (if you don't count the time needed for > downloading packages). Well, that is what I tried, but I was unable to use osc the way you described it. I am using an Debian Etch test system and got up to step 5, but then osc downloads 3 or 4 packages and fails with "Error: No more mirrors to try." This happens with a number of different packages, subsequent calls to osc download 3 or 4 other packages and then fail the same way. Once it runs out of files to download (or so I guess) it fails with a python error and refuses to launch. Osc indeed sounds like a useful tool and I would love to use it to debug the issue, but I simply don't have the time to debug the issues osc seems to have with its own build system. If there is an easy fix for the osc issues I described above, please do let me know and I will gladly use it. Thanks! Regards, Michael P.S.: The python error thrown by osc yields the following traceback: Verifying integrity of cached packages Traceback (most recent call last): File "/usr/bin/osc", line 12, in ? r = babysitter.run(osccli) File "/usr/lib/python2.4/site-packages/osc/babysitter.py", line 40, in run return prg.main() File "/usr/lib/python2.4/site-packages/osc/cmdln.py", line 256, in main return self.cmd(args) File "/usr/lib/python2.4/site-packages/osc/cmdln.py", line 279, in cmd retval = self.onecmd(argv) File "/usr/lib/python2.4/site-packages/osc/cmdln.py", line 395, in onecmd return self._dispatch_cmd(handler, argv) File "/usr/lib/python2.4/site-packages/osc/cmdln.py", line 1070, in _dispatch_cmd return handler(argv[0], opts, *args) File "/usr/lib/python2.4/site-packages/osc/commandline.py", line 1937, in do_build return osc.build.main(opts, args) File "/usr/lib/python2.4/site-packages/osc/build.py", line 390, in main verify_pacs([ i.fullfilename for i in bi.deps ]) File "/usr/lib/python2.4/site-packages/osc/fetch.py", line 150, in verify_pacs stderr=subprocess.STDOUT, close_fds=True).stdout File "/usr/lib/python2.4/subprocess.py", line 543, in __init__ errread, errwrite) File "/usr/lib/python2.4/subprocess.py", line 975, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory -- 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 Thu Dec 18 11:03:10 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 18 Dec 2008 11:03:10 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <4d7b043c0812142326t496a8562q2c4dd9184a0a3701@mail.gmail.com> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <200812142158.34423.jan-oliver.wagner@intevation.de> <4d7b043c0812142326t496a8562q2c4dd9184a0a3701@mail.gmail.com> Message-ID: <200812181103.13190.jan-oliver.wagner@intevation.de> Hi Stjepan, On Montag, 15. Dezember 2008, Stjepan Gros wrote: > On Sun, Dec 14, 2008 at 9:58 PM, Jan-Oliver Wagner > > Wouldn't another solution option be to reorganize the caching as such > > to be based on OIDs instead of names? > > That is the idea. The problem is that plugins themselves, as source > files, are stored in files with descriptive names. Now, when you know > the name of the plugin on a disk, you don't know it's OID until you > read and parse it. > > For easier understanding I'll describe this process now, and how it is > planned to be implemented, on a plugin named plugin.nasl with an OID > 1.2.3.4.5.6.7.8 >... > > Did I better explain the problem? yes, that helped me to make up my mind: It is probably best to have the cachedir be a 1:1 mirror of the plugindir: $PLUGINDIR/script.nasl is cached to $CACHEDIR/script.desc and in the future: $PLUGINDIR/script.nasl $PLUGINDIR/myfamily/script2.nasl to $CACHEDIR/script.desc $CACHEDIR/myfamily/script2.nasl The background idea is to not invent a second organizational structure, but rather use the same one. 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 joey at infodrom.org Thu Dec 18 11:20:46 2008 From: joey at infodrom.org (Joey Schulze) Date: Thu, 18 Dec 2008 11:20:46 +0100 Subject: [Openvas-devel] OpenVAS-client Usability Improvements: Context Menus, Accellerators In-Reply-To: <20081218073120.GA8854@intevation.de> References: <20081217171316.GA25418@finlandia.home.infodrom.org> <20081218073120.GA8854@intevation.de> Message-ID: <20081218102046.GN24968@finlandia.home.infodrom.org> Michael Wiegand wrote: > * Martin Schulze [17. Dec 2008]: > > Hi, > > > > during work and use of the OpenVAS client I noticed several areas of > > future improvements. Here are three of them: > > > > 1. It would be nice if there would be a context menu (click with right > > mouse button) in the TreeView on the left and in the Report > > TreeView in the middle. > > > > 2. It would be nice if some functions would be reachable via proper > > accellerators. > > Both good ideas. I'm not a Gtk expert, but implementing this should be > pretty straightforward, shouldn't it? Yes. No magic required. > > 3. It would be nice if reports in the main TreeView would be sorted by > > date, i.e. alphabetically. That would help finding an older report > > easier than now (reports seem to be displayed more or less > > unsorted (file system order, I'd guess)). > > I thought they were sorted, but feel free to prove me wrong. :) If this > is the case, other user-selectable sorting schemes could be useful as > well, don't you think? Yes. 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 joey at infodrom.org Thu Dec 18 21:58:07 2008 From: joey at infodrom.org (Joey Schulze) Date: Thu, 18 Dec 2008 21:58:07 +0100 Subject: [Openvas-devel] Problem with SVN HEAD OpenVAS-Client Message-ID: <20081218205807.GE27470@finlandia.home.infodrom.org> Hi, when I start OpenVAS-client from the most recent SVN HEAD I receive the following output on the console and don't get any useful Report: http://paste.debian.net/24000 (valid for 72 hours) Did something break recently? What makes me wonder is that an older checkout works fine. 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 michael.wiegand at intevation.de Fri Dec 19 09:11:12 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Fri, 19 Dec 2008 09:11:12 +0100 Subject: [Openvas-devel] Problem with SVN HEAD OpenVAS-Client In-Reply-To: <20081218205807.GE27470@finlandia.home.infodrom.org> References: <20081218205807.GE27470@finlandia.home.infodrom.org> Message-ID: <20081219081112.GA16832@intevation.de> * Martin Schulze [18. Dec 2008]: > Hi, > > when I start OpenVAS-client from the most recent SVN HEAD I receive the > following output on the console and don't get any useful Report: > > http://paste.debian.net/24000 (valid for 72 hours) > > Did something break recently? > > What makes me wonder is that an older checkout works fine. I just tried to reproduce the issue you described with SVN HEAD and did not notice anything unusual. From the looks of it, I would say either your client NVT cache or the server cache were generated by an older version or became corrupted. There were some minor changes in the way the preferences are send by the server during the last weeks, this might confuse your client. I would suggest deleting your cache and thus forcing the client to rebuild its cache. Let me know if this resolves your 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 sgros.ml at gmail.com Fri Dec 19 09:21:31 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Fri, 19 Dec 2008 09:21:31 +0100 Subject: [Openvas-devel] Change Request #24: OpenVAS-Server: Reorganize NVTs in Subdirectories In-Reply-To: <200812181103.13190.jan-oliver.wagner@intevation.de> References: <4d7b043c0812061152l63c61896jbf32a3c7497b0b1f@mail.gmail.com> <200812142158.34423.jan-oliver.wagner@intevation.de> <4d7b043c0812142326t496a8562q2c4dd9184a0a3701@mail.gmail.com> <200812181103.13190.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0812190021i2170f04er71527ae00b12348@mail.gmail.com> On Thu, Dec 18, 2008 at 11:03 AM, Jan-Oliver Wagner wrote: > Hi Stjepan, > > On Montag, 15. Dezember 2008, Stjepan Gros wrote: >> On Sun, Dec 14, 2008 at 9:58 PM, Jan-Oliver Wagner >> > Wouldn't another solution option be to reorganize the caching as such >> > to be based on OIDs instead of names? >> >> That is the idea. The problem is that plugins themselves, as source >> files, are stored in files with descriptive names. Now, when you know >> the name of the plugin on a disk, you don't know it's OID until you >> read and parse it. >> >> For easier understanding I'll describe this process now, and how it is >> planned to be implemented, on a plugin named plugin.nasl with an OID >> 1.2.3.4.5.6.7.8 >>... >> >> Did I better explain the problem? > > yes, that helped me to make up my mind: > > It is probably best to have the cachedir be a 1:1 mirror of the > plugindir: > > $PLUGINDIR/script.nasl > is cached to > $CACHEDIR/script.desc > > and in the future: > > $PLUGINDIR/script.nasl > $PLUGINDIR/myfamily/script2.nasl > to > $CACHEDIR/script.desc > $CACHEDIR/myfamily/script2.nasl > > The background idea is to not invent a second organizational structure, > but rather use the same one. Ok, I'll use that one then. Probably I'll start coding over the weekend so I'll have the first patch available next week. SG From sgros.ml at gmail.com Fri Dec 19 09:23:34 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Fri, 19 Dec 2008 09:23:34 +0100 Subject: [Openvas-devel] Few questions about the code... In-Reply-To: <200812152239.37220.jan-oliver.wagner@intevation.de> References: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> <-5891970929835685261@unknownmsgid> <4d7b043c0812142330x125f871y3c05da92944165e3@mail.gmail.com> <200812152239.37220.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0812190023h6d26cadn612c46e3a123e07f@mail.gmail.com> On Mon, Dec 15, 2008 at 10:39 PM, Jan-Oliver Wagner wrote: > On Monday 15 December 2008 08:30:48 Stjepan Gros wrote: >> On Sun, Dec 14, 2008 at 9:13 PM, Jan-Oliver Wagner >> wrote: >> > On Sunday 14 December 2008 10:52:27 Stjepan Gros wrote: >> >> 1. Who/where/when and why sets and uses ENABLE_PLUGIN_SERVER. I >> >> grep'ed through the code and it's only used, not defined anywere!? >> >> >> >> 2. The consequence of 1 is that "cache_dir" is never used (it's in >> >> plugins directory, .bin subdirectory) and that cache I'm talking about >> >> in CR is differently set. >> > >> > I think you spotted yet another portion of code that is unused. >> > I found no place where the "Plugin Server" is enabled or even used. >> > I also fail to understand the code (badly documented) nor can I >> > imagine any reason why a "plugin server" should make sense. >> > >> > Does anyone else have an idea about this feature? >> >> If no one has argument to leave this code in, I can generate a patch >> to remove it. This should be fairly easy to do. > > I digged into this further and started to remove it. > It is not so easy as thought initially. > Re-inventing the wheel 3 times in a row sometimes characterizes > the code base ;-) > Will you commit that soon? As I said, the cache_dir variable is misleading and pointless and thus I'm going to reuse it to modify behavior of openvas. Now, either you have to commit this before I start coding, or I'll do it as a part of a first patch. SG From joey at infodrom.org Fri Dec 19 09:35:35 2008 From: joey at infodrom.org (Joey Schulze) Date: Fri, 19 Dec 2008 09:35:35 +0100 Subject: [Openvas-devel] OpenVAS-client Usability Improvements: Context Menus, Accellerators In-Reply-To: <20081218102046.GN24968@finlandia.home.infodrom.org> References: <20081217171316.GA25418@finlandia.home.infodrom.org> <20081218073120.GA8854@intevation.de> <20081218102046.GN24968@finlandia.home.infodrom.org> Message-ID: <20081219083535.GA20051@finlandia.home.infodrom.org> Joey Schulze wrote: > > > 3. It would be nice if reports in the main TreeView would be sorted by > > > date, i.e. alphabetically. That would help finding an older report > > > easier than now (reports seem to be displayed more or less > > > unsorted (file system order, I'd guess)). > > > > I thought they were sorted, but feel free to prove me wrong. :) If this Does the TreeView in the attached screenshot snippet look sorted? 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 -------------- A non-text attachment was scrubbed... Name: openvas-treeview.png Type: image/png Size: 23031 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081219/3cf04f73/openvas-treeview-0001.png From michael.wiegand at intevation.de Fri Dec 19 09:54:01 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Fri, 19 Dec 2008 09:54:01 +0100 Subject: [Openvas-devel] OpenVAS-client Usability Improvements: Context Menus, Accellerators In-Reply-To: <20081219083535.GA20051@finlandia.home.infodrom.org> References: <20081217171316.GA25418@finlandia.home.infodrom.org> <20081218073120.GA8854@intevation.de> <20081218102046.GN24968@finlandia.home.infodrom.org> <20081219083535.GA20051@finlandia.home.infodrom.org> Message-ID: <20081219085401.GB16832@intevation.de> * Martin Schulze [19. Dec 2008]: > > > I thought they were sorted, but feel free to prove me wrong. :) If this > > Does the TreeView in the attached screenshot snippet look sorted? I guess not. :) 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 Fri Dec 19 11:40:56 2008 From: joey at infodrom.org (Joey Schulze) Date: Fri, 19 Dec 2008 11:40:56 +0100 Subject: [Openvas-devel] OpenVAS-client Usability Improvements: Expand all reports Message-ID: <20081219104056.GB25418@finlandia.home.infodrom.org> Hi, another issue that I notice frequently when I want to read a report in the Client is that I have to click on each and every port and priority to have the associated output displayed. It would be nice if there would be an "expand all" and "collapse all" button in the right report TreeView. It may also be a good idea if the text associated with the port would contain information about found vulnerabilities for this particular port without having to expand all priorities. (both ideas could be orthogonal) 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 Fri Dec 19 11:37:19 2008 From: joey at infodrom.org (Joey Schulze) Date: Fri, 19 Dec 2008 11:37:19 +0100 Subject: [Openvas-devel] Problem with SVN HEAD OpenVAS-Client In-Reply-To: <20081219081112.GA16832@intevation.de> References: <20081218205807.GE27470@finlandia.home.infodrom.org> <20081219081112.GA16832@intevation.de> Message-ID: <20081219103719.GJ24968@finlandia.home.infodrom.org> Moin! Michael Wiegand wrote: > > when I start OpenVAS-client from the most recent SVN HEAD I receive the > > following output on the console and don't get any useful Report: > > > > http://paste.debian.net/24000 (valid for 72 hours) > > > > Did something break recently? > > > > What makes me wonder is that an older checkout works fine. > > I just tried to reproduce the issue you described with SVN HEAD and did > not notice anything unusual. > > From the looks of it, I would say either your client NVT cache or the > server cache were generated by an older version or became corrupted. Removing the client cache openvas_nvt_cache in the scope directory results new messages... "Could not parse script id..." > There were some minor changes in the way the preferences are send by the > server during the last weeks, this might confuse your client. The server is 2.0.0.beta1-1 from November, not current SVN HEAD. Could that be the reason? The older client that works is from the same time but has received several updates. > I would suggest deleting your cache and thus forcing the client to > rebuild its cache. Let me know if this resolves your issue. If you refer to openvas_nvt_cache in the scope directory, then this does not yet help. Here's the stdout/stderr output http://paste.debian.net/24034 (4MB, beware) Regards, Joey -- A mathematician is a machine for converting coffee into theorems. Paul Erd?s From michael.wiegand at intevation.de Fri Dec 19 11:56:05 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Fri, 19 Dec 2008 11:56:05 +0100 Subject: [Openvas-devel] Problem with SVN HEAD OpenVAS-Client In-Reply-To: <20081219103719.GJ24968@finlandia.home.infodrom.org> References: <20081218205807.GE27470@finlandia.home.infodrom.org> <20081219081112.GA16832@intevation.de> <20081219103719.GJ24968@finlandia.home.infodrom.org> Message-ID: <20081219105605.GD16832@intevation.de> * Martin Schulze [19. Dec 2008]: > The server is 2.0.0.beta1-1 from November, not current SVN HEAD. > Could that be the reason? The older client that works is from the > same time but has received several updates. Yes, this is most likely the reason. There were several changes to the communication protocol and the available plugin information, so the 2.0.0 client is not expected to be compatible to 2.0-beta1. I would recommend that you upgrade your server to OpenVAS 2.0.0. 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 Fri Dec 19 12:08:37 2008 From: joey at infodrom.org (Joey Schulze) Date: Fri, 19 Dec 2008 12:08:37 +0100 Subject: [Openvas-devel] Problem with SVN HEAD OpenVAS-Client In-Reply-To: <20081219105605.GD16832@intevation.de> References: <20081218205807.GE27470@finlandia.home.infodrom.org> <20081219081112.GA16832@intevation.de> <20081219103719.GJ24968@finlandia.home.infodrom.org> <20081219105605.GD16832@intevation.de> Message-ID: <20081219110837.GL24968@finlandia.home.infodrom.org> Michael Wiegand wrote: > * Martin Schulze [19. Dec 2008]: > > The server is 2.0.0.beta1-1 from November, not current SVN HEAD. > > Could that be the reason? The older client that works is from the > > same time but has received several updates. > > Yes, this is most likely the reason. There were several changes to the > communication protocol and the available plugin information, so the > 2.0.0 client is not expected to be compatible to 2.0-beta1. > > I would recommend that you upgrade your server to OpenVAS 2.0.0. Ok. Thanks. Will do. Will report if that doesn't suffice. 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 Fri Dec 19 15:13:48 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Fri, 19 Dec 2008 15:13:48 +0100 Subject: [Openvas-devel] OpenVAS-client Usability Improvements In-Reply-To: <20081219104056.GB25418@finlandia.home.infodrom.org> References: <20081219104056.GB25418@finlandia.home.infodrom.org> Message-ID: <20081219141348.GF16832@intevation.de> * Martin Schulze [19. Dec 2008]: > Hi, > > another issue that I notice frequently when I want to read a report in > the Client is that I have to click on each and every port and priority > to have the associated output displayed. > > It would be nice if there would be an "expand all" and "collapse all" > button in the right report TreeView. Sounds useful to me. You seem to have a lot of good ideas for the client GUI, it might be a good idea to collect them in a change request so they don't get buried in the mailing list. What do you think? Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From hanno at hboeck.de Sat Dec 20 23:30:47 2008 From: hanno at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=) Date: Sat, 20 Dec 2008 23:30:47 +0100 Subject: [Openvas-devel] [PATCH] openvas-libraries: Respect LDFLAGS Message-ID: <200812202330.47549.hanno@hboeck.de> Hi, The Makefiles of openvas-libraries-2.0.0 don't respect LDFLAGS, attached patch will fix that. Please apply. cu, -- Hanno B?ck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno at hboeck.de http://www.jukss.de/ Jugemdumweltkongress, 27.12.-4.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-libraries-2.0.0-ldflags.diff Type: text/x-diff Size: 1647 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081220/50e9d1d9/openvas-libraries-2.0.0-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/20081220/50e9d1d9/attachment.pgp From hanno at hboeck.de Sat Dec 20 23:36:49 2008 From: hanno at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=) Date: Sat, 20 Dec 2008 23:36:49 +0100 Subject: [Openvas-devel] [PATCH] openvas-server: respect LDFLAGS Message-ID: <200812202336.49863.hanno@hboeck.de> The Makefiles of openvas-server-2.0.0 don't respect LDFLAGS, attached patch will fix that. Please apply. -- Hanno B?ck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno at hboeck.de http://www.jukss.de/ Jugemdumweltkongress, 27.12.-4.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-server-2.0.0-ldflags.diff Type: text/x-diff Size: 893 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081220/855e8aba/openvas-server-2.0.0-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/20081220/855e8aba/attachment.pgp From hanno at hboeck.de Sat Dec 20 23:38:31 2008 From: hanno at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=) Date: Sat, 20 Dec 2008 23:38:31 +0100 Subject: [Openvas-devel] [PATCH] openvas-server: remove unneeded gpgme.h include Message-ID: <200812202338.32014.hanno@hboeck.de> Hi, A file in openvas-server (otp_1_0.c) references gpgme.h, but it's never used. Also there's no other reference in the whole source to gpgme. I noticed a compilation failure because it didn't find gpgme.h (it was in the subdir /usr/include/gpgme/), but the "fix" seems to just remove it, as it isn't used anyway. Attached patch does that, please apply. cu, -- Hanno B?ck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno at hboeck.de http://www.jukss.de/ Jugemdumweltkongress, 27.12.-4.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-server-2.0.0-remove-useless-gpgme.diff Type: text/x-diff Size: 314 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081220/1f05039c/openvas-server-2.0.0-remove-useless-gpgme.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/20081220/1f05039c/attachment.pgp From timb at nth-dimension.org.uk Sun Dec 21 00:18:19 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Sat, 20 Dec 2008 23:18:19 +0000 Subject: [Openvas-devel] [PATCH] openvas-libraries: Respect LDFLAGS In-Reply-To: <200812202330.47549.hanno@hboeck.de> References: <200812202330.47549.hanno@hboeck.de> Message-ID: <200812202318.20034.timb@nth-dimension.org.uk> On Saturday 20 December 2008 22:30:47 Hanno B?ck wrote: > Hi, > > The Makefiles of openvas-libraries-2.0.0 don't respect LDFLAGS, attached > patch will fix that. Please apply. > > cu, Thanks Hanno, I've committed both your LDFLAGS patches to trunk. Tim -- Tim Brown From hanno at hboeck.de Sun Dec 21 00:41:23 2008 From: hanno at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=) Date: Sun, 21 Dec 2008 00:41:23 +0100 Subject: [Openvas-devel] [PATCH] openvas-libnasl: respect LDFLAGS Message-ID: <200812210041.23920.hanno@hboeck.de> Another ldflags patch -- Hanno B?ck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno at hboeck.de http://www.jukss.de/ Jugemdumweltkongress, 27.12.-4.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-libnasl-2.0.0-ldflags.diff Type: text/x-diff Size: 1199 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081221/29727f42/openvas-libnasl-2.0.0-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/20081221/29727f42/attachment.pgp From sgros.ml at gmail.com Sun Dec 21 23:45:33 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Sun, 21 Dec 2008 23:45:33 +0100 Subject: [Openvas-devel] Patch to move cache - try 1 Message-ID: <4d7b043c0812211445i6d219112t2cd5576abf6ca61d@mail.gmail.com> This wasn't so easy. I _think_ this works, but I didn't yet tested enough, and also, there is a catch. If you try to make subdirectories inside plugins directory it'll complain that it can not find include files. This can not be solved without introducing include directories, what I'll do in the next few days. Also, my intention to keep things compatible with the previous installations/versions (meaning, if you don't specify cache_folder in conf. file that everything behaves as before) complicates things a bit, but not so drastically. For a record, I implemented the version where directory structure within plugins subdirectory is mirrored into cache directory. Thus, there is no OID based hierarchy. What I tested for now, are the following two test cases: - specified cache_folder with flat plugin directory structure and started openvasd several times - no cache_folder and flat plugin directory then started openvasd several times but I didn't try to run the client yet. The main problem with the introduction of the cache directory is that it's hardcoded in, at least, two places. First, some functions inside store.c themselves construct path by adding ".desc" on the plugins directory, while the other use variable "sys_store_dir" which has the same value. It doesn't seem necessary to be so, but this has to be discussed. Additionaly, the functionality can be placed in several places and it's hard to determine the best one based on the partial knowledge of openvas I have. And, finally, two notes. First, it seems that when openvasd server sends the client data about plugins, for several attributes that are sent, it reads disk and loads cached version of a plugin for each attribute. I didn't investigate it further, but maybe someone can say more about that. The execution path is send_plug_info -> plug_get_{version,cve_id,bugtraq_id,xref,tag,family,summary,description,copyright} -> store_fetch_{...} -> store_get_plugin (which reads cached plugin). The second note is about plugin directory organization. Since nes, oval and nasl plugins are automatically handled, maybe it would be beneficial for readability purpose to create three directories within the top level plugins directory, one for each type of plugin (nasl, oval, nes)? Ok, that's it, I hope I didn't mess something because it's late and I'm tired... :) SG -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-cache-v00.patch Type: text/x-patch Size: 47781 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081221/01a890f0/openvas-cache-v00-0001.bin From jan-oliver.wagner at intevation.de Mon Dec 22 10:49:59 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 22 Dec 2008 10:49:59 +0100 Subject: [Openvas-devel] Few questions about the code... In-Reply-To: <4d7b043c0812190023h6d26cadn612c46e3a123e07f@mail.gmail.com> References: <4d7b043c0812140152g34352af3la090a321010e3e2e@mail.gmail.com> <200812152239.37220.jan-oliver.wagner@intevation.de> <4d7b043c0812190023h6d26cadn612c46e3a123e07f@mail.gmail.com> Message-ID: <200812221049.59421.jan-oliver.wagner@intevation.de> On Friday 19 December 2008 09:23:34 Stjepan Gros wrote: > On Mon, Dec 15, 2008 at 10:39 PM, Jan-Oliver Wagner > > I digged into this further and started to remove it. > > It is not so easy as thought initially. > > Re-inventing the wheel 3 times in a row sometimes characterizes > > the code base ;-) > > Will you commit that soon? As I said, the cache_dir variable is > misleading and pointless and thus I'm going to reuse it to modify > behavior of openvas. Now, either you have to commit this before I > start coding, or I'll do it as a part of a first patch. All removed already before the 2.0.0 release :-) Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Thu Dec 18 15:31:00 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 18 Dec 2008 15:31:00 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B855=5D_Doesn=27t_b?= =?utf-8?q?uild_with_=22configure_--disable-static=22?= Message-ID: <20081218143100.12ED5407CC@pyrosoma.intevation.org> Bugs item #855, was opened at 2008-12-18 14:31 Status: Open Priority: 3 Submitted By: Stephan Kleine (bitshuffler) Assigned to: Nobody (None) Summary: Doesn't build with "configure --disable-static" Resolution: None Severity: None Version: v2.0 Component: openvas-libnasl Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: If "--disable-static" is added to the configure flags the build fails (without --disable-static it builds just fine): ----------------------------------------------------------------- ----- building openvas-libnasl.spec (user abuild) ----------------------------------------------------------------- ----------------------------------------------------------------- + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --eval %suse_insert_debug_package /usr/src/packages/SOURCES/openvas-libnasl.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.7167 + umask 022 + cd /usr/src/packages/BUILD + cd /usr/src/packages/BUILD + rm -rf openvas-libnasl-2.0.0 + /usr/bin/bzip2 -dc /usr/src/packages/SOURCES/openvas-libnasl-2.0.0.tar.bz2 + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd openvas-libnasl-2.0.0 ++ /usr/bin/id -u + '[' 399 = 0 ']' ++ /usr/bin/id -u + '[' 399 = 0 ']' + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.7167 + umask 022 + cd /usr/src/packages/BUILD + /bin/rm -rf /var/tmp/openvas-libnasl-2.0.0-build ++ dirname /var/tmp/openvas-libnasl-2.0.0-build + /bin/mkdir -p /var/tmp + /bin/mkdir /var/tmp/openvas-libnasl-2.0.0-build + cd openvas-libnasl-2.0.0 + CFLAGS='-march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g' + export CFLAGS + CXXFLAGS='-march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g' + export CXXFLAGS + FFLAGS='-march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g' + export FFLAGS + ./configure --host=i686-suse-linux-gnu --build=i686-suse-linux-gnu --target=i586-suse-linux --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-static checking for i686-suse-linux-gnu-gcc... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking build system type... i686-suse-linux-gnu checking host system type... i686-suse-linux-gnu checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by gcc... /usr/i586-suse-linux/bin/ld checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes checking for /usr/i586-suse-linux/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for i686-suse-linux-gnu-g++... no checking for i686-suse-linux-gnu-c++... no checking for i686-suse-linux-gnu-gpp... no checking for i686-suse-linux-gnu-aCC... no checking for i686-suse-linux-gnu-CC... no checking for i686-suse-linux-gnu-cxx... no checking for i686-suse-linux-gnu-cc++... no checking for i686-suse-linux-gnu-cl.exe... no checking for i686-suse-linux-gnu-FCC... no checking for i686-suse-linux-gnu-KCC... no checking for i686-suse-linux-gnu-RCC... no checking for i686-suse-linux-gnu-xlC_r... no checking for i686-suse-linux-gnu-xlC... no checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl.exe... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking for i686-suse-linux-gnu-g77... no checking for i686-suse-linux-gnu-xlf... no checking for i686-suse-linux-gnu-f77... no checking for i686-suse-linux-gnu-frt... no checking for i686-suse-linux-gnu-pgf77... no checking for i686-suse-linux-gnu-cf77... no checking for i686-suse-linux-gnu-fort77... no checking for i686-suse-linux-gnu-fl32... no checking for i686-suse-linux-gnu-af77... no checking for i686-suse-linux-gnu-xlf90... no checking for i686-suse-linux-gnu-f90... no checking for i686-suse-linux-gnu-pgf90... no checking for i686-suse-linux-gnu-pghpf... no checking for i686-suse-linux-gnu-epcf90... no checking for i686-suse-linux-gnu-gfortran... no checking for i686-suse-linux-gnu-g95... no checking for i686-suse-linux-gnu-xlf95... no checking for i686-suse-linux-gnu-f95... no checking for i686-suse-linux-gnu-fort... no checking for i686-suse-linux-gnu-ifort... no checking for i686-suse-linux-gnu-ifc... no checking for i686-suse-linux-gnu-efc... no checking for i686-suse-linux-gnu-pgf95... no checking for i686-suse-linux-gnu-lf95... no checking for i686-suse-linux-gnu-ftn... no checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for i686-suse-linux-gnu-ar... no checking for ar... ar checking for i686-suse-linux-gnu-ranlib... no checking for ranlib... ranlib checking for i686-suse-linux-gnu-strip... no checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/i586-suse-linux/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool appending configuration tag "F77" to libtool checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking if the compiler understands -pipe... yes checking for libopenvas-config... /usr/bin/libopenvas-config checking for gpgme-config... /usr/bin/gpgme-config checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGEFILE_SOURCE value needed for large files... no checking for off_t... yes checking for i686-suse-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for GLIB... yes checking for bison... /usr/bin/bison checking for ANSI C header files... (cached) yes checking for sys/wait.h that is POSIX.1 compatible... yes checking whether time.h and sys/time.h may both be included... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for main in -lrpcsvc... yes checking /usr/ucbinclude/fcntl.h usability... no checking /usr/ucbinclude/fcntl.h presence... no checking for /usr/ucbinclude/fcntl.h... no checking for unistd.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sys/sockio.h usability... no checking sys/sockio.h presence... no checking for sys/sockio.h... no checking sys/socketio.h usability... no checking sys/socketio.h presence... no checking for sys/socketio.h... no checking for netinet/in.h... yes checking for netinet/in_systm.h... yes checking for netinet/ip.h... yes checking for netinet/ip_icmp.h... yes checking for netinet/ip.h... (cached) yes checking for netinet/udp.h... no checking for netinet/protocols.h... no checking for netinet/ip_udp.h... no checking for netinet/ip_tcp.h... no checking for netinet/tcpip.h... no checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking rpc/rpc.h usability... yes checking rpc/rpc.h presence... yes checking for rpc/rpc.h... yes checking for dlfcn.h... (cached) yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking for memory.h... (cached) yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking for sys/types.h... (cached) yes checking for stdlib.h... (cached) yes checking stdio.h usability... yes checking stdio.h presence... yes checking for stdio.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking sys/filio.h usability... no checking sys/filio.h presence... no checking for sys/filio.h... no checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking assert.h usability... yes checking assert.h presence... yes checking for assert.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking for netinet/in.h... (cached) yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking for netinet/ip_tcp.h... (cached) no checking for sys/stat.h... (cached) yes checking stat.h usability... no checking stat.h presence... no checking for stat.h... no checking net/if.h usability... yes checking net/if.h presence... yes checking for net/if.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking search.h usability... yes checking search.h presence... yes checking for search.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for netinet/ip.h... (cached) yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking for working alloca.h... yes checking for alloca... yes checking for lstat... yes checking for memmove... yes checking for gettimeofday... yes checking for gethrtime... no checking for getrusage... yes checking for rand... yes checking for strchr... yes checking for memcpy... yes checking for select... yes checking for poll... yes checking for vsnprintf... yes checking for memmem... yes checking for bzero... yes checking for bcopy... yes checking for addr2ascii... no checking for inet_neta... no checking for signal... yes checking for sigaction... yes checking for wait... yes checking for wait3... yes checking for wait4... yes checking for waitpid... yes checking for lfind... yes checking for lfind in -lcompat... no checking whether byte ordering is bigendian... no checking for time_t... yes checking for pid_t... yes checking for size_t... yes checking for uid_t in sys/types.h... yes checking for short... yes checking size of short... 2 checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking struct ip contains ip_csum... no checking struct ip... yes checking struct ip has ip_hl... yes checking struct icmp... yes checking struct udphdr... yes checking BSD struct udphdr... yes checking struct tcphdr... yes checking struct tcphdr has th_off... yes checking struct tcphdr has th_x2_off... no checking for long file names... yes checking for inet_aton in -lc... yes checking for inet_aton in -lresolv... yes checking for inet_aton in -lsocket... no checking for inet_aton in -lnsl... yes checking if sockaddr{} has sa_len member... no checking for a working strndup implementation... no configure: creating ./config.status config.status: creating nasl.tmpl config.status: creating openvas-libnasl-config config.status: creating include/config.h + /usr/bin/make cd nasl && /usr/bin/make make[1]: Entering directory `/usr/src/packages/BUILD/openvas-libnasl-2.0.0/nasl' /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_packet_forgery.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_socket.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_crypto.c nasl_crypto.c: In function 'nasl_gcrypt_hash': nasl_crypto.c:76: warning: pointer targets in passing argument 1 of 'nasl_strndup' differ in signedness /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c -DNESSUS_STATE_DIR=\"/var\" nasl_crypto2.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_http.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_host.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_text_utils.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_nessusd_glue.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_misc_funcs.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c -DNESSUS_STATE_DIR=\"/var\" nasl_cmd_exec.c nasl_cmd_exec.c: In function 'nasl_fwrite': nasl_cmd_exec.c:412: warning: ignoring return value of 'ftruncate', declared with attribute warn_unused_result /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c capture_packet.c bison -d -v -t -p nasl nasl_grammar.y /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_grammar.tab.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_tree.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_var.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c exec.c exec.c: In function 'execute_nasl_script': exec.c:1735: warning: ignoring return value of 'getcwd', declared with attribute warn_unused_result exec.c:1756: warning: ignoring return value of 'chdir', declared with attribute warn_unused_result exec.c:1767: warning: ignoring return value of 'chdir', declared with attribute warn_unused_result exec.c:1852: warning: ignoring return value of 'chdir', declared with attribute warn_unused_result /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c lint.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_lex_ctxt.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_func.c nasl_func.c: In function 'insert_nasl_func': nasl_func.c:100: warning: passing argument 4 of 'qsort' from incompatible pointer type /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c -DVERSION=\"2.0.0\" nasl_init.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c strutils.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c regex.c regex.c: In function 're_match_2': regex.c:3844: warning: passing argument 1 of 'bcmp_translate' discards qualifiers from pointer target type regex.c:3844: warning: passing argument 2 of 'bcmp_translate' discards qualifiers from pointer target type /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c lsearch.c lsearch.c: In function 'lfind': lsearch.c:64: warning: passing argument 2 of 'linear_base' discards qualifiers from pointer target type /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c preparse.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c -DOPENVAS_SYSCONFDIR=\"/etc\" nasl_signature.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=compile gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -c nasl_debug.c /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=link gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -lgpgme -lgpg-error -lrpcsvc `/usr/bin/libopenvas-config --libs` `/usr/bin/gpgme-config --libs` -lglib-2.0 -o libopenvasnasl.la nasl_packet_forgery.lo nasl_socket.lo nasl_crypto.lo nasl_crypto2.lo nasl_http.lo nasl_host.lo nasl_text_utils.lo nasl_nessusd_glue.lo nasl_misc_funcs.lo nasl_cmd_exec.lo capture_packet.lo nasl_grammar.tab.lo nasl_tree.lo nasl_var.lo exec.lo lint.lo nasl_lex_ctxt.lo nasl_func.lo nasl_init.lo strutils.lo regex.lo lsearch.lo preparse.lo nasl_signature.lo nasl_debug.lo -rpath /usr/lib \ -version-info 2:0:0 /bin/sh /usr/src/packages/BUILD/openvas-libnasl-2.0.0/libtool --silent --mode=link gcc -pipe -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -I../include `/usr/bin/libopenvas-config --cflags` `/usr/bin/gpgme-config --cflags` -DNESSUS_EXTENSIONS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I. -I/usr/src/packages/BUILD/openvas-libnasl-2.0.0/include -DHAVE_CONFIG_H -o openvas-nasl -DVERSION=\"2.0.0\" nasl.c nasl_packet_forgery.o nasl_socket.o nasl_crypto.o nasl_crypto2.o nasl_http.o nasl_host.o nasl_text_utils.o nasl_nessusd_glue.o nasl_misc_funcs.o nasl_cmd_exec.o capture_packet.o nasl_grammar.tab.o nasl_tree.o nasl_var.o exec.o lint.o nasl_lex_ctxt.o nasl_func.o nasl_init.o strutils.o regex.o lsearch.o preparse.o nasl_signature.o nasl_debug.o -lgpgme -lgpg-error -lrpcsvc `/usr/bin/libopenvas-config --libs` `/usr/bin/gpgme-config --libs` -lglib-2.0 gcc: nasl_packet_forgery.o: No such file or directory gcc: nasl_socket.o: No such file or directory gcc: nasl_crypto.o: No such file or directory gcc: nasl_crypto2.o: No such file or directory gcc: nasl_http.o: No such file or directory gcc: nasl_host.o: No such file or directory gcc: nasl_text_utils.o: No such file or directory gcc: nasl_nessusd_glue.o: No such file or directory gcc: nasl_misc_funcs.o: No such file or directory gcc: nasl_cmd_exec.o: No such file or directory gcc: capture_packet.o: No such file or directory gcc: nasl_grammar.tab.o: No such file or directory gcc: nasl_tree.o: No such file or directory gcc: nasl_var.o: No such file or directory gcc: exec.o: No such file or directory gcc: lint.o: No such file or directory gcc: nasl_lex_ctxt.o: No such file or directory gcc: nasl_func.o: No such file or directory gcc: nasl_init.o: No such file or directory gcc: strutils.o: No such file or directory gcc: regex.o: No such file or directory gcc: lsearch.o: No such file or directory gcc: preparse.o: No such file or directory gcc: nasl_signature.o: No such file or directory gcc: nasl_debug.o: No such file or directory make[1]: *** [openvas-nasl] Error 1 make[1]: Leaving directory `/usr/src/packages/BUILD/openvas-libnasl-2.0.0/nasl' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.7167 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.7167 (%build) The missing files are in the ".libs" directory where they should be picked up just fine normally. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=855&group_id=29 From openvas-bugs at wald.intevation.org Fri Dec 19 10:34:59 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Fri, 19 Dec 2008 10:34:59 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B856=5D_MAC_Problem?= =?utf-8?q?_-_checking_for_=5F=5Fdn=5Fexpand_in_-lresolv=2E=2E=2E_n?= =?utf-8?q?o?= Message-ID: <20081219093459.A88F3407ED@pyrosoma.intevation.org> Bugs item #856, was opened at 2008-12-19 09:34 Status: Open Priority: 3 Submitted By: andrew blyth (ajcblyth) Assigned to: Nobody (None) Summary: MAC Problem - checking for __dn_expand in -lresolv... no Resolution: Awaiting Response Severity: critical Version: v2.0 Component: openvas-libraries Operating System: MacOS X Product: OpenVAS Hardware: Macintosh URL: Initial Comment: > I am running a Mac OS X (10.5). When I try and configure/compile > openvas-libraries-2.0.0 I get the following error message: > > checking for __dn_expand in -lresolv... no > configure: error: you need to install resolve library with development files > > I know that the resolve files are on my machine: > > $ ls -l /usr/include/resolv.h > -rw-r--r-- 1 root wheel 19363 5 Oct 2007 /usr/include/resolv.h > $ ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=856&group_id=29 From michael.wiegand at intevation.de Mon Dec 22 11:25:50 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 22 Dec 2008 11:25:50 +0100 Subject: [Openvas-devel] [PATCH] openvas-server: respect LDFLAGS In-Reply-To: <200812202336.49863.hanno@hboeck.de> References: <200812202336.49863.hanno@hboeck.de> Message-ID: <20081222102550.GA5295@intevation.de> * Hanno B?ck [20. Dec 2008]: > The Makefiles of openvas-server-2.0.0 don't respect LDFLAGS, attached patch > will fix that. Please apply. > > openvas-mkrand: $(OBJS) > - $(CC) $(OBJS) -o openvas-mkrand -lm > + $(CC) $(LDFLAGS) $(OBJS) -o openvas-mkrand -lm Could you explain why you are passing LDFLAGS directly to gcc? This may work in some or most cases, but might lead to trouble with LDFLAGS gcc does not understand. Wouldn't it be better to use -Xlinker or -Wl, for that? I'm sure there is a rationale behind your patch, I'm just not quite sure I understand it correctly. ;) 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 Mon Dec 22 12:21:43 2008 From: hanno at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=) Date: Mon, 22 Dec 2008 12:21:43 +0100 Subject: [Openvas-devel] [PATCH] openvas-server: respect LDFLAGS In-Reply-To: <20081222102550.GA5295@intevation.de> References: <200812202336.49863.hanno@hboeck.de> <20081222102550.GA5295@intevation.de> Message-ID: <200812221221.44034.hanno@hboeck.de> Am Montag 22 Dezember 2008 schrieb Michael Wiegand: > Could you explain why you are passing LDFLAGS directly to gcc? This may > work in some or most cases, but might lead to trouble with LDFLAGS gcc > does not understand. Wouldn't it be better to use -Xlinker or -Wl, for > that? It's common practise to do so. If you pass LDFLAGS to configure/makefiles, you usually pass them in a gcc-compliant way. That's also the way common autoconf/automake-setups do it, you'll always use something like LDFLAGS="-Wl,--as-needed" and never LDFLAGS="--as-needed". -- Hanno B?ck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno at hboeck.de http://www.jukss.de/ Jugemdumweltkongress, 27.12.-4.1. -------------- 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/20081222/315ece77/attachment.pgp From matt at mundell.ukfsn.org Mon Dec 22 22:39:18 2008 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 22 Dec 2008 21:39:18 GMT Subject: [Openvas-devel] Test framework Message-ID: <20081222213424.0DD0EDED4D@mail.ukfsn.org> Revision 2087 adds a test framework to the manager. The framework is a very simple mechanism which is basically provided by the build system (cmake). Small programs in the src/tests/ directory test specific parts of the manager, with the aim of combining to cover all the manager code. The name of each program corresponds to the function it tests. So, the files tests/strip_space_*.c test the function split_space openvas-manager/src/tests/strip_space_0.c openvas-manager/src/tests/strip_space_1.c openvas-manager/src/tests/strip_space_2.c ... In the build scripts, tests are defined by the ADD_TEST command, for example ADD_TEST (strip_space_3 strip_space_3) and the result is that make test runs all the tests. It's easy to understand. A novice can easily refer to the existing tests to see how to write new ones. It's also easy to add tests quickly by copying the existing tests. I worked on a project that used a very similar style, and it worked pretty well. What do other people think? Does anyone have suggestions for alternatives or improvements? It's basically the simplest thing I could do to get some tests up under cmake, so I'd be happy to completely replace it. I guess that this should set the way for testing the other modules. From randy at procyonlabs.com Tue Dec 23 02:45:36 2008 From: randy at procyonlabs.com (Randal T. Rioux) Date: Mon, 22 Dec 2008 20:45:36 -0500 (EST) Subject: [Openvas-devel] Compendium and Solaris Packages In-Reply-To: <20081222102550.GA5295@intevation.de> References: <200812202336.49863.hanno@hboeck.de> <20081222102550.GA5295@intevation.de> Message-ID: Ok I've been away. Forever. I'm back! I'd like to update the compendium in various areas, specifically the installation sections (for Solaris, AIX, etc). I can't find a way to do this on the svn server. Advice? Also, once I get everything to compile cleanly on Solaris, I'd like to make packages. Is anyone else already doing this? Thanks, Randy From timb at nth-dimension.org.uk Tue Dec 23 03:21:50 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Tue, 23 Dec 2008 02:21:50 +0000 Subject: [Openvas-devel] Compendium and Solaris Packages In-Reply-To: References: <200812202336.49863.hanno@hboeck.de> <20081222102550.GA5295@intevation.de> Message-ID: <200812230221.50887.timb@nth-dimension.org.uk> On Tuesday 23 December 2008 01:45:36 Randal T. Rioux wrote: > I'd like to update the compendium in various areas, specifically the > installation sections (for Solaris, AIX, etc). I can't find a way to do > this on the svn server. Advice? Have you got an account set up? If you have, the compendium module is /trunk/openvas-compendium. > Also, once I get everything to compile cleanly on Solaris, I'd like to > make packages. Is anyone else already doing this? No, but it sounds like a great idea. Porting it to Solaris will undoubtably enable us to clear out some more of the 64-bit bugs that still lurk. Tim -- Tim Brown From michael.wiegand at intevation.de Tue Dec 23 08:10:16 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 23 Dec 2008 08:10:16 +0100 Subject: [Openvas-devel] Compendium and Solaris Packages In-Reply-To: References: <200812202336.49863.hanno@hboeck.de> <20081222102550.GA5295@intevation.de> Message-ID: <20081223071016.GA9951@intevation.de> * Randal T. Rioux [23. Dec 2008]: > Ok I've been away. Forever. I'm back! Welcome back then! :) > I'd like to update the compendium in various areas, specifically the > installation sections (for Solaris, AIX, etc). I can't find a way to do > this on the svn server. Advice? As Tim said, it should be in your SVN checkout. Just fire up you favorite LaTeX editor and you should be ready to go. The source itself is HyperLaTeX, but I think there are enough examples in the file to give you a little help. Feel free to ask if you have questions. > Also, once I get everything to compile cleanly on Solaris, I'd like to > make packages. Is anyone else already doing this? I don't think so, sounds good to me! 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 randy at procyonlabs.com Tue Dec 23 08:36:36 2008 From: randy at procyonlabs.com (Randal T. Rioux) Date: Tue, 23 Dec 2008 02:36:36 -0500 (EST) Subject: [Openvas-devel] Web Client Message-ID: <99260bc454f8818ee0f007f30148db28.squirrel@192.168.3.3> I saw mention of this briefly. Has any work been started yet? If not, I can start this one. My choice is PHP, however I can do J2EE if so desired. Anybody want to begin a wish list? Respond with your hopes and dreams. Thanks, Randy From jan-oliver.wagner at intevation.de Tue Dec 23 09:00:25 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 23 Dec 2008 09:00:25 +0100 Subject: [Openvas-devel] Web Client In-Reply-To: <99260bc454f8818ee0f007f30148db28.squirrel@192.168.3.3> References: <99260bc454f8818ee0f007f30148db28.squirrel@192.168.3.3> Message-ID: <200812230900.26007.jan-oliver.wagner@intevation.de> Hi Randal, On Tuesday 23 December 2008 08:36:36 Randal T. Rioux wrote: > I saw mention of this briefly. Has any work been started yet? If not, I > can start this one. My choice is PHP, however I can do J2EE if so desired. > > Anybody want to begin a wish list? Respond with your hopes and dreams. yes, a web client is planned. As a initial step we are currently working out a entirely new communication protocol that finally removes all the design flaws of the old protocol (OTP heals only a couple of them). The new protocol will suffice the needs of a web client far better than the current one. However, this goes with the introduction of the "OpenVAS Manager" which is a daemon to handle session management and all the stuff that you do not want to have in the scan server and can not have in some clients like the web based ones. So, all in all in does not make too much sense to start a web client based on OTP. I neither prefer PHP nor J2EE, but rather something python-based or similar. Security people don't stop telling me that PHP is simply too error-prone and will be too easily subject to a security hole. A light-weight solution would already suffice the needs of a OpenVAS web frontend. It might even be possible with the new protocol to write a 100% JavaScript OpenVAS-Client. So far my thoughts. Starting into the new year, we have to find conclusions on how to go for a web-based client. I won't stop anyone to develop whatever he likes of course. Having more than one web based client in the end is not a bad thing. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Tue Dec 23 12:26:18 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 23 Dec 2008 12:26:18 +0100 Subject: [Openvas-devel] Patch to move cache - try 1 In-Reply-To: <4d7b043c0812211445i6d219112t2cd5576abf6ca61d@mail.gmail.com> References: <4d7b043c0812211445i6d219112t2cd5576abf6ca61d@mail.gmail.com> Message-ID: <20081223112618.GB10744@intevation.de> * Stjepan Gros [21. Dec 2008]: > This wasn't so easy. I _think_ this works, but I didn't yet tested > enough, and also, there is a catch. If you try to make subdirectories > inside plugins directory it'll complain that it can not find include > files. This can not be solved without introducing include directories, > what I'll do in the next few days. Also, my intention to keep things > compatible with the previous installations/versions (meaning, if you > don't specify cache_folder in conf. file that everything behaves as > before) complicates things a bit, but not so drastically. Thanks a lot for your hard work! I've already skimmed over your patch so far, it looks pretty sound to me. > The main problem with the introduction of the cache directory is that > it's hardcoded in, at least, two places. First, some functions inside > store.c themselves construct path by adding ".desc" on the plugins > directory, while the other use variable "sys_store_dir" which has the > same value. It doesn't seem necessary to be so, but this has to be > discussed. Additionaly, the functionality can be placed in several > places and it's hard to determine the best one based on the partial > knowledge of openvas I have. I agree that this should be consistent and preferably not hardcoded. Regarding the placement, feel free to make a suggestion, I (and others) will be glad to assist you with that. > And, finally, two notes. First, it seems that when openvasd server > sends the client data about plugins, for several attributes that are > sent, it reads disk and loads cached version of a plugin for each > attribute. I didn't investigate it further, but maybe someone can say > more about that. The execution path is send_plug_info -> > plug_get_{version,cve_id,bugtraq_id,xref,tag,family,summary,description,copyright} > -> store_fetch_{...} -> store_get_plugin (which reads cached plugin). I'll have to look into that myself, I might be able to take a closer look after the holiday season. I've noticed some unexpected results while using the cache, it might be a good idea to think about cleaning up there while we are at it. I have notice we seem to be constructing a lot of paths and filenames "by hand" with snprintf and the like. I recently discovered (thanks to Felix) that glib offers some nice functionality there in the form of g_build_path and g_build_filename. Do you think it might be useful to use them as well with your work? Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Tue Dec 23 09:01:19 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Tue, 23 Dec 2008 09:01:19 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B857=5D_configure_f?= =?utf-8?q?ailure_on_Solaris_10_SPARC?= Message-ID: <20081223080119.C2BFF14237@pyrosoma.intevation.org> Bugs item #857, was opened at 2008-12-23 03:01 Status: Open Priority: 3 Submitted By: Randal Rioux (rrioux) Assigned to: Nobody (None) Summary: configure failure on Solaris 10 SPARC Resolution: None Severity: blocker Version: v2.0 Component: openvas-libraries Operating System: Solaris Product: OpenVAS Hardware: Sun URL: Initial Comment: ./configure fails with the following error: checking for __dn_expand in -lresolv... no configure: error: you need to install resolve library with development files config.log entry: configure:19077: checking for __dn_expand in -lresolv configure:19112: gcc -pipe -o conftest -g -O2 conftest.c -lresolv >&5 Undefined first referenced symbol in file __dn_expand /var/tmp//cc6mBUlT.o ld: fatal: Symbol referencing errors. No output written to conftest collect2: ld returned 1 exit status ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=857&group_id=29 From sgros.ml at gmail.com Tue Dec 23 17:16:59 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Tue, 23 Dec 2008 17:16:59 +0100 Subject: [Openvas-devel] Patch to move cache - try 1 In-Reply-To: <20081223112618.GB10744@intevation.de> References: <4d7b043c0812211445i6d219112t2cd5576abf6ca61d@mail.gmail.com> <20081223112618.GB10744@intevation.de> Message-ID: <4d7b043c0812230816m71ec8bf2w807851fd2d68b334@mail.gmail.com> On Tue, Dec 23, 2008 at 12:26 PM, Michael Wiegand wrote: > * Stjepan Gros [21. Dec 2008]: >> This wasn't so easy. I _think_ this works, but I didn't yet tested >> enough, and also, there is a catch. If you try to make subdirectories >> inside plugins directory it'll complain that it can not find include >> files. This can not be solved without introducing include directories, >> what I'll do in the next few days. Also, my intention to keep things >> compatible with the previous installations/versions (meaning, if you >> don't specify cache_folder in conf. file that everything behaves as >> before) complicates things a bit, but not so drastically. > > Thanks a lot for your hard work! I've already skimmed over your patch so > far, it looks pretty sound to me. > >> The main problem with the introduction of the cache directory is that >> it's hardcoded in, at least, two places. First, some functions inside >> store.c themselves construct path by adding ".desc" on the plugins >> directory, while the other use variable "sys_store_dir" which has the >> same value. It doesn't seem necessary to be so, but this has to be >> discussed. Additionaly, the functionality can be placed in several >> places and it's hard to determine the best one based on the partial >> knowledge of openvas I have. > > I agree that this should be consistent and preferably not hardcoded. > > Regarding the placement, feel free to make a suggestion, I (and others) > will be glad to assist you with that. > >> And, finally, two notes. First, it seems that when openvasd server >> sends the client data about plugins, for several attributes that are >> sent, it reads disk and loads cached version of a plugin for each >> attribute. I didn't investigate it further, but maybe someone can say >> more about that. The execution path is send_plug_info -> >> plug_get_{version,cve_id,bugtraq_id,xref,tag,family,summary,description,copyright} >> -> store_fetch_{...} -> store_get_plugin (which reads cached plugin). > > I'll have to look into that myself, I might be able to take a closer > look after the holiday season. I've noticed some unexpected results > while using the cache, it might be a good idea to think about cleaning > up there while we are at it. > > I have notice we seem to be constructing a lot of paths and filenames > "by hand" with snprintf and the like. I recently discovered (thanks to > Felix) that glib offers some nice functionality there in the form of > g_build_path and g_build_filename. Do you think it might be useful to > use them as well with your work? Yes, I'll certainly look into them. As for patch, I completed it, along with multiple include directories. But, while server seems to work, I'm having a problems with the client. Namely, it doesn't get categories from the server but all the plugins are in a single list with no heading. I don't know yet where the problem might be so it'll take me some time until I debug it. In the mean time, attached is a patch for those who want to try it. There is a new configuration directive: include_folders=/include1;/include2;/include3 as it was mentioned in CR, while loading each plugin there are two implicit include directories: top level plugin directory, and the directory wher plugin itself is placed. Few more comments: 1. loading uncached directory is now slower than before :) BTW, it would be cool to use inotify on openvasd. installing new plugin would be a matter of only dropping nasl script into appropriate directory. 2. standalone nasl interpreter doesn't (yet) support include directories 3. there was some code in nasl_grammar.y that apparently was added with the intention to add include directories, but was obviously never implemented (look for define MULTIPLE_INCLUDE_DIRS) SG -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-cache-v01.patch Type: text/x-patch Size: 54322 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081223/b28a0573/openvas-cache-v01-0001.bin From sgros.ml at gmail.com Fri Dec 26 23:49:48 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Fri, 26 Dec 2008 23:49:48 +0100 Subject: [Openvas-devel] Patch to move cache - try 1 In-Reply-To: <4d7b043c0812230816m71ec8bf2w807851fd2d68b334@mail.gmail.com> References: <4d7b043c0812211445i6d219112t2cd5576abf6ca61d@mail.gmail.com> <20081223112618.GB10744@intevation.de> <4d7b043c0812230816m71ec8bf2w807851fd2d68b334@mail.gmail.com> Message-ID: <4d7b043c0812261449v496f3089nff11f6b29aa4eb20@mail.gmail.com> Ok, here is the first fully functional patch to allow definition of a cache location in the configuration file, definition of include directories and hierarchical plugin organization. Cache directory structure follows the plugin directory structure. Basically, the only difference to v01 is that I fixed a bug where family of a plugin wasn't properly communicated to the client. I did some limited testing (running openvasd with different combinations of the new directives, accessing server with the client, a very simple scan) and everything appears to be working. Finally, if this patch is applied and nothing is changed in the current implementations, then everything should work as it used to be. SG On Tue, Dec 23, 2008 at 5:16 PM, Stjepan Gros wrote: > On Tue, Dec 23, 2008 at 12:26 PM, Michael Wiegand > wrote: >> * Stjepan Gros [21. Dec 2008]: >>> This wasn't so easy. I _think_ this works, but I didn't yet tested >>> enough, and also, there is a catch. If you try to make subdirectories >>> inside plugins directory it'll complain that it can not find include >>> files. This can not be solved without introducing include directories, >>> what I'll do in the next few days. Also, my intention to keep things >>> compatible with the previous installations/versions (meaning, if you >>> don't specify cache_folder in conf. file that everything behaves as >>> before) complicates things a bit, but not so drastically. >> >> Thanks a lot for your hard work! I've already skimmed over your patch so >> far, it looks pretty sound to me. >> >>> The main problem with the introduction of the cache directory is that >>> it's hardcoded in, at least, two places. First, some functions inside >>> store.c themselves construct path by adding ".desc" on the plugins >>> directory, while the other use variable "sys_store_dir" which has the >>> same value. It doesn't seem necessary to be so, but this has to be >>> discussed. Additionaly, the functionality can be placed in several >>> places and it's hard to determine the best one based on the partial >>> knowledge of openvas I have. >> >> I agree that this should be consistent and preferably not hardcoded. >> >> Regarding the placement, feel free to make a suggestion, I (and others) >> will be glad to assist you with that. >> >>> And, finally, two notes. First, it seems that when openvasd server >>> sends the client data about plugins, for several attributes that are >>> sent, it reads disk and loads cached version of a plugin for each >>> attribute. I didn't investigate it further, but maybe someone can say >>> more about that. The execution path is send_plug_info -> >>> plug_get_{version,cve_id,bugtraq_id,xref,tag,family,summary,description,copyright} >>> -> store_fetch_{...} -> store_get_plugin (which reads cached plugin). >> >> I'll have to look into that myself, I might be able to take a closer >> look after the holiday season. I've noticed some unexpected results >> while using the cache, it might be a good idea to think about cleaning >> up there while we are at it. >> >> I have notice we seem to be constructing a lot of paths and filenames >> "by hand" with snprintf and the like. I recently discovered (thanks to >> Felix) that glib offers some nice functionality there in the form of >> g_build_path and g_build_filename. Do you think it might be useful to >> use them as well with your work? > > Yes, I'll certainly look into them. As for patch, I completed it, > along with multiple include directories. But, while server seems to > work, I'm having a problems with the client. Namely, it doesn't get > categories from the server but all the plugins are in a single list > with no heading. I don't know yet where the problem might be so it'll > take me some time until I debug it. > > In the mean time, attached is a patch for those who want to try it. > There is a new configuration directive: > > include_folders=/include1;/include2;/include3 > > as it was mentioned in CR, while loading each plugin there are two > implicit include directories: top level plugin directory, and the > directory wher plugin itself is placed. > > Few more comments: > > 1. loading uncached directory is now slower than before :) BTW, it > would be cool to use inotify on openvasd. installing new plugin would > be a matter of only dropping nasl script into appropriate directory. > > 2. standalone nasl interpreter doesn't (yet) support include directories > > 3. there was some code in nasl_grammar.y that apparently was added > with the intention to add include directories, but was obviously never > implemented (look for define MULTIPLE_INCLUDE_DIRS) > > SG > -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-cache-v02.patch Type: text/x-patch Size: 61892 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20081226/d5ca635e/openvas-cache-v02-0001.bin From felix.wolfsteller at intevation.de Mon Dec 29 10:30:01 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 29 Dec 2008 10:30:01 +0100 Subject: [Openvas-devel] OpenVAS-client Usability Improvements In-Reply-To: <20081219141348.GF16832@intevation.de> References: <20081219104056.GB25418@finlandia.home.infodrom.org> <20081219141348.GF16832@intevation.de> Message-ID: <200812291030.01171.felix.wolfsteller@intevation.de> Sounds all usefull. If you open a new Change Request you could integrate some of the items mentioned in openvas-client/TODO. If you do not feel like opening a new Change Request, please add your thoughts there. -- felix On Friday 19 December 2008 15:13:48 Michael Wiegand wrote: > * Martin Schulze [19. Dec 2008]: > > Hi, > > > > another issue that I notice frequently when I want to read a report in > > the Client is that I have to click on each and every port and priority > > to have the associated output displayed. > > > > It would be nice if there would be an "expand all" and "collapse all" > > button in the right report TreeView. > > Sounds useful to me. You seem to have a lot of good ideas for the client > GUI, it might be a good idea to collect them in a change request so they > don't get buried in the mailing list. What do you think? > > Regards, > > Michael -- 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 Mon Dec 29 11:53:03 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Mon, 29 Dec 2008 11:53:03 +0100 Subject: [Openvas-devel] IPv6 and a text about OpenVAS on InternetNews Message-ID: <4d7b043c0812290253w11f5d9dh6f526aff15967b2e@mail.gmail.com> First, I didn't saw that anyone mentioned it, so here it goes. A text on InternetNews about OpenVAS: http://www.internetnews.com/dev-news/article.php/3792791/OpenVAS+Charts+Its+Own+Forked+Course.htm but what caught my attention was the mention of IPv6. It turns out that OpenVAS doesn't support it? Is it true? SG From michael.wiegand at intevation.de Mon Dec 29 12:54:47 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 29 Dec 2008 12:54:47 +0100 Subject: [Openvas-devel] IPv6 and a text about OpenVAS on InternetNews In-Reply-To: <4d7b043c0812290253w11f5d9dh6f526aff15967b2e@mail.gmail.com> References: <4d7b043c0812290253w11f5d9dh6f526aff15967b2e@mail.gmail.com> Message-ID: <20081229115447.GA25651@intevation.de> * Stjepan Gros [29. Dec 2008]: > but what caught my attention was the mention of IPv6. It turns out > that OpenVAS doesn't support it? Is it true? I haven't tested IPv6 support in OpenVAS yet, but AFAICT there is no explicit support for it in OpenVAS. I think this would certainly be useful for future versions of OpenVAS, but I'm not quite sure as to how much work this would be. Anyone with experience in that field? 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 Mon Dec 29 13:30:38 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 29 Dec 2008 13:30:38 +0100 Subject: [Openvas-devel] [PATCH] openvas-server: remove unneeded gpgme.h include In-Reply-To: <200812202338.32014.hanno@hboeck.de> References: <200812202338.32014.hanno@hboeck.de> Message-ID: <200812291330.38312.felix.wolfsteller@intevation.de> Thanks for spotting that. I thankfully applied your patch. On Saturday 20 December 2008 23:38:31 Hanno B?ck wrote: > Hi, > > A file in openvas-server (otp_1_0.c) references gpgme.h, but it's never > used. Also there's no other reference in the whole source to gpgme. > > I noticed a compilation failure because it didn't find gpgme.h (it was in > the subdir /usr/include/gpgme/), but the "fix" seems to just remove it, as > it isn't used anyway. Attached patch does that, please apply. > > cu, -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From timb at nth-dimension.org.uk Mon Dec 29 15:00:02 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Mon, 29 Dec 2008 14:00:02 +0000 Subject: [Openvas-devel] Fwd: [IANA #199362] Application for port-number: otp (Assigned-9390) Message-ID: <200812291400.02793.timb@nth-dimension.org.uk> Better late than never - I raised this request almost 3 months ago ;). I'll forward on the port assignment as soon as I get it. It does however raise an interesting question. Which services, openvasd or the manager being written by Matt should we give it to? I did have a thought that maybe we could change openvasd to use a UNIX socket instead and thereby get some much needed privilege separation? Cheers, Tim ---------- Forwarded Message ---------- Subject: [IANA #199362] Application for port-number: otp (Assigned-9390) Date: Wednesday 24 December 2008 From: "Pearl Liang via RT" To: timb at openvas.org Dear Tim Brown: We have assigned the following TCP port to 'otp' with you as the point of contact: otp 9390/tcp OpenVAS Transfer Protocol # Tim Brown 24 December 2008 See: http://www.iana.org/assignments/port-numbers Please notify IANA if there is any change in contact information by completing the following template: http://www.iana.org/cgi-bin/mod_portno.pl This ticket [IANA #199362] is considered resolved. Best regards, Pearl Liang IANA *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 FAX: (310) 823-8649 email: iana-ports at iana.org *************************************************************** ------------------------------------------------------- -- Tim Brown -- Tim Brown From jan-oliver.wagner at intevation.de Mon Dec 29 17:01:14 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 29 Dec 2008 17:01:14 +0100 Subject: [Openvas-devel] IPv6 and a text about OpenVAS on InternetNews In-Reply-To: <4d7b043c0812290253w11f5d9dh6f526aff15967b2e@mail.gmail.com> References: <4d7b043c0812290253w11f5d9dh6f526aff15967b2e@mail.gmail.com> Message-ID: <200812291701.16421.jan-oliver.wagner@intevation.de> On Montag, 29. Dezember 2008, Stjepan Gros wrote: > First, I didn't saw that anyone mentioned it, so here it goes. A text > on InternetNews about OpenVAS: > http://www.internetnews.com/dev-news/article.php/3792791/OpenVAS+Charts+Its+Own+Forked+Course.htm ah yes, that happened all in a rush before christmas. > but what caught my attention was the mention of IPv6. It turns out > that OpenVAS doesn't support it? Is it true? I'd be thankful if anyone could clearly define or specify what "IPv6 Support in OpenVAS" is or should be. So far I received only foggy answers. Once clarified (a CR perhaps), I am more than willing to invest time/money into this feature. 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 sgros.ml at gmail.com Mon Dec 29 20:11:47 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Mon, 29 Dec 2008 20:11:47 +0100 Subject: [Openvas-devel] IPv6 and a text about OpenVAS on InternetNews In-Reply-To: <200812291701.16421.jan-oliver.wagner@intevation.de> References: <4d7b043c0812290253w11f5d9dh6f526aff15967b2e@mail.gmail.com> <200812291701.16421.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0812291111l1b66c356y6401bf5213d32de5@mail.gmail.com> On Mon, Dec 29, 2008 at 5:01 PM, Jan-Oliver Wagner wrote: > On Montag, 29. Dezember 2008, Stjepan Gros wrote: >> but what caught my attention was the mention of IPv6. It turns out >> that OpenVAS doesn't support it? Is it true? > > I'd be thankful if anyone could clearly define or specify what "IPv6 Support in OpenVAS" > is or should be. So far I received only foggy answers. It could mean few things: 1. It means that you can enter IPv6 address(es) in the OpenVAS client and then those hosts, whith those addresses, are scanned. This is not so simple as just entering IPv6 address because the socket code is different: - for a start, addresses are stored in sockaddr_in6 structure instead of sockaddr_in - AF_INET6 has to be used in place of AF_INET (e.g. creating socket, converting ascii adresses with inet_pton/inet_ntop) - constants like INADDR_ANY can not be used with IPv6 after the socket is created and bound (or connected) I believe it doesn't matter any more if IPv4 or IPv6 is used. 2. It means that when you enter hostname (or FQDN) which resolves to IPv6 address, this address will be used 3. There is a code in openvas for forging IP packets. This code has to be enhanced to know how to construct IPv6 packets. 4. NASL laguage has to be enhanced to accept IPv6 addresses, and potentially IPv6 specific extensions. And IMHO, with all the recent hype around IPv4 address shortages, and IPv6 mandatory use, and a like, i think that it would be good to introduce IPv6 as soon as possible, but that obviously won't be easy. > Once clarified (a CR perhaps), I am more than willing to invest time/money into this > feature. SG From jan-oliver.wagner at intevation.de Mon Dec 29 20:14:20 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 29 Dec 2008 20:14:20 +0100 Subject: [Openvas-devel] CR#24 (Subdirectories for NVTs): Call for vote Message-ID: <200812292014.21450.jan-oliver.wagner@intevation.de> Hello, I've updated the Change Request slightly: http://www.openvas.org/openvas-cr-24.html (However, the most important info is a working patch as recently sent by Stjepan :-) I call for a vote for this feature, because it hasn't been done yet at a formal level. For myself I vote +1 ! Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From lists at securityspace.com Mon Dec 29 20:42:55 2008 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 29 Dec 2008 14:42:55 -0500 Subject: [Openvas-devel] CR#24 (Subdirectories for NVTs): Call for vote In-Reply-To: <200812292014.21450.jan-oliver.wagner@intevation.de> References: <200812292014.21450.jan-oliver.wagner@intevation.de> Message-ID: <4959283F.70309@securityspace.com> > > I call for a vote for this feature, because it hasn't been done yet at > a formal level. > +1 Thomas From sgros.ml at gmail.com Mon Dec 29 22:15:31 2008 From: sgros.ml at gmail.com (Stjepan Gros) Date: Mon, 29 Dec 2008 22:15:31 +0100 Subject: [Openvas-devel] CR#24 (Subdirectories for NVTs): Call for vote In-Reply-To: <4959283F.70309@securityspace.com> References: <200812292014.21450.jan-oliver.wagner@intevation.de> <4959283F.70309@securityspace.com> Message-ID: <4d7b043c0812291315v367bf073x16508a067f55f27f@mail.gmail.com> On Mon, Dec 29, 2008 at 8:42 PM, Thomas Reinke wrote: > >> >> I call for a vote for this feature, because it hasn't been done yet at >> a formal level. >> > > +1 > Obviously, I'll add my +1 here. :) Sg From openvas-bugs at wald.intevation.org Wed Dec 24 17:50:25 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Wed, 24 Dec 2008 17:50:25 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B858=5D_OpenVAS-Cli?= =?utf-8?q?ent_Crash_listing_Preferences?= Message-ID: <20081224165025.DBE55406F4@pyrosoma.intevation.org> Bugs item #858, was opened at 2008-12-24 10:50 Status: Open Priority: 3 Submitted By: MadHat Unspecific (unspecific) Assigned to: Nobody (None) Summary: OpenVAS-Client Crash listing Preferences Resolution: None Severity: normal Version: v2.0 Component: openvas-client Operating System: Linux Product: OpenVAS Hardware: PC URL: Initial Comment: strace and gdb output. I am not sure what all is needed. It's been a long time since I debugged any software like this. # OpenVAS-Client -P 127.0.0.1 1241 XXXXXX XXXXXX Segmentation fault is-scanner:~# strace OpenVAS-Client -P 127.0.0.1 1241 XXXXXX XXXXXX execve("/usr/local/bin/OpenVAS-Client", ["OpenVAS-Client", "-P", "127.0.0.1", "1241", "XXXXXX", "XXXXXX"], [/* 13 vars */]) = 0 uname({sys="Linux", node="is-scanner.XXXXXX.net", ...}) = 0 brk(0) = 0x8098000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f51000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=41447, ...}) = 0 mmap2(NULL, 41447, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f46000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libglib-2.0.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\322\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=596608, ...}) = 0 mmap2(NULL, 596204, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7eb4000 mmap2(0xb7f45000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x91) = 0xb7f45000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/libm.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`3\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=145136, ...}) = 0 mmap2(NULL, 147584, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e8f000 mmap2(0xb7eb2000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22) = 0xb7eb2000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/i686/cmov/libssl.so.0.9.8", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\255"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=253120, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e8e000 mmap2(NULL, 256084, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e4f000 mmap2(0xb7e8a000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3a) = 0xb7e8a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/i686/cmov/libcrypto.so.0.9.8", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300Y\3"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=1270520, ...}) = 0 mmap2(NULL, 1282904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d15000 mmap2(0xb7e37000, 81920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x122) = 0xb7e37000 mmap2(0xb7e4b000, 13144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7e4b000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\f\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9592, ...}) = 0 mmap2(NULL, 12404, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d11000 mmap2(0xb7d13000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7d13000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libz.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\26"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=78500, ...}) = 0 mmap2(NULL, 81456, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7cfd000 mmap2(0xb7d10000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7d10000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/libnsl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p5\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=76548, ...}) = 0 mmap2(NULL, 87808, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ce7000 mmap2(0xb7cf9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11) = 0xb7cf9000 mmap2(0xb7cfb000, 5888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7cfb000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260$\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=67364, ...}) = 0 mmap2(NULL, 75976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7cd4000 mmap2(0xb7ce3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb7ce3000 mmap2(0xb7ce5000, 6344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ce5000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=1245488, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cd3000 mmap2(NULL, 1251484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ba1000 mmap2(0xb7cc9000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x128) = 0xb7cc9000 mmap2(0xb7cd0000, 10396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7cd0000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\35\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=26516, ...}) = 0 mmap2(NULL, 29264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7b99000 mmap2(0xb7b9f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0xb7b9f000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360G\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=85010, ...}) = 0 mmap2(NULL, 70104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7b87000 mmap2(0xb7b95000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd) = 0xb7b95000 mmap2(0xb7b97000, 4568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7b97000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7b86000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7b85000 mprotect(0xb7cc9000, 20480, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7b856c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7f46000, 41447) = 0 set_tid_address(0xb7b85708) = 16410 rt_sigaction(SIGRTMIN, {0xb7b8b450, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb7b8b3c0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 uname({sys="Linux", node="is-scanner.XXXXXX.net", ...}) = 0 brk(0) = 0x8098000 brk(0x80b9000) = 0x80b9000 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1209120, ...}) = 0 mmap2(NULL, 1209120, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7a5d000 close(3) = 0 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2582, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f50000 read(3, "# Locale name alias data base.\n#"..., 4096) = 2582 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7f50000, 4096) = 0 open("/usr/local/share/locale/en_US.UTF-8/LC_MESSAGES/OpenVAS-Client.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/local/share/locale/en_US.utf8/LC_MESSAGES/OpenVAS-Client.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/local/share/locale/en_US/LC_MESSAGES/OpenVAS-Client.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/local/share/locale/en.UTF-8/LC_MESSAGES/OpenVAS-Client.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/local/share/locale/en.utf8/LC_MESSAGES/OpenVAS-Client.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/local/share/locale/en/LC_MESSAGES/OpenVAS-Client.mo", O_RDONLY) = -1 ENOENT (No such file or directory) gettimeofday({1230136607, 567624}, NULL) = 0 open("/usr/lib/charset.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) rt_sigaction(SIGINT, {0x804e360, [INT], SA_RESTART}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {0x804e360, [QUIT], SA_RESTART}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGKILL, {0x804e360, [KILL], SA_RESTART}, {SIG_DFL}, 8) = -1 EINVAL (Invalid argument) rt_sigaction(SIGTERM, {0x804e360, [TERM], SA_RESTART}, {SIG_DFL}, 8) = 0 chmod("/root/.openvasrc", 0600) = 0 open("/root/.openvasrc", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=216114, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f50000 read(3, "# This file was automagically cr"..., 4096) = 4096 read(3, " 1.3.6.1.4.1.25623.1.0.60393 = y"..., 4096) = 4096 read(3, "104 = yes\n 1.3.6.1.4.1.25623.1.0"..., 4096) = 4096 read(3, ".0.61023 = yes\n 1.3.6.1.4.1.2562"..., 4096) = 4096 read(3, "5623.1.0.53786 = yes\n 1.3.6.1.4."..., 4096) = 4096 read(3, "1.25623.1.0.53636 = yes\n 1.3.6.1"..., 4096) = 4096 read(3, ".4.1.25623.1.0.52700 = yes\n 1.3."..., 4096) = 4096 read(3, ".3.6.1.4.1.25623.1.0.900171 = ye"..., 4096) = 4096 read(3, "yes\n 1.3.6.1.4.1.25623.1.0.52428"..., 4096) = 4096 read(3, "54910 = yes\n 1.3.6.1.4.1.25623.1"..., 4096) = 4096 read(3, ".14371 = yes\n 1.3.6.1.4.1.25623."..., 4096) = 4096 brk(0x80da000) = 0x80da000 read(3, ".0.58598 = yes\n 1.3.6.1.4.1.2562"..., 4096) = 4096 read(3, "3.1.0.53801 = yes\n 1.3.6.1.4.1.2"..., 4096) = 4096 read(3, "25623.1.0.56786 = yes\n 1.3.6.1.4"..., 4096) = 4096 read(3, "1.25623.1.0.56393 = yes\n 1.3.6.1"..., 4096) = 4096 read(3, "1.4.1.25623.1.0.55937 = yes\n 1.3"..., 4096) = 4096 read(3, ".3.6.1.4.1.25623.1.0.58689 = yes"..., 4096) = 4096 read(3, "yes\n 1.3.6.1.4.1.25623.1.0.56391"..., 4096) = 4096 read(3, "1 = yes\n 1.3.6.1.4.1.25623.1.0.5"..., 4096) = 4096 read(3, "025 = yes\n 1.3.6.1.4.1.25623.1.0"..., 4096) = 4096 read(3, "0.58742 = yes\n 1.3.6.1.4.1.25623"..., 4096) = 4096 read(3, "1.0.58465 = yes\n 1.3.6.1.4.1.256"..., 4096) = 4096 read(3, ".25623.1.0.54610 = yes\n 1.3.6.1."..., 4096) = 4096 brk(0x80fb000) = 0x80fb000 read(3, ".1.4.1.25623.1.0.56521 = yes\n 1."..., 4096) = 4096 read(3, "6.1.4.1.25623.1.0.18478 = yes\n 1"..., 4096) = 4096 read(3, "= yes\n 1.3.6.1.4.1.25623.1.0.142"..., 4096) = 4096 read(3, "335 = yes\n 1.3.6.1.4.1.25623.1.0"..., 4096) = 4096 read(3, "56358 = yes\n 1.3.6.1.4.1.25623.1"..., 4096) = 4096 read(3, "3.1.0.60053 = yes\n 1.3.6.1.4.1.2"..., 4096) = 4096 read(3, "25623.1.0.10642 = yes\n 1.3.6.1.4"..., 4096) = 4096 read(3, ".1.25623.1.0.54924 = yes\n 1.3.6."..., 4096) = 4096 read(3, ".4.1.25623.1.0.54616 = yes\n 1.3."..., 4096) = 4096 read(3, "3.6.1.4.1.25623.1.0.11889 = yes\n"..., 4096) = 4096 read(3, "\n 1.3.6.1.4.1.25623.1.0.61191 = "..., 4096) = 4096 read(3, "es\n 1.3.6.1.4.1.25623.1.0.10851 "..., 4096) = 4096 brk(0x811c000) = 0x811c000 read(3, " = yes\n 1.3.6.1.4.1.25623.1.0.54"..., 4096) = 4096 read(3, ".1.0.53377 = yes\n 1.3.6.1.4.1.25"..., 4096) = 4096 read(3, "5623.1.0.55234 = yes\n 1.3.6.1.4."..., 4096) = 4096 read(3, "4.1.25623.1.0.61028 = yes\n 1.3.6"..., 4096) = 4096 read(3, "\n 1.3.6.1.4.1.25623.1.0.57145 = "..., 4096) = 4096 read(3, "= yes\n 1.3.6.1.4.1.25623.1.0.619"..., 4096) = 4096 read(3, "54917 = yes\n 1.3.6.1.4.1.25623.1"..., 4096) = 4096 read(3, "0.53455 = yes\n 1.3.6.1.4.1.25623"..., 4096) = 4096 read(3, "3.1.0.52440 = yes\n 1.3.6.1.4.1.2"..., 4096) = 4096 read(3, "5623.1.0.53509 = yes\n 1.3.6.1.4."..., 4096) = 4096 read(3, ".1.25623.1.0.58823 = yes\n 1.3.6."..., 4096) = 4096 read(3, ".3.6.1.4.1.25623.1.0.53511 = yes"..., 4096) = 4096 brk(0x813d000) = 0x813d000 read(3, "es\n 1.3.6.1.4.1.25623.1.0.54697 "..., 4096) = 4096 read(3, "465 = yes\n 1.3.6.1.4.1.25623.1.0"..., 4096) = 4096 read(3, ".1.0.55514 = yes\n 1.3.6.1.4.1.25"..., 4096) = 4096 read(3, "25623.1.0.56208 = yes\n 1.3.6.1.4"..., 4096) = 4096 read(3, "1.4.1.25623.1.0.56834 = yes\n 1.3"..., 4096) = 4096 read(3, "entify the remote OS = no\n Nmap "..., 4096) = 3122 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7f50000, 4096) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Process 16410 detached # gdb OpenVAS-Client GNU gdb 6.4.90-debian 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-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r -P 127.0.0.1 1241 XXXXXX XXXXXX Starting program: /usr/local/bin/OpenVAS-Client -P 127.0.0.1 1241 XXXXXX XXXXXX Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1212770624 (LWP 16440)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212770624 (LWP 16440)] 0xb7bf0e63 in strlen () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7bf0e63 in strlen () from /lib/tls/libc.so.6 #1 0xb7bf0b65 in strdup () from /lib/tls/libc.so.6 #2 0x0804f253 in cli_args_server () #3 0x08063bd7 in main () ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=858&group_id=29 From timb at openvas.org Fri Dec 26 17:50:23 2008 From: timb at openvas.org (Tim Brown) Date: Fri, 26 Dec 2008 16:50:23 +0000 Subject: [Openvas-devel] Fwd: [IANA #199362] Application for port-number: otp (Assigned-9390) Message-ID: <200812261650.23994.timb@openvas.org> Better late than never - I raised this request almost 3 months ago ;). I'll forward on the port assignment as soon as I get it. It does however raise an interesting question. Which services, openvasd or the manager being written by Matt should we give it to? I did have a thought that maybe we could change openvasd to use a UNIX socket instead and thereby get some much needed privilege separation? Cheers, Tim ---------- Forwarded Message ---------- Subject: [IANA #199362] Application for port-number: otp (Assigned-9390) Date: Wednesday 24 December 2008 From: "Pearl Liang via RT" To: timb at openvas.org Dear Tim Brown: We have assigned the following TCP port to 'otp' with you as the point of contact: otp 9390/tcp OpenVAS Transfer Protocol # Tim Brown 24 December 2008 See: http://www.iana.org/assignments/port-numbers Please notify IANA if there is any change in contact information by completing the following template: http://www.iana.org/cgi-bin/mod_portno.pl This ticket [IANA #199362] is considered resolved. Best regards, Pearl Liang IANA *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 FAX: (310) 823-8649 email: iana-ports at iana.org *************************************************************** ------------------------------------------------------- -- Tim Brown From openvas-bugs at wald.intevation.org Mon Dec 29 20:58:38 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Mon, 29 Dec 2008 20:58:38 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B860=5D_Darwin_buil?= =?utf-8?q?d_issues?= Message-ID: <20081229195838.089B14072E@pyrosoma.intevation.org> Bugs item #860, was opened at 2008-12-29 19:58 Status: Open Priority: 3 Submitted By: Adrian Portelli (adrianp) Assigned to: Nobody (None) Summary: Darwin build issues Resolution: None Severity: blocker Version: v2.0 Component: openvas-libraries Operating System: MacOS X Product: OpenVAS Hardware: Other URL: Initial Comment: While packaging OpenVAS for pkgsrc I came across a few issues on OS/X (10.5.6/i386) openvas-libraries: * compilation fails on libopenvas/plugutils.c as it tries to do #include which needs to be #include * compilation fails on libopenvas/bpf_share.h as the u_char type is not defined. I had to add an #include to the top of bpf_share.h to get this to work. openvas-server: * openvas-adduser.in, openvas-mkcert-client.in, openvas-mkcert.in and openvas-rmuser.in all assume that gettext.sh is under /usr/bin which is not always the case. Without this pointing to the correct location, at least openvas-adduser does not work correctly. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=860&group_id=29 From openvas-bugs at wald.intevation.org Mon Dec 29 21:00:45 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Mon, 29 Dec 2008 21:00:45 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B861=5D_OpenVAS-Cli?= =?utf-8?q?ent_Plugin_script=5Fid_Duplication?= Message-ID: <20081229200045.3D1814072E@pyrosoma.intevation.org> Bugs item #861, was opened at 2008-12-29 14:00 Status: Open Priority: 3 Submitted By: MadHat Unspecific (unspecific) Assigned to: Nobody (None) Summary: OpenVAS-Client Plugin script_id Duplication Resolution: None Severity: trivial Version: v1.0 Component: openvas-plugins Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: /usr/local/lib/openvas/plugins/secpod_nms_dvd_burning_sdk_actvx_vuln_900132.nasl: script_id(900132); /usr/local/lib/openvas/plugins/secpod_nms_dvd_sdk_actvex_vuln_900132.nasl: script_id(900132); Causing issues with SQL output for plugins. Seems like it should cause errors in other places as well. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=861&group_id=29 From openvas-bugs at wald.intevation.org Mon Dec 29 21:27:25 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Mon, 29 Dec 2008 21:27:25 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B862=5D_NetBSD_buil?= =?utf-8?q?d_issues?= Message-ID: <20081229202725.D706B40740@pyrosoma.intevation.org> Bugs item #862, was opened at 2008-12-29 20:27 Status: Open Priority: 3 Submitted By: Adrian Portelli (adrianp) Assigned to: Nobody (None) Summary: NetBSD build issues Resolution: None Severity: blocker Version: v2.0 Component: openvas-libraries Operating System: NetBSD Product: OpenVAS Hardware: PC URL: Initial Comment: While packaging OpenVAS for pkgsrc I came across a few issues on NetBSD (5.0/x64) openvas-libraries: * compilation fails on libopenvas/pcap.c due to missing types. I had to add an #include to the top of pcap.c to get this to work. * compilation fails on libopenvas/popen.c due to missing types. I had to add an #include to the top of popen.c to get this to work. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=862&group_id=29 From felix.wolfsteller at intevation.de Tue Dec 30 09:17:55 2008 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 30 Dec 2008 09:17:55 +0100 Subject: [Openvas-devel] CR#24 (Subdirectories for NVTs): Call for vote In-Reply-To: <200812292014.21450.jan-oliver.wagner@intevation.de> References: <200812292014.21450.jan-oliver.wagner@intevation.de> Message-ID: <200812300917.55384.felix.wolfsteller@intevation.de> +1 On Monday 29 December 2008 20:14:20 Jan-Oliver Wagner wrote: > Hello, > > I've updated the Change Request slightly: > > http://www.openvas.org/openvas-cr-24.html > > (However, the most important info is a working patch as recently sent > by Stjepan :-) > > I call for a vote for this feature, because it hasn't been done yet at > a formal level. > > For myself I vote +1 ! > > Best > > Jan -- 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 bchandra at secpod.com Tue Dec 30 14:12:40 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Tue, 30 Dec 2008 18:42:40 +0530 Subject: [Openvas-devel] CR#24 (Subdirectories for NVTs): Call for vote In-Reply-To: <200812292014.21450.jan-oliver.wagner@intevation.de> References: <200812292014.21450.jan-oliver.wagner@intevation.de> Message-ID: <37EB16A5590B49C7A18CF1D0B9239D6B@bchandra> +1 Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Tuesday, December 30, 2008 12:44 AM To: openvas-devel at wald.intevation.org Subject: [Openvas-devel] CR#24 (Subdirectories for NVTs): Call for vote Hello, I've updated the Change Request slightly: http://www.openvas.org/openvas-cr-24.html (However, the most important info is a working patch as recently sent by Stjepan :-) I call for a vote for this feature, because it hasn't been done yet at a formal level. For myself I vote +1 ! Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel