From felix.wolfsteller at intevation.de Tue Sep 1 11:10:47 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 1 Sep 2009 11:10:47 +0200 Subject: [Openvas-devel] Removal of libnasl from svn trunk In-Reply-To: <200908281135.16248.felix.wolfsteller@intevation.de> References: <200908281135.16248.felix.wolfsteller@intevation.de> Message-ID: <200909011110.47267.felix.wolfsteller@intevation.de> In line with CR #38 (http://www.openvas.org/openvas-cr-38.html), libnasl is going to be removed from svn trunk soon. libnasl is now part of openvas-libraries and built using cmake. Server (and client) are linked against it. It is the ideal moment to test the build now and I would be happy if you report the outcome ("e.g. works on gentoo 64Bit"). I expect a couple of issues because the separate configure step for libnasl is not done anymore. Any input on how to deal with these issues and cmake is very welcome. Have fun, -- 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 christian.edjenguele at owasp.org Tue Sep 1 18:21:37 2009 From: christian.edjenguele at owasp.org (Christian Eric Edjenguele) Date: Tue, 01 Sep 2009 18:21:37 +0200 Subject: [Openvas-devel] [Openvas-commits] r4805 - trunk/openvas-plugins/scripts In-Reply-To: <20090901105813.D7FEC85C730F@pyrosoma.intevation.org> References: <20090901105813.D7FEC85C730F@pyrosoma.intevation.org> Message-ID: <4A9D4A11.9060004@owasp.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chandra, I'm not certain about changes in this code, Jan told me about some errors, but does identation solves the problem ? thanks. scm-commit at wald.intevation.org wrote: > Author: chandra > Date: 2009-09-01 12:58:12 +0200 (Tue, 01 Sep 2009) > New Revision: 4805 > > Modified: > trunk/openvas-plugins/scripts/remote-MS04-017.nasl > Log: > Updated to resolve the issue in dump messages > > Modified: trunk/openvas-plugins/scripts/remote-MS04-017.nasl > =================================================================== > --- trunk/openvas-plugins/scripts/remote-MS04-017.nasl 2009-09-01 09:22:54 UTC (rev 4804) > +++ trunk/openvas-plugins/scripts/remote-MS04-017.nasl 2009-09-01 10:58:12 UTC (rev 4805) > @@ -108,19 +108,22 @@ > foreach page (pages) > { > soc = open_sock_tcp(port); > - # build the malicious request > - request = page + '/crystalimagehandler.aspx?dynamicimage=../../../../../../../../../boot.ini'; > + if(soc) > + { > + # build the malicious request > + request = page + '/crystalimagehandler.aspx?dynamicimage=../../../../../../../../../boot.ini'; > > - qry = string('GET ' + request + ' HTTP/1.0\r\n', > - 'Host: ' + h_ip + ':' + port + '\r\n\r\n'); > + qry = string('GET ' + request + ' HTTP/1.0\r\n', > + 'Host: ' + h_ip + ':' + port + '\r\n\r\n'); > > - req = http_get(item:qry, port:port); > - send(socket:soc, data: req); > + req = http_get(item:qry, port:port); > + send(socket:soc, data: req); > > - # Get back the response > - reply = recv(socket:soc, length:4096); > + # Get back the response > + reply = recv(socket:soc, length:4096); > > - close(soc); > + close(soc); > + } > > if(reply) > { > > _______________________________________________ > Openvas-commits mailing list > Openvas-commits at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-commits - -- Christian Eric Edjenguele IT Security Engineer PGP KeyID: 0xB1654498 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJKnUoMAAoJENETScWxZUSYfFgH/jgW7VwvG8fPAcfbI1P8IXwB XwgrzX2rha7Qqqrceswpkyh+qVwt9X4RTeKQRVlLnKCZBT7pqEXWdAvlYsNdQcEP wkMYLl/D5BLWyDNAJ/FaEfyq9PXgz/jjg7l0Y8MSy5hF9J5zoL5IQSwIO2RTDqYx rjVgYHX3h+Vkr08Y6V7hbpVrVQfnvJmaMWx+kis6SUyAdJti6C6Nz4SCRcwn1j7l yQFQZCU4GfMCYGVwwbuPZZh2n4GVgLEQ4p4kkFCe+K364t+wVSNem5WrFsD68MCS WEcYt0eq78pCN9TqYNyDU+X4I1lggJQbVRHmE6U+Dh/L0wEu1dUoM3D701C56h4= =xhPQ -----END PGP SIGNATURE----- From mime at gmx.de Tue Sep 1 20:42:14 2009 From: mime at gmx.de (Michael Meyer) Date: Tue, 1 Sep 2009 20:42:14 +0200 Subject: [Openvas-devel] [Openvas-commits] r4805 - trunk/openvas-plugins/scripts In-Reply-To: <4A9D4A11.9060004@owasp.org> References: <20090901105813.D7FEC85C730F@pyrosoma.intevation.org> <4A9D4A11.9060004@owasp.org> Message-ID: <20090901184214.GA13925@komma-nix.de> Hello Christian, *** Christian Eric Edjenguele wrote: > Hi Chandra, I'm not certain about changes in this code, Jan told me > about some errors, but does identation solves the problem ? No, but... > > + if(soc) i think. ;) But i dont't know what the problem was. Micha From geoff at galitz.org Tue Sep 1 22:48:39 2009 From: geoff at galitz.org (Geoff Galitz) Date: Tue, 1 Sep 2009 22:48:39 +0200 Subject: [Openvas-devel] Concurrent hosts and tests options Message-ID: <56A6C883917E4ABCA547C2D13D495695@geoffPC> What is the relationship between concurrent hosts and concurrent tests? Specifically, does the same test against two machines count as one test, or as two tests? -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090901/9a5b7c6e/attachment.html From lists at securityspace.com Tue Sep 1 23:13:49 2009 From: lists at securityspace.com (Thomas Reinke) Date: Tue, 01 Sep 2009 17:13:49 -0400 Subject: [Openvas-devel] Concurrent hosts and tests options In-Reply-To: <56A6C883917E4ABCA547C2D13D495695@geoffPC> References: <56A6C883917E4ABCA547C2D13D495695@geoffPC> Message-ID: <4A9D8E8D.4010707@securityspace.com> A. Concurrent hosts - the # of hosts that are simultaneously tested. B. Concurrent tests - the # of tests (per host) that may be simultaneously run. If you launch a test against two machines (e.g. 192.168.1.1,192.168.1.2) you will start auditing both IPs simultaneously if and only if concurrent hosts is > 1. Within each IP being tested up to "B" concurrent tests will be run simultaneously, at most, providing plugin scheduling and dependencies allows for it. Thomas Geoff Galitz wrote: > > > What is the relationship between concurrent hosts and concurrent tests? > > > > Specifically, does the same test against two machines count as one test, > or as two tests? > > > > > > -geoff > > --------------------------------- > Geoff Galitz > Blankenheim NRW, Germany > http://www.galitz.org/ > http://german-way.com/blog/ > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From geoff at galitz.org Tue Sep 1 23:26:02 2009 From: geoff at galitz.org (Geoff Galitz) Date: Tue, 1 Sep 2009 23:26:02 +0200 Subject: [Openvas-devel] Concurrent hosts and tests options In-Reply-To: <4A9D8E8D.4010707@securityspace.com> References: <56A6C883917E4ABCA547C2D13D495695@geoffPC> <4A9D8E8D.4010707@securityspace.com> Message-ID: <2F9C6191A94B439ABE269704F22066B9@geoffPC> Thanks Thomas. That was my understanding, but I needed to verify that for my current project. -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel- > bounces at wald.intevation.org] On Behalf Of Thomas Reinke > Sent: Dienstag, 1. September 2009 23:14 > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] Concurrent hosts and tests options > > A. Concurrent hosts - the # of hosts that are simultaneously tested. > B. Concurrent tests - the # of tests (per host) that may be > simultaneously run. > > If you launch a test against two machines (e.g. 192.168.1.1,192.168.1.2) > you will start auditing both IPs simultaneously if and only if > concurrent hosts is > 1. Within each IP being tested up to "B" > concurrent tests will be run simultaneously, at most, providing > plugin scheduling and dependencies allows for it. > ... From bchandra at secpod.com Wed Sep 2 07:38:29 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 2 Sep 2009 11:08:29 +0530 Subject: [Openvas-devel] [Openvas-commits] r4805 -trunk/openvas-plugins/scripts In-Reply-To: <4A9D4A11.9060004@owasp.org> References: <20090901105813.D7FEC85C730F@pyrosoma.intevation.org> <4A9D4A11.9060004@owasp.org> Message-ID: <79B822D592604199A7CDCF78AE657D7B@bchandra> Hello Christian, I have added socket functions inside if(soc) which resolves the dump errors. Before calling the functions such as send(), close(), there should always be a check soc either, If(soc) or if(!soc) exit(0) Also there are few more problems in the plugin, In ln 114, you are constructing a complete HTTP GET request and then calling http_get() function, http_get itself will do all these, just need to pass the URL. In this case http_get() is returning a wrong HTTP request. Thanks, Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Christian Eric Edjenguele Sent: Tuesday, September 01, 2009 9:52 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] [Openvas-commits] r4805 -trunk/openvas-plugins/scripts -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chandra, I'm not certain about changes in this code, Jan told me about some errors, but does identation solves the problem ? thanks. scm-commit at wald.intevation.org wrote: > Author: chandra > Date: 2009-09-01 12:58:12 +0200 (Tue, 01 Sep 2009) > New Revision: 4805 > > Modified: > trunk/openvas-plugins/scripts/remote-MS04-017.nasl > Log: > Updated to resolve the issue in dump messages > > Modified: trunk/openvas-plugins/scripts/remote-MS04-017.nasl > =================================================================== > --- trunk/openvas-plugins/scripts/remote-MS04-017.nasl 2009-09-01 09:22:54 UTC (rev 4804) > +++ trunk/openvas-plugins/scripts/remote-MS04-017.nasl 2009-09-01 10:58:12 UTC (rev 4805) > @@ -108,19 +108,22 @@ > foreach page (pages) > { > soc = open_sock_tcp(port); > - # build the malicious request > - request = page + '/crystalimagehandler.aspx?dynamicimage=../../../../../../../../../boot.ini' ; > + if(soc) > + { > + # build the malicious request > + request = page + '/crystalimagehandler.aspx?dynamicimage=../../../../../../../../../boot.ini' ; > > - qry = string('GET ' + request + ' HTTP/1.0\r\n', > - 'Host: ' + h_ip + ':' + port + '\r\n\r\n'); > + qry = string('GET ' + request + ' HTTP/1.0\r\n', > + 'Host: ' + h_ip + ':' + port + '\r\n\r\n'); > > - req = http_get(item:qry, port:port); > - send(socket:soc, data: req); > + req = http_get(item:qry, port:port); > + send(socket:soc, data: req); > > - # Get back the response > - reply = recv(socket:soc, length:4096); > + # Get back the response > + reply = recv(socket:soc, length:4096); > > - close(soc); > + close(soc); > + } > > if(reply) > { > > _______________________________________________ > Openvas-commits mailing list > Openvas-commits at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-commits - -- Christian Eric Edjenguele IT Security Engineer PGP KeyID: 0xB1654498 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJKnUoMAAoJENETScWxZUSYfFgH/jgW7VwvG8fPAcfbI1P8IXwB XwgrzX2rha7Qqqrceswpkyh+qVwt9X4RTeKQRVlLnKCZBT7pqEXWdAvlYsNdQcEP wkMYLl/D5BLWyDNAJ/FaEfyq9PXgz/jjg7l0Y8MSy5hF9J5zoL5IQSwIO2RTDqYx rjVgYHX3h+Vkr08Y6V7hbpVrVQfnvJmaMWx+kis6SUyAdJti6C6Nz4SCRcwn1j7l yQFQZCU4GfMCYGVwwbuPZZh2n4GVgLEQ4p4kkFCe+K364t+wVSNem5WrFsD68MCS WEcYt0eq78pCN9TqYNyDU+X4I1lggJQbVRHmE6U+Dh/L0wEu1dUoM3D701C56h4= =xhPQ -----END PGP SIGNATURE----- _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From christian.edjenguele at owasp.org Wed Sep 2 08:26:27 2009 From: christian.edjenguele at owasp.org (Christian Eric Edjenguele) Date: Wed, 02 Sep 2009 08:26:27 +0200 Subject: [Openvas-devel] [Openvas-commits] r4805 -trunk/openvas-plugins/scripts In-Reply-To: <79B822D592604199A7CDCF78AE657D7B@bchandra> References: <20090901105813.D7FEC85C730F@pyrosoma.intevation.org> <4A9D4A11.9060004@owasp.org> <79B822D592604199A7CDCF78AE657D7B@bchandra> Message-ID: <4A9E1013.7080306@owasp.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chandrashekhar B wrote: > Hello Christian, > > I have added socket functions inside if(soc) which resolves the dump errors. > Before calling the functions such as send(), close(), there should always be > a check soc either, > > If(soc) or if(!soc) exit(0) > > Also there are few more problems in the plugin, > > In ln 114, you are constructing a complete HTTP GET request and then calling > http_get() function, http_get itself will do all these, just need to pass > the URL. In this case http_get() is returning a wrong HTTP request. yes you're right. thanks. > > Thanks, > Chandra. > > > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Christian > Eric Edjenguele > Sent: Tuesday, September 01, 2009 9:52 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] [Openvas-commits] r4805 > -trunk/openvas-plugins/scripts > > Hi Chandra, I'm not certain about changes in this code, Jan told me > about some errors, but does identation solves the problem ? > > thanks. > > scm-commit at wald.intevation.org wrote: >> Author: chandra >> Date: 2009-09-01 12:58:12 +0200 (Tue, 01 Sep 2009) >> New Revision: 4805 > >> Modified: >> trunk/openvas-plugins/scripts/remote-MS04-017.nasl >> Log: >> Updated to resolve the issue in dump messages > >> Modified: trunk/openvas-plugins/scripts/remote-MS04-017.nasl >> =================================================================== >> --- trunk/openvas-plugins/scripts/remote-MS04-017.nasl 2009-09-01 > 09:22:54 UTC (rev 4804) >> +++ trunk/openvas-plugins/scripts/remote-MS04-017.nasl 2009-09-01 > 10:58:12 UTC (rev 4805) >> @@ -108,19 +108,22 @@ >> foreach page (pages) >> { >> soc = open_sock_tcp(port); >> - # build the malicious request >> - request = page + > '/crystalimagehandler.aspx?dynamicimage=../../../../../../../../../boot.ini' > ; >> + if(soc) >> + { >> + # build the malicious request >> + request = page + > '/crystalimagehandler.aspx?dynamicimage=../../../../../../../../../boot.ini' > ; > >> - qry = string('GET ' + request + ' HTTP/1.0\r\n', >> - 'Host: ' + h_ip + ':' + port + '\r\n\r\n'); >> + qry = string('GET ' + request + ' HTTP/1.0\r\n', >> + 'Host: ' + h_ip + ':' + port + '\r\n\r\n'); > >> - req = http_get(item:qry, port:port); >> - send(socket:soc, data: req); >> + req = http_get(item:qry, port:port); >> + send(socket:soc, data: req); > >> - # Get back the response >> - reply = recv(socket:soc, length:4096); >> + # Get back the response >> + reply = recv(socket:soc, length:4096); > >> - close(soc); >> + close(soc); >> + } > >> if(reply) >> { > >> _______________________________________________ >> Openvas-commits mailing list >> Openvas-commits at wald.intevation.org >> http://lists.wald.intevation.org/mailman/listinfo/openvas-commits > > _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel - -- Christian Eric Edjenguele IT Security Engineer PGP KeyID: 0xB1654498 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJKnhANAAoJENETScWxZUSY4sEIAK/RTa/g3QHLiIj8E+IC8Qcm 9AxIXsYRxRHX2j4vy8jjWWeTj2c3sY5Vfe+qJFbbNTSj6cHNQzssYY8F8ltb/r3G wJkHSpfPyIJxRZ7ULbl6wHuAlmIikUvGKu+T51u3w6RTabTF3QQPafmLQMLh6jKd c9QYxA+mLHrr2e/tIOBfrvK5Cu8/VLbKqv9ox8G1VQLDwWxswozc9DXc0pn4rSCk /g5RyDQpsq/izqvJ9BnjrnY+JxsWc/rqqB3a5ndkBQNhayvmufqN+UJa6tC+Ocv1 ASdtbhMygvyCl1mPFfPGvkZ7f0MY5UbDWSYxhQYYFL24oG8y6BM3tIFZxDTzuoc= =U5ET -----END PGP SIGNATURE----- From felix.wolfsteller at intevation.de Wed Sep 2 08:35:08 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 2 Sep 2009 08:35:08 +0200 Subject: [Openvas-devel] Concurrent hosts and tests options In-Reply-To: <2F9C6191A94B439ABE269704F22066B9@geoffPC> References: <56A6C883917E4ABCA547C2D13D495695@geoffPC> <4A9D8E8D.4010707@securityspace.com> <2F9C6191A94B439ABE269704F22066B9@geoffPC> Message-ID: <200909020835.08674.felix.wolfsteller@intevation.de> Outcome is: you should have maximally (#maxhost * #maxchecks) processes that run NVTs at the same time (per scan) + 1 openvasd "main" process + 1 openvasd process per scan serving the client and doing scheduling etc. Note though that there are some hardcoded limits (20 for checks I think). -- felix On Tuesday 01 September 2009 23:26:02 Geoff Galitz wrote: > Thanks Thomas. That was my understanding, but I needed to verify that for > my current project. > > -geoff > > > --------------------------------- > Geoff Galitz > Blankenheim NRW, Germany > http://www.galitz.org/ > http://german-way.com/blog/ > > > -----Original Message----- > > From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel- > > bounces at wald.intevation.org] On Behalf Of Thomas Reinke > > Sent: Dienstag, 1. September 2009 23:14 > > To: openvas-devel at wald.intevation.org > > Subject: Re: [Openvas-devel] Concurrent hosts and tests options > > > > A. Concurrent hosts - the # of hosts that are simultaneously tested. > > B. Concurrent tests - the # of tests (per host) that may be > > simultaneously run. > > > > If you launch a test against two machines (e.g. 192.168.1.1,192.168.1.2) > > you will start auditing both IPs simultaneously if and only if > > concurrent hosts is > 1. Within each IP being tested up to "B" > > concurrent tests will be run simultaneously, at most, providing > > plugin scheduling and dependencies allows for it. > > ... > > _______________________________________________ > 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 geoff at galitz.org Wed Sep 2 11:08:36 2009 From: geoff at galitz.org (Geoff Galitz) Date: Wed, 2 Sep 2009 11:08:36 +0200 Subject: [Openvas-devel] Concurrent hosts and tests options In-Reply-To: <200909020835.08674.felix.wolfsteller@intevation.de> References: <56A6C883917E4ABCA547C2D13D495695@geoffPC><4A9D8E8D.4010707@securityspace.com><2F9C6191A94B439ABE269704F22066B9@geoffPC> <200909020835.08674.felix.wolfsteller@intevation.de> Message-ID: > > Outcome is: you should have maximally (#maxhost * #maxchecks) processes > that > run NVTs at the same time (per scan) + 1 openvasd "main" process + 1 > openvasd > process per scan serving the client and doing scheduling etc. > Note though that there are some hardcoded limits (20 for checks I think). > Just to be clear... is that limit 20 checks per host or 20 checks total? I assume that would be 20 checks total. In other words, 20 simultaneous checks running maximum, no matter if you running on one host or one hundred at the same time. Correct? -geoff From openvas-bugs at wald.intevation.org Wed Sep 2 13:25:12 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Wed, 2 Sep 2009 13:25:12 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1112=5D_Use_of_/bi?= =?utf-8?q?n/sh_results_for_shell_scripts_in_erratic_behavior_on_Ub?= =?utf-8?q?untu?= Message-ID: <20090902112512.617E2852E8C0@pyrosoma.intevation.org> Bugs item #1112, was opened at 2009-09-02 13:25 Status: Open Priority: 3 Submitted By: Geoff Galitz (geoff) Assigned to: Nobody (None) Summary: Use of /bin/sh results for shell scripts in erratic behavior on Ubuntu Architecture: 64 Bit Resolution: None Severity: major Version: v2.0.3 Component: openvas-server Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: On Ubuntu, the /bin/sh shell is linked to /bin/dash, rather than /bin/bash which is more the standard on Linux distributions. OpenVAS shell scripts such as openvas-adduser run into problems in this scenario. Test operations frequently fail and execution of the script becomes erratic. Some still function, such as openvas-adduser, but others partially fail such as the client side LSC credential installation packages. Specifically, there are many bashims which do not work in dash. More info on this can be found at: https://wiki.ubuntu.com/DashAsBinSh The problem can be resolved on the sysadmin side of an Ubuntu solution by changing the default shell back to bash... but I'm not sure that is right solution. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1112&group_id=29 From michael.wiegand at intevation.de Thu Sep 3 15:17:59 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 3 Sep 2009 15:17:59 +0200 Subject: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: Migrate from OpenSSL to GNU/TLS Message-ID: <20090903131759.GC22161@intevation.de> Hi, I would like to call for votes on change request #35: "OpenVAS-Client: Migrate from OpenSSL to GNU/TLS" (see http://www.openvas.org/openvas-cr-35.html). Implementation of this CR would be a big step towards a working Windows client and would mean we could get rid of the OpenSSL licensing implications. Please vote +1 (for), +/-0 (don't care) or -1 (against). Feel free to ask if you have any questions regarding this CR. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090903/074890de/attachment.pgp From bchandra at secpod.com Thu Sep 3 15:23:34 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 3 Sep 2009 18:53:34 +0530 Subject: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: Migratefrom OpenSSL to GNU/TLS In-Reply-To: <20090903131759.GC22161@intevation.de> References: <20090903131759.GC22161@intevation.de> Message-ID: <485005FC715949D591EBE0C19B4EAC30@bchandra> +1 Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Michael Wiegand Sent: Thursday, September 03, 2009 6:48 PM To: OpenVAS Development List Subject: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: Migratefrom OpenSSL to GNU/TLS Hi, I would like to call for votes on change request #35: "OpenVAS-Client: Migrate from OpenSSL to GNU/TLS" (see http://www.openvas.org/openvas-cr-35.html). Implementation of this CR would be a big step towards a working Windows client and would mean we could get rid of the OpenSSL licensing implications. Please vote +1 (for), +/-0 (don't care) or -1 (against). Feel free to ask if you have any questions regarding this CR. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Thu Sep 3 15:24:27 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Thu, 3 Sep 2009 15:24:27 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline Message-ID: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> Hi, it is getting time to bring OpenVAS on the track to 3.0. First of all: I was initially thinking that we will have a 2.1 release first. However, IMHO the significant changes in architecture and features justify a 3.0. Main idea: OpenVAS 3.0 introduce various new features and a improved internal architcture. But it should not make OpenVAS-Manager mandatory yet. It rather should recommend to try out OpenVAS-Manager, because it will be supported well by OpenVAS 3.0. OpenVAS 4.0 should then have OpenVAS-Manager as mandatory default (while OTP is still being supported). OpenVAS 5.0 should not support OTP anymore - OMP is the protocol every client uses. New Features and changes in OpenVAS 3.0: * Drop module openvas-libnasl (done) * Drop module openvas-plugins (done) * IPv6 Support (in progress) * WMI-client support (done) * OpenVAS-Client depends on openvas-libraries (done) * OpenVAS-Client supports OMP (in progress) * OpenVAS-Client migrates from OpenSSL to GNU/TLS (in progress) * OpenVAS-Client offer command line client for OMP (in progress) * OpenVAS-Client compiles for Windows (in progress) * OpenVAS-Server uses new NVT cache (faster, no size limits for NVTs in the future) What I like to change for 3.0 also: * rename openvasd to openvassd for scan daemon. This would be in line with openvasmd (manager daemon) and openvascd (configuration daemon) * In fact, rename "openvas-server" to "openvas-scanner" because "server" is a bit too generic. * new rules file format. The rules are really badly managed. * new openvas(s)d.conf format: use keyfile here. Timeline: Have 3.0.0beta1 in October. Have 3.0.0 before Christmas. Please feel free to add things I forgot or you would like to add. Any other comments welcome as well. Perhaps we can generate some CRs out of this discussion. Anyone volunteering to create a nice roadmap webpage? (http://www.openvas.org/roadmap.html is a bit, well ... thin) All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Thu Sep 3 15:28:49 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Thu, 3 Sep 2009 15:28:49 +0200 Subject: [Openvas-devel] =?iso-8859-1?q?Call_for_Votes=3A_CR_=2335_-_OpenV?= =?iso-8859-1?q?AS-Client=3A_Migrate_from_OpenSSL_to=09GNU/TLS?= In-Reply-To: <20090903131759.GC22161@intevation.de> References: <20090903131759.GC22161@intevation.de> Message-ID: <200909031528.49703.felix.wolfsteller@intevation.de> +1 On Thursday 03 September 2009 15:17:59 Michael Wiegand wrote: > Hi, > > I would like to call for votes on change request #35: "OpenVAS-Client: > Migrate from OpenSSL to GNU/TLS" (see > http://www.openvas.org/openvas-cr-35.html). > > Implementation of this CR would be a big step towards a working Windows > client and would mean we could get rid of the OpenSSL licensing > implications. > > Please vote +1 (for), +/-0 (don't care) or -1 (against). Feel free to > ask if you have any questions regarding this CR. > > 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 mime at gmx.de Thu Sep 3 15:38:35 2009 From: mime at gmx.de (Michael Meyer) Date: Thu, 3 Sep 2009 15:38:35 +0200 Subject: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: Migrate from OpenSSL to GNU/TLS In-Reply-To: <20090903131759.GC22161@intevation.de> References: <20090903131759.GC22161@intevation.de> Message-ID: <20090903133835.GA4373@komma-nix.de> *** Michael Wiegand wrote: > Migrate from OpenSSL to GNU/TLS" (see > http://www.openvas.org/openvas-cr-35.html). +1 Micha From c_edjenguele at yahoo.it Thu Sep 3 15:39:41 2009 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Thu, 3 Sep 2009 13:39:41 +0000 (GMT) Subject: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: Migratefrom OpenSSL to GNU/TLS In-Reply-To: <485005FC715949D591EBE0C19B4EAC30@bchandra> References: <20090903131759.GC22161@intevation.de> <485005FC715949D591EBE0C19B4EAC30@bchandra> Message-ID: <949287.69607.qm@web28606.mail.ukl.yahoo.com> +1 --- Christian Eric Edjenguele IT Security Engineer ----- Messaggio originale ----- > Da: Chandrashekhar B > A: OpenVAS Development List > Inviato: Gioved? 3 settembre 2009, 15:23:34 > Oggetto: Re: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: Migratefrom OpenSSL to GNU/TLS > > +1 > > Chandra. > > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Michael > Wiegand > Sent: Thursday, September 03, 2009 6:48 PM > To: OpenVAS Development List > Subject: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: > Migratefrom OpenSSL to GNU/TLS > > Hi, > > I would like to call for votes on change request #35: "OpenVAS-Client: > Migrate from OpenSSL to GNU/TLS" (see > http://www.openvas.org/openvas-cr-35.html). > > Implementation of this CR would be a big step towards a working Windows > client and would mean we could get rid of the OpenSSL licensing > implications. > > Please vote +1 (for), +/-0 (don't care) or -1 (against). Feel free to > ask if you have any questions regarding this CR. > > Regards, > > Michael > > -- > Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de > Neuer Graben 17, 49074 Osnabr?ck, Germany | 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 labeneator at gmail.com Thu Sep 3 15:41:45 2009 From: labeneator at gmail.com (Laban Mwangi) Date: Thu, 03 Sep 2009 17:41:45 +0400 Subject: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: Migratefrom OpenSSL to GNU/TLS In-Reply-To: <949287.69607.qm@web28606.mail.ukl.yahoo.com> References: <20090903131759.GC22161@intevation.de> <485005FC715949D591EBE0C19B4EAC30@bchandra> <949287.69607.qm@web28606.mail.ukl.yahoo.com> Message-ID: <1251985305.17431.38.camel@hyperion.penguinlabs.co.ke> +1 On Thu, 2009-09-03 at 13:39 +0000, Christian Eric EDJENGUELE wrote: > +1 > > --- > Christian Eric Edjenguele > IT Security Engineer > > > > > ----- Messaggio originale ----- > > Da: Chandrashekhar B > > A: OpenVAS Development List > > Inviato: Gioved? 3 settembre 2009, 15:23:34 > > Oggetto: Re: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: Migratefrom OpenSSL to GNU/TLS > > > > +1 > > > > Chandra. > > > > -----Original Message----- > > From: openvas-devel-bounces at wald.intevation.org > > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Michael > > Wiegand > > Sent: Thursday, September 03, 2009 6:48 PM > > To: OpenVAS Development List > > Subject: [Openvas-devel] Call for Votes: CR #35 - OpenVAS-Client: > > Migratefrom OpenSSL to GNU/TLS > > > > Hi, > > > > I would like to call for votes on change request #35: "OpenVAS-Client: > > Migrate from OpenSSL to GNU/TLS" (see > > http://www.openvas.org/openvas-cr-35.html). > > > > Implementation of this CR would be a big step towards a working Windows > > client and would mean we could get rid of the OpenSSL licensing > > implications. > > > > Please vote +1 (for), +/-0 (don't care) or -1 (against). Feel free to > > ask if you have any questions regarding this CR. > > > > Regards, > > > > Michael > > > > -- > > Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de > > Neuer Graben 17, 49074 Osnabr?ck, Germany | 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 > > > > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel -------------- 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/20090903/476f49ec/attachment-0001.pgp From Jan-Oliver.Wagner at greenbone.net Thu Sep 3 17:40:42 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Thu, 3 Sep 2009 17:40:42 +0200 Subject: [Openvas-devel] =?utf-8?q?Call_for_Votes=3A_CR_=2335_-_OpenVAS-Cl?= =?utf-8?q?ient=3A_Migrate_from_OpenSSL_to=09GNU/TLS?= In-Reply-To: <20090903131759.GC22161@intevation.de> References: <20090903131759.GC22161@intevation.de> Message-ID: <200909031740.42640.Jan-Oliver.Wagner@greenbone.net> On Thursday 03 September 2009 15:17:59 Michael Wiegand wrote: > I would like to call for votes on change request #35: "OpenVAS-Client: > Migrate from OpenSSL to GNU/TLS" (see > http://www.openvas.org/openvas-cr-35.html). +1 -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Fri Sep 4 10:24:06 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 4 Sep 2009 10:24:06 +0200 Subject: [Openvas-devel] CR #40 - find_service.c In-Reply-To: <4A7C9C7D.5030608@securityspace.com> References: <4A7C9C7D.5030608@securityspace.com> Message-ID: <200909041024.06833.Jan-Oliver.Wagner@greenbone.net> Hi Thomas, On Friday 07 August 2009 23:28:29 Thomas Reinke wrote: > We've put up a CR (http://www.openvas.org/openvas-cr-40.html) > to facilitate discussion on the concept of replacing the existing > find_service.c thanks a lot for this! > In the CR, while I make note of the ability for us to replace > find_service.c, there are certain issues with doing that. > > I've documented the problems, while also proposing an altered > approach that allows us to avoid these problems while still > meeting our goals of > > a) being able to update detection methods with the script feed > b) leveraging nmap's service detection database. > > Please read and comment. I completely agree with the porposed approach. The question whether to distribute a signature file via the feed can be answered later and even easily implemented. So that does not prevent us from starting to work on this. Would you volunteer to implement the new NASL script? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Fri Sep 4 10:27:09 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 4 Sep 2009 10:27:09 +0200 Subject: [Openvas-devel] Call for vote CR#40: NMAP service detection Message-ID: <200909041027.09620.Jan-Oliver.Wagner@greenbone.net> Hello, a while ago Thomas submitted the Change Request #40 about the NMAP service detection and replacement strategy for find_services.c. I have received only positive comments so far and I would like to call for a vote on this CR now. My vote is: +1 Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Fri Sep 4 11:01:08 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Fri, 4 Sep 2009 11:01:08 +0200 Subject: [Openvas-devel] Call for vote CR#40: NMAP service detection In-Reply-To: <200909041027.09620.Jan-Oliver.Wagner@greenbone.net> References: <200909041027.09620.Jan-Oliver.Wagner@greenbone.net> Message-ID: <20090904090108.GB16434@intevation.de> * Jan-Oliver Wagner [ 4. Sep 2009]: > Hello, > > a while ago Thomas submitted the Change Request #40 about > the NMAP service detection and replacement strategy for find_services.c. > > I have received only positive comments so far and I would like to > call for a vote on this CR now. +1 Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090904/1f469db1/attachment.pgp From lists at securityspace.com Fri Sep 4 15:18:53 2009 From: lists at securityspace.com (Thomas Reinke) Date: Fri, 04 Sep 2009 09:18:53 -0400 Subject: [Openvas-devel] Call for vote CR#40: NMAP service detection In-Reply-To: <200909041027.09620.Jan-Oliver.Wagner@greenbone.net> References: <200909041027.09620.Jan-Oliver.Wagner@greenbone.net> Message-ID: <4AA113BD.2060400@securityspace.com> +1 Thomas Jan-Oliver Wagner wrote: > Hello, > > a while ago Thomas submitted the Change Request #40 about > the NMAP service detection and replacement strategy for find_services.c. > > I have received only positive comments so far and I would like to > call for a vote on this CR now. > > My vote is: +1 > > Best > > Jan > From mime at gmx.de Fri Sep 4 15:22:58 2009 From: mime at gmx.de (Michael Meyer) Date: Fri, 4 Sep 2009 15:22:58 +0200 Subject: [Openvas-devel] Call for vote CR#40: NMAP service detection In-Reply-To: <200909041027.09620.Jan-Oliver.Wagner@greenbone.net> References: <200909041027.09620.Jan-Oliver.Wagner@greenbone.net> Message-ID: <20090904132258.GA5144@komma-nix.de> *** Jan-Oliver Wagner wrote: > a while ago Thomas submitted the Change Request #40 about > the NMAP service detection and replacement strategy for find_services.c. +1 Micha From lists at securityspace.com Fri Sep 4 16:07:57 2009 From: lists at securityspace.com (Thomas Reinke) Date: Fri, 04 Sep 2009 10:07:57 -0400 Subject: [Openvas-devel] CR #40 - find_service.c In-Reply-To: <200909041024.06833.Jan-Oliver.Wagner@greenbone.net> References: <4A7C9C7D.5030608@securityspace.com> <200909041024.06833.Jan-Oliver.Wagner@greenbone.net> Message-ID: <4AA11F3D.6010703@securityspace.com> > Would you volunteer to implement the new NASL script? That was the plan. Thomas -- SecuritySpace Support From Jan-Oliver.Wagner at greenbone.net Fri Sep 4 16:16:30 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 4 Sep 2009 16:16:30 +0200 Subject: [Openvas-devel] openvasd -S option In-Reply-To: References: Message-ID: <200909041616.30311.Jan-Oliver.Wagner@greenbone.net> Hi, On Thursday 20 August 2009 12:40:05 Chandrashekhar B wrote: > As per the 'openvasd --help', '-S' says 'Send packets with a source IP...'. > Whatever IP we supply to this, the packets originating from the server are > always with the actual server IP and not what is supplied. The code seems to > have some logic to set the Source IP to 'ANY' but never works. > > The question is: what is the purpose behind this? And is it useful? If not > really used, may be time to remove the unwanted code. We are working on the > IPv6 support, could clean up this code. Any concerns or feedback is > appreciated. though I never used this option, I am not convinced this is not needed at all. Various special cases seem to need it, google says. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From geoff at galitz.org Fri Sep 4 16:35:57 2009 From: geoff at galitz.org (Geoff Galitz) Date: Fri, 4 Sep 2009 16:35:57 +0200 Subject: [Openvas-devel] openvasd -S option In-Reply-To: <200909041616.30311.Jan-Oliver.Wagner@greenbone.net> References: <200909041616.30311.Jan-Oliver.Wagner@greenbone.net> Message-ID: <8C169CEBED3A4D22ADB50916E9E997E2@geoffPC> Changing the source IP is frequently used for IDS evasion and spoofing the address of another system or network to get around firewall rules. Typically the spoofing does not work so well with TCP connections, but is more effective with UDP scans. If the scanner was on the same local network as the target the TCP spoofed scan would stand a better chance of success (since the MAC address would still be intact). I think it would be useful to retain this feature. It is good for auditing firewall and IDS systems. -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ > -----Original Message----- > > though I never used this option, I am not convinced this > is not needed at all. Various special cases seem to need it, > google says. > ... From timb at openvas.org Fri Sep 4 16:42:15 2009 From: timb at openvas.org (Tim Brown) Date: Fri, 4 Sep 2009 15:42:15 +0100 Subject: [Openvas-devel] openvasd -S option In-Reply-To: <8C169CEBED3A4D22ADB50916E9E997E2@geoffPC> References: <200909041616.30311.Jan-Oliver.Wagner@greenbone.net> <8C169CEBED3A4D22ADB50916E9E997E2@geoffPC> Message-ID: <200909041542.17925.timb@openvas.org> On Friday 04 September 2009 15:35:57 Geoff Galitz wrote: > Changing the source IP is frequently used for IDS evasion and spoofing the > address of another system or network to get around firewall rules. > Typically the spoofing does not work so well with TCP connections, but is > more effective with UDP scans. If the scanner was on the same local > network as the target the TCP spoofed scan would stand a better chance of > success (since the MAC address would still be intact). > > I think it would be useful to retain this feature. It is good for auditing > firewall and IDS systems. Also useful it you have a multi homed machine and want to force traffic down a specific interface irrespective of routes. Tim -- Tim Brown From bchandra at secpod.com Fri Sep 4 16:55:18 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 4 Sep 2009 20:25:18 +0530 Subject: [Openvas-devel] openvasd -S option In-Reply-To: <8C169CEBED3A4D22ADB50916E9E997E2@geoffPC> References: <200909041616.30311.Jan-Oliver.Wagner@greenbone.net> <8C169CEBED3A4D22ADB50916E9E997E2@geoffPC> Message-ID: <05059E921BDD4A1EA6120A21FB52226F@bchandra> Spoofing or packet forgery is seperately implemneted in NASL. Targets auditing is done using those functions. -S option is for the server. I am not able to realize the need for server to spoof. Jan: Can you point to some links from google? Thanks, Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Geoff Galitz Sent: Friday, September 04, 2009 8:06 PM To: 'Jan-Oliver Wagner'; openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] openvasd -S option Changing the source IP is frequently used for IDS evasion and spoofing the address of another system or network to get around firewall rules. Typically the spoofing does not work so well with TCP connections, but is more effective with UDP scans. If the scanner was on the same local network as the target the TCP spoofed scan would stand a better chance of success (since the MAC address would still be intact). I think it would be useful to retain this feature. It is good for auditing firewall and IDS systems. -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ > -----Original Message----- > > though I never used this option, I am not convinced this > is not needed at all. Various special cases seem to need it, > google says. > ... _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From bchandra at secpod.com Fri Sep 4 16:56:09 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 4 Sep 2009 20:26:09 +0530 Subject: [Openvas-devel] openvasd -S option In-Reply-To: <200909041542.17925.timb@openvas.org> References: <200909041616.30311.Jan-Oliver.Wagner@greenbone.net><8C169CEBED3A4D22ADB50916E9E997E2@geoffPC> <200909041542.17925.timb@openvas.org> Message-ID: <6D4075D0BD12499C94D2ECB346F6CC96@bchandra> -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Tim Brown Sent: Friday, September 04, 2009 8:12 PM To: openvas-devel at wald.intevation.org Cc: 'Jan-Oliver Wagner' Subject: Re: [Openvas-devel] openvasd -S option On Friday 04 September 2009 15:35:57 Geoff Galitz wrote: >> Changing the source IP is frequently used for IDS evasion and spoofing the >> address of another system or network to get around firewall rules. >> Typically the spoofing does not work so well with TCP connections, but is >> more effective with UDP scans. If the scanner was on the same local >> network as the target the TCP spoofed scan would stand a better chance of >> success (since the MAC address would still be intact). >> >> I think it would be useful to retain this feature. It is good for auditing >> firewall and IDS systems. > Also useful it you have a multi homed machine and want to force traffic down a > specific interface irrespective of routes. This looks to be the real purpose! Chandra. From Jan-Oliver.Wagner at greenbone.net Sun Sep 6 11:06:18 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Sun, 6 Sep 2009 11:06:18 +0200 Subject: [Openvas-devel] Get rid of old services concept Message-ID: <200909061106.18664.Jan-Oliver.Wagner@greenbone.net> Hi, I looked at the code/concept we inherited from Nessus regarding services handling (modules openvas-libraries/misc/services*). To me it looks like multiple broken concept. What I understand so far is: * /etc/services is used through the standard glibc API * in openvas-server there is a openvas-services file that may work as an alternative to the system wide file. * nmap knows even more about services. What's broken? (I might be wrong here, so please comment, discuss) * My guess is that the nessus authors believed the system wide file is not always enough up-to-date. With their own file they unlink dependency to OS version and introduce dependency link to Scanner version. This leads to the problem that in several cases, people may use even older services data because they use an old scanner on a new OS. They might also have had the intention to make the scanner run on Windows eventually. * It is questionalbel whether it makes sense at all to maintain services database on out own at all. In case we would do it, the only sensible way is to distribute it over the feed so it is always uptodate. * What we might really want is to share effords with the nmap people. Distributuing the newes data via the feed remains still an option here. What to do? IMHO, we should drop the whole services code stuff and use the glibc API using a thin layer that allows us to go for a nmap database distributed via feed. You opinions welcome! Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Mon Sep 7 12:22:22 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 7 Sep 2009 12:22:22 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> Message-ID: <200909071222.22856.felix.wolfsteller@intevation.de> Personally, I would like to see at least these two features in 3.0: - Integration of a library for doing the ssh stuff - Service identification revamped/nmap We also should have logging done right at some point. I expect this being too much work for 3.0, though (correct me). -- felix On Thursday 03 September 2009 15:24:27 Jan-Oliver Wagner wrote: > Hi, > > it is getting time to bring OpenVAS on the track to 3.0. > > First of all: I was initially thinking that we will have a 2.1 release > first. However, IMHO the significant changes in architecture > and features justify a 3.0. > > Main idea: > OpenVAS 3.0 introduce various new features and > a improved internal architcture. But it should not make > OpenVAS-Manager mandatory yet. It rather should > recommend to try out OpenVAS-Manager, because > it will be supported well by OpenVAS 3.0. > OpenVAS 4.0 should then have OpenVAS-Manager > as mandatory default (while OTP is still being supported). > OpenVAS 5.0 should not support OTP anymore - OMP > is the protocol every client uses. > > New Features and changes in OpenVAS 3.0: > > * Drop module openvas-libnasl (done) > * Drop module openvas-plugins (done) > * IPv6 Support (in progress) > * WMI-client support (done) > * OpenVAS-Client depends on openvas-libraries (done) > * OpenVAS-Client supports OMP (in progress) > * OpenVAS-Client migrates from OpenSSL to GNU/TLS (in progress) > * OpenVAS-Client offer command line client for OMP (in progress) > * OpenVAS-Client compiles for Windows (in progress) > * OpenVAS-Server uses new NVT cache (faster, no size limits for NVTs in the > future) > > What I like to change for 3.0 also: > > * rename openvasd to openvassd for scan daemon. > This would be in line with openvasmd (manager daemon) > and openvascd (configuration daemon) > > * In fact, rename "openvas-server" to "openvas-scanner" > because "server" is a bit too generic. > > * new rules file format. The rules are really badly managed. > > * new openvas(s)d.conf format: use keyfile here. > > Timeline: > > Have 3.0.0beta1 in October. > Have 3.0.0 before Christmas. > > > Please feel free to add things I forgot or you would like to add. > Any other comments welcome as well. > Perhaps we can generate some CRs out of this discussion. > > Anyone volunteering to create a nice roadmap webpage? > (http://www.openvas.org/roadmap.html is a bit, well ... thin) > > All the 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 Jan-Oliver.Wagner at greenbone.net Mon Sep 7 14:43:23 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 7 Sep 2009 14:43:23 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <200909071222.22856.felix.wolfsteller@intevation.de> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <200909071222.22856.felix.wolfsteller@intevation.de> Message-ID: <200909071443.23655.Jan-Oliver.Wagner@greenbone.net> On Monday 07 September 2009 12:22:22 Felix Wolfsteller wrote: > Personally, I would like to see at least these two features in 3.0: > > - Integration of a library for doing the ssh stuff IIRC, no one yet volunteered to do that. I don't regard this a blocker for 3.0. > - Service identification revamped/nmap thats CR#40 currently being voted. > We also should have logging done right at some point. I expect this being too > much work for 3.0, though (correct me). yes, that was missing on my wish list. Laban works on it. And Matt did some improvements. I've seen no master plan for finalization of this feature. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From bchandra at secpod.com Mon Sep 7 15:28:08 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 7 Sep 2009 18:58:08 +0530 Subject: [Openvas-devel] Get rid of old services concept In-Reply-To: <200909061106.18664.Jan-Oliver.Wagner@greenbone.net> References: <200909061106.18664.Jan-Oliver.Wagner@greenbone.net> Message-ID: <4F3B84AD3D95497E979608B68333E4C9@bchandra> -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Sunday, September 06, 2009 2:36 PM To: openvas-devel at wald.intevation.org Subject: [Openvas-devel] Get rid of old services concept > * It is questionalbel whether it makes sense at all > to maintain services database on out own at all. > In case we would do it, the only sensible way > is to distribute it over the feed so it is always > uptodate. Maintaining on our own, you mean, distributing through openvas-nvt-sync? I think it should only be distribution and there's no maintenance. >* What we might really want is to share effords > with the nmap people. Distributuing the newes > data via the feed remains still an option here. > What to do? > IMHO, we should drop the whole services code > stuff and use the glibc API using a thin layer > that allows us to go for a nmap database > distributed via feed. I agree. NMAP is the way to go. Thanks, Chandra. From bchandra at secpod.com Mon Sep 7 15:31:48 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 7 Sep 2009 19:01:48 +0530 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> Message-ID: <9FB4B1A86235413BB6346E91A35B0A1C@bchandra> I have two items in my agenda, to write CR's for, - Description separation from the code in NVT's - SMB library integration for SMB/DCERPC packet crafting. This can go for 3.0 or may be for later releases. Thanks, 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: Thursday, September 03, 2009 6:54 PM To: openvas-devel at wald.intevation.org Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline Hi, it is getting time to bring OpenVAS on the track to 3.0. First of all: I was initially thinking that we will have a 2.1 release first. However, IMHO the significant changes in architecture and features justify a 3.0. Main idea: OpenVAS 3.0 introduce various new features and a improved internal architcture. But it should not make OpenVAS-Manager mandatory yet. It rather should recommend to try out OpenVAS-Manager, because it will be supported well by OpenVAS 3.0. OpenVAS 4.0 should then have OpenVAS-Manager as mandatory default (while OTP is still being supported). OpenVAS 5.0 should not support OTP anymore - OMP is the protocol every client uses. New Features and changes in OpenVAS 3.0: * Drop module openvas-libnasl (done) * Drop module openvas-plugins (done) * IPv6 Support (in progress) * WMI-client support (done) * OpenVAS-Client depends on openvas-libraries (done) * OpenVAS-Client supports OMP (in progress) * OpenVAS-Client migrates from OpenSSL to GNU/TLS (in progress) * OpenVAS-Client offer command line client for OMP (in progress) * OpenVAS-Client compiles for Windows (in progress) * OpenVAS-Server uses new NVT cache (faster, no size limits for NVTs in the future) What I like to change for 3.0 also: * rename openvasd to openvassd for scan daemon. This would be in line with openvasmd (manager daemon) and openvascd (configuration daemon) * In fact, rename "openvas-server" to "openvas-scanner" because "server" is a bit too generic. * new rules file format. The rules are really badly managed. * new openvas(s)d.conf format: use keyfile here. Timeline: Have 3.0.0beta1 in October. Have 3.0.0 before Christmas. Please feel free to add things I forgot or you would like to add. Any other comments welcome as well. Perhaps we can generate some CRs out of this discussion. Anyone volunteering to create a nice roadmap webpage? (http://www.openvas.org/roadmap.html is a bit, well ... thin) All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, 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 greenbone.net Mon Sep 7 15:50:39 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 7 Sep 2009 15:50:39 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <9FB4B1A86235413BB6346E91A35B0A1C@bchandra> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <9FB4B1A86235413BB6346E91A35B0A1C@bchandra> Message-ID: <200909071550.39929.Jan-Oliver.Wagner@greenbone.net> On Monday 07 September 2009 15:31:48 Chandrashekhar B wrote: > I have two items in my agenda, to write CR's for, > - Description separation from the code in NVT's I don't think this big change should be with 3.0. There are too many details to be discussed, evaluated and tested. > - SMB library integration for SMB/DCERPC packet crafting. A work that can be started already (with preparing a CR). We can see how fast it gets done and flexibly decide whether to make it part of 3.0 or not. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From christian.edjenguele at owasp.org Mon Sep 7 16:24:53 2009 From: christian.edjenguele at owasp.org (Christian Eric Edjenguele) Date: Mon, 07 Sep 2009 16:24:53 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <9FB4B1A86235413BB6346E91A35B0A1C@bchandra> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <9FB4B1A86235413BB6346E91A35B0A1C@bchandra> Message-ID: <4AA517B5.8040107@owasp.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chandrashekhar B wrote: > I have two items in my agenda, to write CR's for, > - Description separation from the code in NVT's This is a prety good idea, in fact it should be great to keep description out of code, maybe in in some database. This could also solve some problems such as duplicate script_id, using an auto-increment based on user commits. > - SMB library integration for SMB/DCERPC packet crafting. > > This can go for 3.0 or may be for later releases. > > Thanks, > 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: Thursday, September 03, 2009 6:54 PM > To: openvas-devel at wald.intevation.org > Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline > > Hi, > > it is getting time to bring OpenVAS on the track to 3.0. > > First of all: I was initially thinking that we will have a 2.1 release > first. However, IMHO the significant changes in architecture > and features justify a 3.0. > > Main idea: > OpenVAS 3.0 introduce various new features and > a improved internal architcture. But it should not make > OpenVAS-Manager mandatory yet. It rather should > recommend to try out OpenVAS-Manager, because > it will be supported well by OpenVAS 3.0. > OpenVAS 4.0 should then have OpenVAS-Manager > as mandatory default (while OTP is still being supported). > OpenVAS 5.0 should not support OTP anymore - OMP > is the protocol every client uses. > > New Features and changes in OpenVAS 3.0: > > * Drop module openvas-libnasl (done) > * Drop module openvas-plugins (done) > * IPv6 Support (in progress) > * WMI-client support (done) > * OpenVAS-Client depends on openvas-libraries (done) > * OpenVAS-Client supports OMP (in progress) > * OpenVAS-Client migrates from OpenSSL to GNU/TLS (in progress) > * OpenVAS-Client offer command line client for OMP (in progress) > * OpenVAS-Client compiles for Windows (in progress) > * OpenVAS-Server uses new NVT cache (faster, no size limits for NVTs in the > future) > > What I like to change for 3.0 also: > > * rename openvasd to openvassd for scan daemon. > This would be in line with openvasmd (manager daemon) > and openvascd (configuration daemon) > > * In fact, rename "openvas-server" to "openvas-scanner" > because "server" is a bit too generic. > > * new rules file format. The rules are really badly managed. > > * new openvas(s)d.conf format: use keyfile here. > > Timeline: > > Have 3.0.0beta1 in October. > Have 3.0.0 before Christmas. > > > Please feel free to add things I forgot or you would like to add. > Any other comments welcome as well. > Perhaps we can generate some CRs out of this discussion. > > Anyone volunteering to create a nice roadmap webpage? > (http://www.openvas.org/roadmap.html is a bit, well ... thin) > > All the best > > Jan > - -- Christian Eric Edjenguele IT Security Engineer PGP KeyID: 0xB1654498 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJKpRetAAoJENETScWxZUSYGGQIAIp52waLcfKG+2lYRbOHZ8+5 /kzn+dFuDrGoA+f+ic0yH6sH8wJrPMTOVm+lbSnjeiZo/3zr9j9r+KcCDafhdm/p eZPxb/7XzUEbeADXYW6WRbMvkMrfqGDErNHhWSYpznmYeTCOTepipHzIYL1je7vG U0UrX4Mb6weUfY9VT3P+O2eRz4GPxbykhUNrBm2/O2OI1ofRQl6VMCBQUmR3St4P fzo7HgMNVVPiTcQZNJVOQ/y5bO7QXDh15mfNcyppdxfyKZx9YmrvwaMcr2rv5cr0 jG8bTqM7DUYFkh8N4RxhDENMNl3cJbyfGjzGmpjZjvjWj9zwB/u7oDb+a+0K9wM= =EFGs -----END PGP SIGNATURE----- From Jan-Oliver.Wagner at greenbone.net Mon Sep 7 20:14:32 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 7 Sep 2009 20:14:32 +0200 Subject: [Openvas-devel] Get rid of old services concept In-Reply-To: <4F3B84AD3D95497E979608B68333E4C9@bchandra> References: <200909061106.18664.Jan-Oliver.Wagner@greenbone.net> <4F3B84AD3D95497E979608B68333E4C9@bchandra> Message-ID: <200909072014.32658.Jan-Oliver.Wagner@greenbone.net> On Monday 07 September 2009 15:28:08 Chandrashekhar B wrote: > > * It is questionalbel whether it makes sense at all > > to maintain services database on out own at all. > > In case we would do it, the only sensible way > > is to distribute it over the feed so it is always > > uptodate. > > Maintaining on our own, you mean, distributing through openvas-nvt-sync? I > think it should only be distribution and there's no maintenance. yes. Distributing the database that we think is best. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From lists at securityspace.com Mon Sep 7 20:58:45 2009 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 07 Sep 2009 14:58:45 -0400 Subject: [Openvas-devel] Get rid of old services concept In-Reply-To: <200909061106.18664.Jan-Oliver.Wagner@greenbone.net> References: <200909061106.18664.Jan-Oliver.Wagner@greenbone.net> Message-ID: <4AA557E5.1050206@securityspace.com> Jan-Oliver Wagner wrote: > Hi, > > I looked at the code/concept we inherited from Nessus > regarding services handling (modules openvas-libraries/misc/services*). > > To me it looks like multiple broken concept. > > What I understand so far is: > > * /etc/services is used through the standard glibc API > * in openvas-server there is a openvas-services file > that may work as an alternative to the system wide > file. > * nmap knows even more about services. > > What's broken? > (I might be wrong here, so please comment, discuss) > > * My guess is that the nessus authors believed > the system wide file is not always enough up-to-date. > With their own file they unlink dependency to OS version > and introduce dependency link to Scanner version. As far as I can see, the daemon does a fallback to glibc linked to /etc/services - it's just that first dibs are given to the daemon's version of the services file, and only if the name cannot be found does it fall back to glibc use of /etc/services. > This leads to the problem that in several cases, people > may use even older services data because they use > an old scanner on a new OS. > They might also have had the intention to make > the scanner run on Windows eventually. > > * It is questionalbel whether it makes sense at all > to maintain services database on out own at all. > In case we would do it, the only sensible way > is to distribute it over the feed so it is always > uptodate. > > * What we might really want is to share effords > with the nmap people. Distributuing the newes > data via the feed remains still an option here. > > What to do? > > IMHO, we should drop the whole services code > stuff and use the glibc API using a thin layer > that allows us to go for a nmap database > distributed via feed. > > You opinions welcome! I'm not sure I see too much wrong with the fall-back approach currently in use. That being said, the services file I think could benefit from being distributed with the feed to have it be up to date, so moving this file from the $CONF directory to the script feed direction seems to make good sense. Thomas From Jan-Oliver.Wagner at greenbone.net Wed Sep 9 10:26:26 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 9 Sep 2009 10:26:26 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> Message-ID: <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> Hi, I'd like to stress that the renaming should really be done for the sake of consistent and easy to understand wording. On Thursday 03 September 2009 15:24:27 Jan-Oliver Wagner wrote: > What I like to change for 3.0 also: > > * rename openvasd to openvassd for scan daemon. > This would be in line with openvasmd (manager daemon) > and openvascd (configuration daemon) > > * In fact, rename "openvas-server" to "openvas-scanner" > because "server" is a bit too generic. Ideally we should end up with: Module names: openvas-scanner, opernvas-manager, openvas-administrator, openvas-client and openvas-libraries. Daemon names: openvassd, openvasmd, openvasad Protocol names: OSP (OpenVAS Scanner Protocol, a yet to be designed protocol that is in line with the design of OMP), OMP (OpenVAS Manager Protocol) and OAP (OpenVAS Administrator Protocol). Please let us know if you agree, don't agree with this or like to add thoughts. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From geoff at galitz.org Wed Sep 9 10:39:46 2009 From: geoff at galitz.org (Geoff Galitz) Date: Wed, 9 Sep 2009 10:39:46 +0200 Subject: [Openvas-devel] SSH cipher selection Message-ID: Hi folks. Is it possible to select an alternate cipher for SSH than blowfish-cbc when doing local checks via SSH? I looked at ssh_func.inc and played around with it a bit, but the answer was not forthcoming (unless the answer is... "no"). -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090909/bc727baa/attachment.html From matthew.mundell at intevation.de Wed Sep 9 11:06:42 2009 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 09 Sep 2009 09:05:42 -0001 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: Message of Wed, 9 Sep 2009 10:26:26 +0200. <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> Message-ID: <20090909090639.4A4D3DEFD8@mail.ukfsn.org> > Module names: > openvas-scanner, opernvas-manager, openvas-administrator, > openvas-client and openvas-libraries. > > Daemon names: openvassd, openvasmd, openvasad > > Protocol names: OSP (OpenVAS Scanner Protocol, > a yet to be designed protocol that is in line with > the design of OMP), OMP (OpenVAS Manager Protocol) > and OAP (OpenVAS Administrator Protocol). > > Please let us know if you agree, don't agree with this > or like to add thoughts. I like the names. Administrator is a bit long, but it's better than configuration. I think OpenVAS-Client should be brought in line with the daemon names, maybe it could just be "openvas". -- Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From c_edjenguele at yahoo.it Wed Sep 9 11:14:48 2009 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Wed, 9 Sep 2009 09:14:48 +0000 (GMT) Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> Message-ID: <315592.12903.qm@web28607.mail.ukl.yahoo.com> I completly agree with that. Best. --- Christian Eric Edjenguele IT Security Engineer & Researcher ----- Messaggio originale ----- > Da: Jan-Oliver Wagner > A: openvas-devel at wald.intevation.org > Inviato: Mercoled? 9 settembre 2009, 10:26:26 > Oggetto: Re: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline > > Hi, > > I'd like to stress that the renaming should really be done > for the sake of consistent and easy to understand wording. > > On Thursday 03 September 2009 15:24:27 Jan-Oliver Wagner wrote: > > What I like to change for 3.0 also: > > > > * rename openvasd to openvassd for scan daemon. > > This would be in line with openvasmd (manager daemon) > > and openvascd (configuration daemon) > > > > * In fact, rename "openvas-server" to "openvas-scanner" > > because "server" is a bit too generic. > > Ideally we should end up with: > > Module names: > openvas-scanner, opernvas-manager, openvas-administrator, > openvas-client and openvas-libraries. > > Daemon names: openvassd, openvasmd, openvasad > > Protocol names: OSP (OpenVAS Scanner Protocol, > a yet to be designed protocol that is in line with > the design of OMP), OMP (OpenVAS Manager Protocol) > and OAP (OpenVAS Administrator Protocol). > > Please let us know if you agree, don't agree with this > or like to add thoughts. > > Best > > Jan > > -- > Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ > Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck > AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver > Wagner > _______________________________________________ > 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 Sep 9 11:27:44 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 9 Sep 2009 11:27:44 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <20090909090639.4A4D3DEFD8@mail.ukfsn.org> References: <20090909090639.4A4D3DEFD8@mail.ukfsn.org> Message-ID: <200909091127.44455.felix.wolfsteller@intevation.de> On Wednesday 09 September 2009 11:06:42 Matthew Mundell wrote: > I think OpenVAS-Client should be brought in line with the daemon names I definately agree with that. The mixed case "OpenVAS-Client" is some weird name for an executable. Which might bring up another 3.0 "feature" that also would clean up code in client a little bit: - separate executables for the "batch mode" (non-graphical) and the gtk client (i think that is a nice "junior job" btw). -- felix -- Felix Wolfsteller | ++49 541 335083-783 | 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 geoff at galitz.org Thu Sep 10 13:59:23 2009 From: geoff at galitz.org (Geoff Galitz) Date: Thu, 10 Sep 2009 13:59:23 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> Message-ID: <247B05C8918D410BB117570726FEB266@geoffPC> What is the "openvas-administrator?" While I like the names, I'd like to recommend at this point that anything with a "d" on the end not require the "-D" option to go into daemon mode. A trailing "d" is a defacto standard that specifies an application will automatically daemonize itself. -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ > Ideally we should end up with: > > Module names: > openvas-scanner, opernvas-manager, openvas-administrator, > openvas-client and openvas-libraries. > > Daemon names: openvassd, openvasmd, openvasad > From michael.wiegand at intevation.de Thu Sep 10 14:04:42 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 10 Sep 2009 14:04:42 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <247B05C8918D410BB117570726FEB266@geoffPC> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> <247B05C8918D410BB117570726FEB266@geoffPC> Message-ID: <20090910120442.GE32585@intevation.de> * Geoff Galitz [10. Sep 2009]: > While I like the names, I'd like to recommend at this point that anything > with a "d" on the end not require the "-D" option to go into daemon mode. A > trailing "d" is a defacto standard that specifies an application will > automatically daemonize itself. I agree. In fact, this is the way openvasmd (openvas-manager) already behaves; it backgrounds by default and requires a -f (--foreground) to stay in the foreground. IMHO, that is the way it should work in openvasd as well. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090910/6d0a67e8/attachment.pgp From Jan-Oliver.Wagner at greenbone.net Thu Sep 10 22:51:01 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Thu, 10 Sep 2009 22:51:01 +0200 Subject: [Openvas-devel] Add Web-Cient to OpenVAS Subversion repository? Message-ID: <200909102251.01306.Jan-Oliver.Wagner@greenbone.net> Hello OpenVAS Developers, Greenbone (http://www.greenbone.net) developed a web client based on openvas-manager and its protocol "OMP". It is callled "Greenbone Security Assistant", or short "GSA". In line with the customer-oriented philosophy of Greenbone, the license is GNU GPLv2+. The implementation language is C. Does anyone have concerns regarding to add a module "gsa" to the OpenVAS Subversion repository and distribute this WebClient via the OpenVAS platform? All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Fri Sep 11 09:35:50 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 11 Sep 2009 09:35:50 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <200909091127.44455.felix.wolfsteller@intevation.de> References: <20090909090639.4A4D3DEFD8@mail.ukfsn.org> <200909091127.44455.felix.wolfsteller@intevation.de> Message-ID: <200909110935.50568.Jan-Oliver.Wagner@greenbone.net> On Wednesday 09 September 2009 11:27:44 Felix Wolfsteller wrote: > On Wednesday 09 September 2009 11:06:42 Matthew Mundell wrote: > > I think OpenVAS-Client should be brought in line with the daemon names > > I definately agree with that. The mixed case "OpenVAS-Client" is some weird > name for an executable. > > Which might bring up another 3.0 "feature" that also would clean up code in > client a little bit: > - separate executables for the "batch mode" (non-graphical) and the gtk > client (i think that is a nice "junior job" btw). agreed. This was a permanent source of confusion in the past. Still, I have to move my minds a bit more about the client name scheme ... Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Fri Sep 11 09:36:31 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 11 Sep 2009 09:36:31 +0200 Subject: [Openvas-devel] =?utf-8?q?Preparing_OpenVAS_3=2E0=3A_features_and?= =?utf-8?q?=09timeline?= In-Reply-To: <20090910120442.GE32585@intevation.de> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <247B05C8918D410BB117570726FEB266@geoffPC> <20090910120442.GE32585@intevation.de> Message-ID: <200909110936.31444.Jan-Oliver.Wagner@greenbone.net> On Thursday 10 September 2009 14:04:42 Michael Wiegand wrote: > * Geoff Galitz [10. Sep 2009]: > > While I like the names, I'd like to recommend at this point that anything > > with a "d" on the end not require the "-D" option to go into daemon mode. A > > trailing "d" is a defacto standard that specifies an application will > > automatically daemonize itself. > > I agree. In fact, this is the way openvasmd (openvas-manager) already > behaves; it backgrounds by default and requires a -f (--foreground) to > stay in the foreground. IMHO, that is the way it should work in openvasd > as well. I fully subscribe to this. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From roman at netangels.ru Sat Sep 12 16:36:01 2009 From: roman at netangels.ru (Roman Imankulov) Date: Sat, 12 Sep 2009 20:36:01 +0600 Subject: [Openvas-devel] openvas-server 2.0.3 doesn't ever try to authenticate user with peer certificate? Message-ID: <20090912203601.3cadae3c@romik.planet-a.ru> Hi, As I can suppose, current openvas-server implementaion has broken certificate-based authentication (I've tried with version 2.0.3 it seems that svn trunk has the same behaviour). I suggest than openvas-server have to perform these steps while authenticate remote peer with the certificate: 0. Allow GNU TLS library to perform the check of the peer certificate correctness. 1. Get the certificate distinguished name (DN) with help of GNU TLS library 2. Check out the contents of the file /var/lib/openvas/users/$username/auth/dname and compare the DN value obtained from the peer certificate with the one stored in the file. 3. If these two values are matched, assume that user with $username is sucessfully authenticated But unfortunately I see that the variable x509_dname in the `server_thread` function once initialized with the empty string never ever tries to update its value. However the `check_user` function performs authentication based on the contents of the x509_dname variable. I've made a quick and dirty patch which fix this behaviour (in attachment) and it seems that this one works as expected for me. I want to note however that this patch provides no error handling and I'm not sure that this code works as expected in all cases. -- Roman Imankulov roman at netangels.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: dn_auth.diff Type: text/x-patch Size: 1353 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090912/2c9479cc/dn_auth.bin From michael.wiegand at intevation.de Mon Sep 14 09:23:20 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 14 Sep 2009 09:23:20 +0200 Subject: [Openvas-devel] openvas-server 2.0.3 doesn't ever try to authenticate user with peer certificate? In-Reply-To: <20090912203601.3cadae3c@romik.planet-a.ru> References: <20090912203601.3cadae3c@romik.planet-a.ru> Message-ID: <20090914072320.GE28881@intevation.de> * Roman Imankulov [12. Sep 2009]: > Hi, > > As I can suppose, current openvas-server implementaion has broken > certificate-based authentication (I've tried with version 2.0.3 it > seems that svn trunk has the same behaviour). This is indeed true. I just noticed this the other day while trying out the certificate-based authentication. Apparently, this feature was unintentionally broken during the switch from OpenSSL to GnuTLS in openvas-server. > I've made a quick and dirty patch which fix this behaviour (in > attachment) and it seems that this one works as expected for me. I want > to note however that this patch provides no error handling and I'm not > sure that this code works as expected in all cases. Thank you very very much! I have tested you patch and it indeed re-enables certificate-based authentication. We will do further tests and add error handling and will likely commit your patch to the SVN trunk in the next few days. Out of curiosity, what did you use to create the auth/dname files in the user directories of openvas-server? The old scripts from Nessus/OpenSSL times seem to write the dname in a different format than what is returned by GnuTLS. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090914/8066b67a/attachment.pgp From felix.wolfsteller at intevation.de Mon Sep 14 09:39:46 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 14 Sep 2009 09:39:46 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> Message-ID: <200909140939.46216.felix.wolfsteller@intevation.de> On Wednesday 09 September 2009 10:26:26 Jan-Oliver Wagner wrote: > I'd like to stress that the renaming should really be done > for the sake of consistent and easy to understand wording. > > On Thursday 03 September 2009 15:24:27 Jan-Oliver Wagner wrote: > > What I like to change for 3.0 also: > > > > * rename openvasd to openvassd for scan daemon. > > ? This would be in line with openvasmd (manager daemon) > > ? and openvascd (configuration daemon) > > > > * In fact, rename "openvas-server" to "openvas-scanner" > > ? ?because "server" is a bit too generic. tbh, openvas-scanner is a bit too specific, as currently openvasd does not only do the scanning. I agree in that the 'scanner' part should be stripped down to do just that (and i guess the pentesters will be quite happy about that). This also touches the consistency issue: Where there is a 'xyz-client' I expect to find either a 'xyz' or an 'xyz-server'. To me, openvas-scanner is a 4.0 thing where the client (to be understood as "user interface") does not talk directly to openvas-server anymore. --felix -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Mon Sep 14 09:50:14 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 14 Sep 2009 09:50:14 +0200 Subject: [Openvas-devel] =?utf-8?q?Preparing_OpenVAS_3=2E0=3A_features_and?= =?utf-8?q?=09timeline?= In-Reply-To: <200909110936.31444.Jan-Oliver.Wagner@greenbone.net> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <20090910120442.GE32585@intevation.de> <200909110936.31444.Jan-Oliver.Wagner@greenbone.net> Message-ID: <200909140950.14218.felix.wolfsteller@intevation.de> On Friday 11 September 2009 09:36:31 Jan-Oliver Wagner wrote: > On Thursday 10 September 2009 14:04:42 Michael Wiegand wrote: > > * Geoff Galitz [10. Sep 2009]: > > > While I like the names, I'd like to recommend at this point that > > > anything with a "d" on the end not require the "-D" option to go into > > > daemon mode. A trailing "d" is a defacto standard that specifies an > > > application will automatically daemonize itself. > > > > I agree. In fact, this is the way openvasmd (openvas-manager) already > > behaves; it backgrounds by default and requires a -f (--foreground) to > > stay in the foreground. IMHO, that is the way it should work in openvasd > > as well. Done in revision 4925. -- Felix Wolfsteller | ++49 541 335083-783 | 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 greenbone.net Mon Sep 14 10:24:07 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 14 Sep 2009 10:24:07 +0200 Subject: [Openvas-devel] Preparing OpenVAS 3.0: features and timeline In-Reply-To: <200909140939.46216.felix.wolfsteller@intevation.de> References: <200909031524.27863.Jan-Oliver.Wagner@greenbone.net> <200909091026.26748.Jan-Oliver.Wagner@greenbone.net> <200909140939.46216.felix.wolfsteller@intevation.de> Message-ID: <200909141024.07906.Jan-Oliver.Wagner@greenbone.net> On Monday 14 September 2009 09:39:46 Felix Wolfsteller wrote: > On Wednesday 09 September 2009 10:26:26 Jan-Oliver Wagner wrote: > > I'd like to stress that the renaming should really be done > > for the sake of consistent and easy to understand wording. > > > > On Thursday 03 September 2009 15:24:27 Jan-Oliver Wagner wrote: > > > What I like to change for 3.0 also: > > > > > > * rename openvasd to openvassd for scan daemon. > > > This would be in line with openvasmd (manager daemon) > > > and openvascd (configuration daemon) > > > > > > * In fact, rename "openvas-server" to "openvas-scanner" > > > because "server" is a bit too generic. > > tbh, openvas-scanner is a bit too specific, as currently openvasd does not > only do the scanning. > I agree in that the 'scanner' part should be stripped down to do just that > (and i guess the pentesters will be quite happy about that). yes, it must be stripped down to the core task of scanning. We agreed on this during the last OpenVAS DevCon. The earlier the name change and API alternative (OMP), the better. > This also touches the consistency issue: Where there is a 'xyz-client' I > expect to find either a 'xyz' or an 'xyz-server'. hm, well. The current name scheme caused a lot of misunderstanding as well. I don't have a final opinion about the naming scheme on the client side. > To me, openvas-scanner is a 4.0 thing where the client (to be understood > as "user interface") does not talk directly to openvas-server anymore. Already with 2.0, at you option, OpenVAS-Client is able to talk to the manager with OTP. In 3.0 in can talk to manager with OTP and OMP. So, we offer our users a nice transition phase. But the renaming should be done as early as possible to clarify the way to go. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From roman at netangels.ru Tue Sep 15 04:55:15 2009 From: roman at netangels.ru (Roman Imankulov) Date: Tue, 15 Sep 2009 08:55:15 +0600 Subject: [Openvas-devel] openvas-server 2.0.3 doesn't ever try to authenticate user with peer certificate? In-Reply-To: <20090914072320.GE28881@intevation.de> References: <20090912203601.3cadae3c@romik.planet-a.ru> <20090914072320.GE28881@intevation.de> Message-ID: <20090915085515.06770284@roman> Hi, Michael Wiegand wrote: > Thank you very very much! I have tested you patch and it indeed > re-enables certificate-based authentication. We will do further tests > and add error handling and will likely commit your patch to the SVN > trunk in the next few days. Glad to be a helpful. > Out of curiosity, what did you use to create the auth/dname files in > the user directories of openvas-server? The old scripts from > Nessus/OpenSSL times seem to write the dname in a different format > than what is returned by GnuTLS. It's true, the format was wrong, so I filled up this file manually. But it's pretty easy to obtain the value in scripts when "gnutls-bin" package is installed. I find out that actions as below can be useful: certtool --certificate-info < path/to/cert.pem or, directly in script something like this: certtool --certificate-info < path/to/cert.pem | sed -n '/^\tSubject:/s/.*: *\(.*\)/\1/p' -- Roman Imankulov roman at netangels.ru From Jan-Oliver.Wagner at greenbone.net Wed Sep 16 07:59:53 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 16 Sep 2009 07:59:53 +0200 Subject: [Openvas-devel] Planning openvas-libraries 3.0.0-beta1 Message-ID: <200909160759.53847.Jan-Oliver.Wagner@greenbone.net> Hi, it is now time that we can/should start the first beta release of the upcoming 3.0 series :-) It is important that we get out all the new features to a broader tester community that only will use tarballs or packages. First module is openvas-libraries, naturally. What I see as important TODOs for beta1: * finalize the renaming nessus->openvas * move some modules from openvas-client to -libraries * remove any of the OpenSSL license exception statements * Finalize the IPv6 feature My hope is that we get beta1 out in next week, but at least this month. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From lists at securityspace.com Thu Sep 17 15:31:50 2009 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 17 Sep 2009 09:31:50 -0400 Subject: [Openvas-devel] Multiple? issues in secpod_oxid_eshop_priv_escalation_vuln.nasl Message-ID: <4AB23A46.5050308@securityspace.com> Hi, This test is tripping false on every system we run it against that has a web server, presumably because of the security_note that displays the version without checking if eship was installed. Also, I'm not sure if the line if(eshopVer[1] = "^4\.") is doing what was intended. Thomas From mime at gmx.de Thu Sep 17 16:34:09 2009 From: mime at gmx.de (Michael Meyer) Date: Thu, 17 Sep 2009 16:34:09 +0200 Subject: [Openvas-devel] Multiple? issues in secpod_oxid_eshop_priv_escalation_vuln.nasl In-Reply-To: <4AB23A46.5050308@securityspace.com> References: <4AB23A46.5050308@securityspace.com> Message-ID: <20090917143409.GA11607@komma-nix.de> Hi Thomas, *** Thomas Reinke wrote: > This test is tripping false on every system we run it against that > has a web server, presumably because of the security_note that > displays the version without checking if eship was installed. I have fixed that yesterday by removing "security_note(data:"VERSION:"+eshopVer);". Fixed version is available via openvas-nvt-sync. > Also, I'm not sure if the line > > if(eshopVer[1] = "^4\.") > > is doing what was intended. No. ;) I have overlooked this yesterday. IMO this should be "if(eshopVer[1] =~ "^4\.")". I have fixed that and the fixed version is now available via svn. Micha From bchandra at secpod.com Fri Sep 18 06:44:26 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 18 Sep 2009 10:14:26 +0530 Subject: [Openvas-devel] Multiple? issuesin secpod_oxid_eshop_priv_escalation_vuln.nasl In-Reply-To: <20090917143409.GA11607@komma-nix.de> References: <4AB23A46.5050308@securityspace.com> <20090917143409.GA11607@komma-nix.de> Message-ID: Thanks Micha! Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Michael Meyer Sent: Thursday, September 17, 2009 8:04 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] Multiple? issuesin secpod_oxid_eshop_priv_escalation_vuln.nasl Hi Thomas, *** Thomas Reinke wrote: > This test is tripping false on every system we run it against that > has a web server, presumably because of the security_note that > displays the version without checking if eship was installed. I have fixed that yesterday by removing "security_note(data:"VERSION:"+eshopVer);". Fixed version is available via openvas-nvt-sync. > Also, I'm not sure if the line > > if(eshopVer[1] = "^4\.") > > is doing what was intended. No. ;) I have overlooked this yesterday. IMO this should be "if(eshopVer[1] =~ "^4\.")". I have fixed that and the fixed version is now available via svn. Micha _______________________________________________ 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 Fri Sep 18 09:16:54 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 18 Sep 2009 09:16:54 +0200 Subject: [Openvas-devel] Renaming openvas-server to openvas-scanner Message-ID: <200909180916.54886.felix.wolfsteller@intevation.de> Following the discussions at openvas-devel (http://lists.wald.intevation.org/pipermail/openvas-devel/2009-September/001775.html) I would like to take action soon. Therefore, * openvas-server will be moved to openvas-scanner, * openvasd will be renamed to openvassd, * ~All occurences of 'server' will be replaced by 'scanner'. I will start to do so next week, if nobody objects. Especially if you have some patches to commit please respond, so that we can coordinate. Enjoy, -- Felix -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Fri Sep 18 09:52:35 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 18 Sep 2009 09:52:35 +0200 Subject: [Openvas-devel] (Better) Naming Conventions for libraries and includes Message-ID: <200909180952.35867.felix.wolfsteller@intevation.de> We need some conventions for our libraries and includes. libs ---- In current trunk, openvas-libraries builds a couple of libraries (e.g. libopenvasmisc, libopenvashg, libopenvas_base and libopenvas_nasl). Should(nt) we consistently use underscores to separate the "sub" libraries? includes -------- We are also somewhat messy regarding the includes of files from outside the module, like #include "whatever.h" #include #include . Currently all headers are installed to (include/)openvas, but it makes sense to make clear to which module the files belong and to avoid clashes (e.g. omp.h for the OpenVAS Manager Protocol and not OpenMP). So we could install the headers from openvas-libraries/base to (include/)openvas/base and include e.g. via #include . Objections/ideas/alternatives/oppinions/support? -- felix -- Felix Wolfsteller | ++49 541 335083-783 | 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 matthew.mundell at intevation.de Fri Sep 18 10:53:56 2009 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 18 Sep 2009 08:52:56 -0001 Subject: [Openvas-devel] (Better) Naming Conventions for libraries and includes In-Reply-To: Message of Fri, 18 Sep 2009 09:52:35 +0200. <200909180952.35867.felix.wolfsteller@intevation.de> Message-ID: <20090918085345.7B512DEB8E@mail.ukfsn.org> > We need some conventions for our libraries and includes. > > libs > ---- > In current trunk, openvas-libraries builds a couple of libraries (e.g. > libopenvasmisc, libopenvashg, libopenvas_base and libopenvas_nasl). > Should(nt) we consistently use underscores to separate the "sub" libraries? libopenvasmisc and libopenvashg will go away eventually, so I think this is OK, as long as all new libraries have underscores. > includes > -------- > We are also somewhat messy regarding the includes of files from outside the > module, like > #include "whatever.h" > #include > #include . > Currently all headers are installed to (include/)openvas, but it makes sense > to make clear to which module the files belong and to avoid clashes (e.g. > omp.h for the OpenVAS Manager Protocol and not OpenMP). > > So we could install the headers from openvas-libraries/base to > (include/)openvas/base > and include e.g. via > #include > . Yeah, I think this is a good idea. Alternatives would be #include or #include . Some of the library header names are currently preceded with openvas_, like openvas_auth.h. A related issue is the naming of the symbols in the libraries. Perhaps we could agree on a prefix for all library symbols? Maybe openvas_, ov_, openvas_module_ or ov_module, as in openvas_nvti_new ov_nvti_new openvas_base_nvti_new ov_base_nvti_new Including the module name might result in some very long names, though. From Jan-Oliver.Wagner at greenbone.net Fri Sep 18 16:43:55 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Fri, 18 Sep 2009 16:43:55 +0200 Subject: [Openvas-devel] =?iso-8859-1?q?=28Better=29_Naming_Conventions_fo?= =?iso-8859-1?q?r_libraries_and=09=09=09=09=09=09=09=09=09includes?= In-Reply-To: <20090918085345.7B512DEB8E@mail.ukfsn.org> References: <20090918085345.7B512DEB8E@mail.ukfsn.org> Message-ID: <200909181643.56787.Jan-Oliver.Wagner@greenbone.net> On Freitag, 18. September 2009, Matthew Mundell wrote: > > In current trunk, openvas-libraries builds a couple of libraries (e.g. > > libopenvasmisc, libopenvashg, libopenvas_base and libopenvas_nasl). > > Should(nt) we consistently use underscores to separate the "sub" libraries? > > libopenvasmisc and libopenvashg will go away eventually, so I think this is > OK, as long as all new libraries have underscores. it still could be a long time until then. I favour very much consistency. Also, underscoring would clearly mark the big library change from 2.0 to 3.0 and avoid any confusion beyond so version. > > We are also somewhat messy regarding the includes of files from outside the > > module, like > > #include "whatever.h" > > #include > > #include . > > Currently all headers are installed to (include/)openvas, but it makes sense > > to make clear to which module the files belong and to avoid clashes (e.g. > > omp.h for the OpenVAS Manager Protocol and not OpenMP). > > > > So we could install the headers from openvas-libraries/base to > > (include/)openvas/base > > and include e.g. via > > #include this would be cleanest of all approaches. Moving a header from one lib to another would require to adjust in all files including it. But this should not happen anyway for stable versions. > Yeah, I think this is a good idea. Alternatives would be > > #include that would be my minimum requirement but my real preference is the one above. > or > > #include . I don't like this! > Some of the library header names are currently preceded with openvas_, like > openvas_auth.h. In fact, with the consisten openvas/... approach we would not need such prefixes anymore. > A related issue is the naming of the symbols in the libraries. Perhaps we > could agree on a prefix for all library symbols? Maybe openvas_, ov_, > openvas_module_ or ov_module, as in > > openvas_nvti_new > ov_nvti_new > openvas_base_nvti_new > ov_base_nvti_new > > Including the module name might result in some very long names, though. Is it really a good idea to prefix any of our library functions? However, indeed currently, different names schemes are used and that isn't really consistent either. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From kost at linux.hr Mon Sep 21 09:40:40 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Mon, 21 Sep 2009 09:40:40 +0200 Subject: [Openvas-devel] openvas-libraries and libopenvas-config Message-ID: <4AB72DF8.6040105@linux.hr> Hello! Is there any special reason why openvas-libraries have libopenvas-config and not doing it through standard pkg-config? Kost From Jan-Oliver.Wagner at greenbone.net Mon Sep 21 10:14:33 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 21 Sep 2009 10:14:33 +0200 Subject: [Openvas-devel] openvas-libraries and libopenvas-config In-Reply-To: <4AB72DF8.6040105@linux.hr> References: <4AB72DF8.6040105@linux.hr> Message-ID: <200909211014.35087.Jan-Oliver.Wagner@greenbone.net> On Montag, 21. September 2009, Vlatko Kosturjak wrote: > Is there any special reason why openvas-libraries have > libopenvas-config and not doing it through standard pkg-config? the only reason I can think of: noone did take care of it yet ;-) pkg-conf should be available for most platforms, I assume. Anyone likes to take care for this today? (else 3.0.0-beta1 will be released with the current style) Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Mon Sep 21 10:17:33 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 21 Sep 2009 10:17:33 +0200 Subject: [Openvas-devel] Getting rid of openvasclient-mkrand Message-ID: <200909211017.34615.Jan-Oliver.Wagner@greenbone.net> Hi, in directory openvas-client/ssl there is still the C program for gathering some sort of entropy in absence of /dev/urandom. I neither think this tool is needed today anymore nor do I think it is the task of OpenVAS to care about entropy. Other tools should be employed for this. GNUTLS/libgcrypt tries its best already and they surely to better than we do. So, I think we can remove openvasclient-mkrand entirely. Opinions? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From christian.edjenguele at owasp.org Mon Sep 21 10:20:46 2009 From: christian.edjenguele at owasp.org (Christian Eric Edjenguele) Date: Mon, 21 Sep 2009 10:20:46 +0200 Subject: [Openvas-devel] Getting rid of openvasclient-mkrand In-Reply-To: <200909211017.34615.Jan-Oliver.Wagner@greenbone.net> References: <200909211017.34615.Jan-Oliver.Wagner@greenbone.net> Message-ID: <4AB7375E.1010901@owasp.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan-Oliver Wagner wrote: > Hi, > > in directory openvas-client/ssl there is still the C program > for gathering some sort of entropy in absence of /dev/urandom. > > I neither think this tool is needed today anymore nor do I think > it is the task of OpenVAS to care about entropy. Other tools > should be employed for this. GNUTLS/libgcrypt tries its best already and > they surely to better than we do. I agree with this. > So, I think we can remove openvasclient-mkrand entirely. > Opinions? > > Best > > Jan > - -- Christian Eric Edjenguele IT Security Engineer PGP KeyID: 0xB1654498 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJKtzdYAAoJENETScWxZUSYT7MH/Rw9pHYOX07VtyaFQcYs1Sxc 8OjiCNxtfEK5YOTqaQ0iGPUmJis7qs8UMXRcMGvCOZ7dNAagtdPZloF/0M2LHFv4 rdCe5nKwnwgrEzFglPtSt2j9bPF2t0URjZirYp9q1UZwf9fxZZ1Yr5ZMvqa3oRKd knqHVTCQf6wGRpPtEtrSqibCwfzldfys/6nNbnTQyZ0xHeRy9yMlvhrDPTz+nP3D jZQA5dj/nhQVpySIgwCcDTA7S45CndHi8crvhx+6NyEbS4OXMk23ZCtsiRBM22af Ek2IktAlsoWKrbTjEC4t3+KaZlPDxZ5p3KOFJOBW3gXw2cbKMX4bcWJ5tCQVBfM= =BL9l -----END PGP SIGNATURE----- From kost at linux.hr Mon Sep 21 10:31:21 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Mon, 21 Sep 2009 10:31:21 +0200 Subject: [Openvas-devel] openvas-libraries and libopenvas-config In-Reply-To: <200909211014.35087.Jan-Oliver.Wagner@greenbone.net> References: <4AB72DF8.6040105@linux.hr> <200909211014.35087.Jan-Oliver.Wagner@greenbone.net> Message-ID: <4AB739D9.4040201@linux.hr> Jan-Oliver Wagner wrote: > On Montag, 21. September 2009, Vlatko Kosturjak wrote: >> Is there any special reason why openvas-libraries have >> libopenvas-config and not doing it through standard pkg-config? > the only reason I can think of: noone did take care of it yet ;-) > pkg-conf should be available for most platforms, I assume. Yes, it is a standard way to do it. > Anyone likes to take care for this today? > (else 3.0.0-beta1 will be released with the current style) I can help, but would need to work with someone who implemented libopenvas-config. But, I guess we're too late if 3.0.0-beta1 will be today... I'm sending pkg-config of openvas-libraries.pc as sample I've made. configure should read open-libraries.pc.in and produce open-libraries.pc with right $prefix and $version... I'll be on IRC for details... Kost -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openvas-libraries.pc Url: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090921/f7a3783a/openvas-libraries.asc From kost at linux.hr Mon Sep 21 15:09:19 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Mon, 21 Sep 2009 15:09:19 +0200 Subject: [Openvas-devel] [Fwd: [Openvas-commits] r5095 - trunk/openvas-libraries] Message-ID: <4AB77AFF.3040501@linux.hr> I'm including this on -devel and -distro mailing list as it is concerning package maintainers as well. It is regarding pkg-config implementation for new openvas-libraries in 3.x. openvas-libraries ship with libnasl and openvas-lib now. As client doesn't need libnasl, should: [1] we have more pkg-configs files for each configuration - e.g. libopenvas-nasl for linking server type versions libopenvas-client for linking client type versions (or any other naming convention) [2] ..or we should have single pkg-config which will link all libraries and that's it? Also, would be correct to have version in libopenvas like glib have i.e. libglib-2.0, or we should have single (libopenvas) and package mainteners would do it differently if they feel it for each distro? Let me know, so we can proceed further with pkg-config support implementation. -------- Original Message -------- Subject: [Openvas-commits] r5095 - trunk/openvas-libraries Date: Mon, 21 Sep 2009 14:52:40 +0200 (CEST) From: scm-commit at wald.intevation.org Reply-To: openvas-devel at wald.intevation.org To: openvas-commits at wald.intevation.org Author: kost Date: 2009-09-21 14:52:40 +0200 (Mon, 21 Sep 2009) New Revision: 5095 Added: trunk/openvas-libraries/libopenvas.pc.in Modified: trunk/openvas-libraries/ChangeLog Log: Initial support for pkg-config Modified: trunk/openvas-libraries/ChangeLog =================================================================== --- trunk/openvas-libraries/ChangeLog 2009-09-21 12:35:03 UTC (rev 5094) +++ trunk/openvas-libraries/ChangeLog 2009-09-21 12:52:40 UTC (rev 5095) @@ -1,3 +1,7 @@ +2009-09-21 Vlatko Kosturjak + + * libopenvas.pc.in: new file, support for pkg-config + 2009-09-21 Felix Wolfsteller * base/openvas_certificate_file.c: Commented another show_error, Added: trunk/openvas-libraries/libopenvas.pc.in =================================================================== --- trunk/openvas-libraries/libopenvas.pc.in 2009-09-21 12:35:03 UTC (rev 5094) +++ trunk/openvas-libraries/libopenvas.pc.in 2009-09-21 12:52:40 UTC (rev 5095) @@ -0,0 +1,11 @@ +prefix=@prefix@ +exec_prefix=@exec_prefix@ +libdir=@libdir@ +includedir=@includedir@ + +Name: openvas-libraries +Description: OpenVAS libraries +Version: @version@ +Requires: glib-2.0 = 2.8.0 +Cflags: -I${includedir} +Libs: -L${libdir} -lglib _______________________________________________ Openvas-commits mailing list Openvas-commits at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-commits From matthew.mundell at intevation.de Mon Sep 21 15:31:25 2009 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 21 Sep 2009 13:30:25 -0001 Subject: [Openvas-devel] [Openvas-distro] [Fwd: [Openvas-commits] r5095 - trunk/openvas-libraries] In-Reply-To: Message of Mon, 21 Sep 2009 15:09:19 +0200. <4AB77AFF.3040501@linux.hr> Message-ID: <20090921133112.5EB4EDF7BC@mail.ukfsn.org> > openvas-libraries ship with libnasl and openvas-lib now. As client > doesn't need libnasl, should: There is also the OMP library to consider. Soon there'll be libopenvas_net too. OMP clients could require only libopenvas_omp, so if we're choosing [1], it should be possible to choose only that library. > [1] we have more pkg-configs files for each configuration - e.g. > libopenvas-nasl for linking server type versions > libopenvas-client for linking client type versions > (or any other naming convention) Probably something like libopenvas-base, libopenvas-net, libopenvas-nasl and libopenvas-omp. libopenvas_misc could be provided by libopenvas_base, I think. > [2] ..or we should have single pkg-config which will link all libraries > and that's it? This is a much simpler immediate solution. It's what libopenvas-config is doing now. From Jan-Oliver.Wagner at greenbone.net Tue Sep 22 00:58:22 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Tue, 22 Sep 2009 00:58:22 +0200 Subject: [Openvas-devel] Getting rid of openvasclient-mkrand In-Reply-To: <200909211017.34615.Jan-Oliver.Wagner@greenbone.net> References: <200909211017.34615.Jan-Oliver.Wagner@greenbone.net> Message-ID: <200909220058.22613.Jan-Oliver.Wagner@greenbone.net> On Monday 21 September 2009 10:17:33 Jan-Oliver Wagner wrote: > in directory openvas-client/ssl there is still the C program > for gathering some sort of entropy in absence of /dev/urandom. > > I neither think this tool is needed today anymore nor do I think > it is the task of OpenVAS to care about entropy. Other tools > should be employed for this. GNUTLS/libgcrypt tries its best already and > they surely to better than we do. > > So, I think we can remove openvasclient-mkrand entirely. I removed it now. It was not even installed for a long long time and no one missed it. This also means that openvasclient-mkcert is pretty useless. The scanner package has a similar routine in case you need it at all. -mkcert will now fail in cases where no good enough entropy source is found because it would try then openvasclient-mkrand. Does anyone have a good reason at hand why to keep openvasclient-mkcert in the package? All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Wed Sep 16 23:32:35 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Wed, 16 Sep 2009 23:32:35 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1120=5D_Vague/Conf?= =?utf-8?q?using_script=5Fname_and_script=5Fsummary_in_systems_gene?= =?utf-8?q?rated_checks_for_Solaris?= Message-ID: <20090916213235.4908885D9F48@pyrosoma.intevation.org> Bugs item #1120, was opened at 2009-09-16 23:32 Status: Open Priority: 3 Submitted By: Geoff Galitz (geoff) Assigned to: Nobody (None) Summary: Vague/Confusing script_name and script_summary in systems generated checks for Solaris Architecture: None Resolution: None Severity: minor Version: None Component: openvas-plugins Operating System: None Product: OpenVAS Hardware: None URL: Initial Comment: Some of the local Solaris checks which look for obsoleted patches lack the word "patch" and are vague in the script_name and script_summary. It is a minor issue, but it is confusing when you are unfamiliar with Solaris. For example, gb_solaris_141014_01.nasl: script_name( "Solaris Update for Obsoleted by 141014-01"); script_summary("Check for the Version of Obsoleted by"); Instead they should read: script_name( "Solaris update for obsolete patch 141014-01"); script_summary("Check for the version of obsolete patch"); ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1120&group_id=29 From Jan-Oliver.Wagner at greenbone.net Tue Sep 22 12:45:43 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Tue, 22 Sep 2009 12:45:43 +0200 Subject: [Openvas-devel] openvas-libraries 3.0.0-beta1 Message-ID: <200909221245.44935.Jan-Oliver.Wagner@greenbone.net> Hello OpenVAS developers, I finally released the very first 3.0.0 beta of openvas-libraries: http://wald.intevation.org/frs/?group_id=29&release_id=284 It is of not of too much use as long as the other modules are not released and therefore I did not make a broader announcement of it. However, this release is good for testing in general and testing trying to package it. Have fun Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Tue Sep 22 12:50:31 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Tue, 22 Sep 2009 12:50:31 +0200 Subject: [Openvas-devel] Planning openvas-scanner 3.0.0-beta1 Message-ID: <200909221250.36006.Jan-Oliver.Wagner@greenbone.net> Hi, next module for the first beta series of 3.0 is openvas-scanner. I hope to get it out end this week or early next week at the very latest. What is missing are some IPv6 patches AFAIKT. Lots of cleanups are possible but should not prevent the beta. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From matthew.mundell at intevation.de Tue Sep 22 21:24:16 2009 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 22 Sep 2009 19:23:16 -0001 Subject: [Openvas-devel] [Openvas-commits] r5147 - in trunk/openvas-scanner: . openvasd In-Reply-To: Message of Tue, 22 Sep 2009 21:09:34 +0200 (CEST). <20090922190934.CC26F865F49C@pyrosoma.intevation.org> Message-ID: <20090922192401.E5D65DF276@mail.ukfsn.org> > Modified: trunk/openvas-scanner/openvasd/otp_1_0.c > =================================================================== > --- trunk/openvas-scanner/openvasd/otp_1_0.c 2009-09-22 15:27:12 UTC (rev 5146) > +++ trunk/openvas-scanner/openvasd/otp_1_0.c 2009-09-22 19:09:33 UTC (rev 5147) > @@ -6,7 +6,7 @@ > * Jan-Oliver Wagner > * > * Copyright: > -* Copyright (C) 2008 Intevation GmbH > +* Copyright (C) 2009 Greenbone Networks GmbH Jan, are you doing the right thing with the dates when transfering copyright? I think the year must always stay the same for a particular version, because eventually the copyright runs out. If new additions are made then new years are added. From Jan-Oliver.Wagner at greenbone.net Tue Sep 22 22:18:01 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Tue, 22 Sep 2009 22:18:01 +0200 Subject: [Openvas-devel] [Openvas-commits] r5147 - in trunk/openvas-scanner: . openvasd In-Reply-To: <20090922192401.E5D65DF276@mail.ukfsn.org> References: <20090922192401.E5D65DF276@mail.ukfsn.org> Message-ID: <200909222218.02695.Jan-Oliver.Wagner@greenbone.net> On Dienstag, 22. September 2009, Matthew Mundell wrote: > > Modified: trunk/openvas-scanner/openvasd/otp_1_0.c > > =================================================================== > > --- trunk/openvas-scanner/openvasd/otp_1_0.c 2009-09-22 15:27:12 UTC (rev 5146) > > +++ trunk/openvas-scanner/openvasd/otp_1_0.c 2009-09-22 19:09:33 UTC (rev 5147) > > @@ -6,7 +6,7 @@ > > * Jan-Oliver Wagner > > * > > * Copyright: > > -* Copyright (C) 2008 Intevation GmbH > > +* Copyright (C) 2009 Greenbone Networks GmbH > > Jan, are you doing the right thing with the dates when transfering > copyright? I think the year must always stay the same for a particular > version, because eventually the copyright runs out. If new additions are > made then new years are added. not sure whether it is correct to have a year prior to existance of legal entity holding the copyright. Thats why I changed all to 2009. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From matthew.mundell at intevation.de Wed Sep 23 18:50:51 2009 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 23 Sep 2009 16:49:51 -0001 Subject: [Openvas-devel] [Openvas-commits] r5147 - in trunk/openvas-scanner: . openvasd In-Reply-To: Message of Tue, 22 Sep 2009 22:18:01 +0200. <200909222218.02695.Jan-Oliver.Wagner@greenbone.net> Message-ID: <20090923165034.B020CDEBD8@mail.ukfsn.org> > On Dienstag, 22. September 2009, Matthew Mundell wrote: > > > Modified: trunk/openvas-scanner/openvasd/otp_1_0.c > > > =================================================================== > > > --- trunk/openvas-scanner/openvasd/otp_1_0.c 2009-09-22 15:27:12 UTC (rev 5146) > > > +++ trunk/openvas-scanner/openvasd/otp_1_0.c 2009-09-22 19:09:33 UTC (rev 5147) > > > @@ -6,7 +6,7 @@ > > > * Jan-Oliver Wagner > > > * > > > * Copyright: > > > -* Copyright (C) 2008 Intevation GmbH > > > +* Copyright (C) 2009 Greenbone Networks GmbH > > > > Jan, are you doing the right thing with the dates when transfering > > copyright? I think the year must always stay the same for a particular > > version, because eventually the copyright runs out. If new additions are > > made then new years are added. > > not sure whether it is correct to have a year prior to existance > of legal entity holding the copyright. Thats why I changed all to 2009. http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices Don't delete old year numbers, though; they are significant since they indicate when older versions might theoretically go into the public domain, if the movie companies don't continue buying laws to further extend copyright. If you copy a file into the package from some other program, keep the copyright years that come with the file. I wonder what their rule is when transfering copyright older than the legal entity. From lists at securityspace.com Wed Sep 23 20:11:03 2009 From: lists at securityspace.com (Thomas Reinke) Date: Wed, 23 Sep 2009 14:11:03 -0400 Subject: [Openvas-devel] [Openvas-commits] r5147 - in trunk/openvas-scanner: . openvasd In-Reply-To: <20090923165034.B020CDEBD8@mail.ukfsn.org> References: <20090923165034.B020CDEBD8@mail.ukfsn.org> Message-ID: <4ABA64B7.5080101@securityspace.com> I strongly suspect that the original copyright date holds. While IANAL, it makes sense that way, given that one can certainly transfer IP. The form of the IP being transferred doesn't change (e.g. the content, the creation, or the date created) just because the legal entity receiving the IP is younger than the asset being transferred. It also makes sense from another point of view - if one were allowed to update the copyright date without any change to what was copyrighted, it would make a nice end run-around on the copyright duration. Thomas Matthew Mundell wrote: >> On Dienstag, 22. September 2009, Matthew Mundell wrote: >>>> Modified: trunk/openvas-scanner/openvasd/otp_1_0.c >>>> =================================================================== >>>> --- trunk/openvas-scanner/openvasd/otp_1_0.c 2009-09-22 15:27:12 UTC (rev 5146) >>>> +++ trunk/openvas-scanner/openvasd/otp_1_0.c 2009-09-22 19:09:33 UTC (rev 5147) >>>> @@ -6,7 +6,7 @@ >>>> * Jan-Oliver Wagner >>>> * >>>> * Copyright: >>>> -* Copyright (C) 2008 Intevation GmbH >>>> +* Copyright (C) 2009 Greenbone Networks GmbH >>> Jan, are you doing the right thing with the dates when transfering >>> copyright? I think the year must always stay the same for a particular >>> version, because eventually the copyright runs out. If new additions are >>> made then new years are added. >> not sure whether it is correct to have a year prior to existance >> of legal entity holding the copyright. Thats why I changed all to 2009. > > http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices > > Don't delete old year numbers, though; they are significant since they indicate > when older versions might theoretically go into the public domain, if the movie > companies don't continue buying laws to further extend copyright. If you copy a > file into the package from some other program, keep the copyright years that > come with the file. > > I wonder what their rule is when transfering copyright older than the legal > entity. > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel > From Jan-Oliver.Wagner at greenbone.net Wed Sep 23 21:05:07 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 23 Sep 2009 21:05:07 +0200 Subject: [Openvas-devel] openvas-scanner 3.0.0-beta1 Message-ID: <200909232105.07497.Jan-Oliver.Wagner@greenbone.net> Hello OpenVAS developers, now we have also 3.0.0-beta1 of openvas-scanner http://wald.intevation.org/frs/?group_id=29&release_id=285 In conjunction with openvas-libraries 3.0.0-beta1 you have a working scanner to play with. The scanner is compatible with the OpenVAS NVT Feed and also with OpenVAS-Client 2.0.x. Any feedback regarding building, packaging and using is very welcome! Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From matthew.mundell at intevation.de Fri Sep 25 11:13:56 2009 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 25 Sep 2009 09:12:56 -0001 Subject: [Openvas-devel] [Openvas-commits] r5228 - in trunk/openvas-manager: . src src/tests In-Reply-To: Message of Fri, 25 Sep 2009 09:45:25 +0200 (CEST). <20090925074525.58AC885D9F6B@pyrosoma.intevation.org> Message-ID: <20090925091339.4BD1FDEF6B@mail.ukfsn.org> > =================================================================== > --- trunk/openvas-manager/src/manage.h 2009-09-25 07:32:08 UTC (rev 5227) > +++ trunk/openvas-manager/src/manage.h 2009-09-25 07:45:23 UTC (rev 5228) > @@ -30,8 +30,8 @@ > #include > #include > > -#include > -#include > +#include /* for certificate_t */ > +#include /* for nvti_t */ Please can we refrain from doing this. It adds maintenance with little gain. It makes the include block text-heavy and messy, and it's hard to do consistently. There's little need for it in these cases. For nvti, for example, the word nvti only occurs twice in manage.h, so it's easy to see the reason that the include is present. nvti.h exports a small interface anyway, so it would be pretty obvious even in a large file like manage.c. From Jan-Oliver.Wagner at greenbone.net Mon Sep 28 08:06:14 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 28 Sep 2009 08:06:14 +0200 Subject: [Openvas-devel] [Openvas-commits] r5228 - in trunk/openvas-manager: . src src/tests In-Reply-To: <20090925091339.4BD1FDEF6B@mail.ukfsn.org> References: <20090925091339.4BD1FDEF6B@mail.ukfsn.org> Message-ID: <200909280806.14616.Jan-Oliver.Wagner@greenbone.net> On Friday 25 September 2009 11:13:56 Matthew Mundell wrote: > > =================================================================== > > --- trunk/openvas-manager/src/manage.h 2009-09-25 07:32:08 UTC (rev 5227) > > +++ trunk/openvas-manager/src/manage.h 2009-09-25 07:45:23 UTC (rev 5228) > > @@ -30,8 +30,8 @@ > > #include > > #include > > > > -#include > > -#include > > +#include /* for certificate_t */ > > +#include /* for nvti_t */ > > Please can we refrain from doing this. It adds maintenance with little > gain. It makes the include block text-heavy and messy, and it's hard to do > consistently. There's little need for it in these cases. For nvti, for > example, the word nvti only occurs twice in manage.h, so it's easy to see > the reason that the include is present. nvti.h exports a small interface > anyway, so it would be pretty obvious even in a large file like manage.c. we have numerous includes all over the code without a need. People tend to not care about removing includes when removing code. The way I marked the include, my editor shows me quickly whether this function is still in the code or not. If not, I can remove the include, recompile and see whether it can remain deleted. I hate bloated 'just in case' include and define blocks. They consume your time when trying to trace a bug. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Wed Sep 23 16:32:59 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Wed, 23 Sep 2009 16:32:59 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1122=5D_tools/open?= =?utf-8?q?vas-ssh-client-rpm-creator=2Esh_is_full_of_bashism?= Message-ID: <20090923143259.A332D865F467@pyrosoma.intevation.org> Bugs item #1122, was opened at 2009-09-23 14:32 Status: Open Priority: 3 Submitted By: Jan Wagner (waja) Assigned to: Nobody (None) Summary: tools/openvas-ssh-client-rpm-creator.sh is full of bashism Architecture: None Resolution: None Severity: normal Version: v2.0.5 Component: openvas-client Operating System: All Product: OpenVAS Hardware: None URL: Initial Comment: $ checkbashisms tools/openvas-ssh-client-rpm-creator.sh possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 16 (type): if type printf > /dev/null; then possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 88 (type): MD5_PATH=`exec <&- 2>&-; which md5sum || type md5sum` possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 89 (type): test -x "$MD5_PATH" || MD5_PATH=`exec <&- 2>&-; which md5 || type md5` possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 90 (type): test -x "$MD5_PATH" || MD5_PATH=`exec <&- 2>&-; which digest || type digest` possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 137 (kill -[0-9] or -[A-Z]): tar $1vf - 2>&1 || { echo Extraction failed. > /dev/tty; kill -15 $$; } possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 279 ($RANDOM): tmpdir=$TMPROOT/makeself.$RANDOM.`date +"%y%m%d%H%M%S"`.$$ possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 304 (type): if type $a >/dev/null 2>&1; then possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 328 ($RANDOM): tmpdir="$TMPROOT/selfgz$$$RANDOM" possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 356 (trap with signal numbers): trap 'echo Signal caught, cleaning up >&2; cd $TMPROOT; /bin/rm -rf $tmpdir; eval $finish; exit 15' 1 2 3 15 possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 478 (should be 'b = a'): if [ $# == 1 ]; possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 710 (type): if type gzip 2>&1 > /dev/null; then possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 952 (type): MD5_PATH=`exec <&- 2>&-; which md5sum || type md5sum` possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 953 (type): test -x $MD5_PATH || MD5_PATH=`exec <&- 2>&-; which md5 || type md5` possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 954 (type): test -x $MD5_PATH || MD5_PATH=`exec <&- 2>&-; which digest || type digest` possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 1818 (type): under certain conditions; type `show c' for details. possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 2389 (type): if type gzip 2>&1 > /dev/null; then possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 2631 (type): MD5_PATH=`exec <&- 2>&-; which md5sum || type md5sum` possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 2632 (type): test -x $MD5_PATH || MD5_PATH=`exec <&- 2>&-; which md5 || type md5` possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 2633 (type): test -x $MD5_PATH || MD5_PATH=`exec <&- 2>&-; which digest || type digest` possible bashism in tools/openvas-ssh-client-rpm-creator.sh line 3497 (type): under certain conditions; type `show c' for details. Beside the 2 false positive, there is a patch attached against openvas-ssh-client-rpm-creator.sh which is fixing that. As bonus a patch against openvas-lsc-target-preparation is included. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1122&group_id=29 From Jan-Oliver.Wagner at greenbone.net Mon Sep 28 09:30:58 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 28 Sep 2009 09:30:58 +0200 Subject: [Openvas-devel] Planning openvas-libraries 3.0.0-beta2 Message-ID: <200909280931.03939.Jan-Oliver.Wagner@greenbone.net> Hello OpenVAS developers, the first beta of openvas-libraries has accelerated improvements nicely. Packing issues and consitencies have been addressed and it is helpful to have the second beta now quickly. If testing goes well, I might even release beta2 today. If you have patches or issues that don't make it today, don't worry. I even expect a beta3 during this week. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Mon Sep 28 09:37:12 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 28 Sep 2009 09:37:12 +0200 Subject: [Openvas-devel] Planning openvas-scanner 3.0.0-beta2 Message-ID: <200909280937.15221.Jan-Oliver.Wagner@greenbone.net> Hi, following a openvas-libraries 3.0.0-beta2 release a beta2 of the scanner needs to be done which reflects the API changes in libraries. I expect the beta2 very shortly after the libraries beta2. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Mon Sep 28 17:09:40 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 28 Sep 2009 17:09:40 +0200 Subject: [Openvas-devel] openvas-libraries/openvas-scanner 3.0.0-beta2 Message-ID: <200909281709.44422.Jan-Oliver.Wagner@greenbone.net> Hello OpenVAS developers, the second beta for openvas-libraries and openvas-scaner is released now: http://wald.intevation.org/frs/?group_id=29&release_id=286 http://wald.intevation.org/frs/?group_id=29&release_id=287 These two modules are a equivalent replacement for openvas-libraries 2.0, openvas-server 2.0, openvas-plugins 1.0 and openvas-libnasl 2.0. They are compatible with openvas-client 2.0, the OpenVAS NVT Feed and the Greenbone Security Feed. Please try out this beta2 and report any issues. If no major issues are reported, I would like to add "OpenVAS 3.0 BETA" to the Download box on the OpenVAS homepage and do a announcement to the mailing list. This is in order to get more testers on board early. Any concerns with this strategy? All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From matthew.mundell at intevation.de Tue Sep 29 11:45:06 2009 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 29 Sep 2009 09:44:06 -0001 Subject: [Openvas-devel] [Openvas-commits] r5228 - in trunk/openvas-manager: . src src/tests In-Reply-To: Message of Mon, 28 Sep 2009 08:06:14 +0200. <200909280806.14616.Jan-Oliver.Wagner@greenbone.net> Message-ID: <20090929094446.8CB27E03BE@mail.ukfsn.org> > On Friday 25 September 2009 11:13:56 Matthew Mundell wrote: > > > =================================================================== > > > --- trunk/openvas-manager/src/manage.h 2009-09-25 07:32:08 UTC (rev 5227) > > > +++ trunk/openvas-manager/src/manage.h 2009-09-25 07:45:23 UTC (rev 5228) > > > @@ -30,8 +30,8 @@ > > > #include > > > #include > > > > > > -#include > > > -#include > > > +#include /* for certificate_t */ > > > +#include /* for nvti_t */ > > > > Please can we refrain from doing this. It adds maintenance with little > > gain. It makes the include block text-heavy and messy, and it's hard to do > > consistently. There's little need for it in these cases. For nvti, for > > example, the word nvti only occurs twice in manage.h, so it's easy to see > > the reason that the include is present. nvti.h exports a small interface > > anyway, so it would be pretty obvious even in a large file like manage.c. > > we have numerous includes all over the code without a need. > People tend to not care about removing includes when removing code. Are extra includes such a problem? > The way I marked the include, my editor shows me quickly > whether this function is still in the code or not. > If not, I can remove the include, recompile and see whether > it can remain deleted. > > I hate bloated 'just in case' include and define blocks. They > consume your time when trying to trace a bug. How does having redundant includes affect tracing? From bitdealer at gmail.com Mon Sep 28 19:23:17 2009 From: bitdealer at gmail.com (Stephan Kleine) Date: Mon, 28 Sep 2009 19:23:17 +0200 Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 2 feedback Message-ID: Hi. TBH I'm a bit confused how I am supposed to compile that thing since it's some mix of autoconf & cmake. The problem is that if I use "%configure" (which sets --prefix, --exec-prefix, --mandir et al automatically) it fails with http://pastebin.ca/1582809 . Also you can see that it uses e.g. -DOPENVAS_STATE_DIR=\"/usr/var/lib/openvas\" and -DOPENVAS_SYSCONFDIR=\"/usr/etc/openvas\" - as in it prepends the prefix where it doesn't belong. Contrary, if I just use "./configure" without any arguments it compiles fine but all the stuff is bellow /usr/local which isn't right either. So how am I supposed to set a proper prefix? In other words, you should IMHO either use cmake or autoconf and not mix them but if you insist on mixing them make it so "%configure" can be used since it sets all the proper locations automatically. (E.g. on openSUSE 11.1 i586 it is "./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") Further it fails on e.g. 10.3 (cmake-2.4.7-17) with: CMake Error: Error in cmake code at /usr/src/packages/BUILD/openvas-libraries-3.0.0.beta2/base/CMakeLists.txt:31: IF had incorrect arguments: POLICY CMP0005 (Unknown arguments specified). Current CMake stack: [1] /usr/src/packages/BUILD/openvas-libraries-3.0.0.beta2/base/CMakeLists.txt CMake Error: Error in cmake code at /usr/src/packages/BUILD/openvas-libraries-3.0.0.beta2/base/CMakeLists.txt:32: Unknown CMake command "cmake_policy". It would be great if you could come up with some solution so it works there as well if possible or define a proper minimum cmake version which is checked. Regards, Stephan From Jan-Oliver.Wagner at greenbone.net Tue Sep 29 14:38:11 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Tue, 29 Sep 2009 14:38:11 +0200 Subject: [Openvas-devel] Planning openvas-client 3.0.0-beta1 Message-ID: <200909291438.16816.Jan-Oliver.Wagner@greenbone.net> Hi OpenVAS developers, after the OpenVAS Scanner, next thing to get into first beta is the OpenVAS Client. I therefore like to release beta1 of openvas-client very soon to have a first trial version to play with. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From matthew.mundell at intevation.de Tue Sep 29 14:46:28 2009 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 29 Sep 2009 12:45:28 -0001 Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 2 feedback In-Reply-To: Message of Mon, 28 Sep 2009 19:23:17 +0200. Message-ID: <20090929124608.54ABEDEB9D@mail.ukfsn.org> > Further it fails on e.g. 10.3 (cmake-2.4.7-17) with: > > CMake Error: Error in cmake code at > /usr/src/packages/BUILD/openvas-libraries-3.0.0.beta2/base/CMakeLists.txt:31: > IF had incorrect arguments: POLICY CMP0005 (Unknown arguments specified). > Current CMake stack: > [1] /usr/src/packages/BUILD/openvas-libraries-3.0.0.beta2/base/CMakeLists.txt > CMake Error: Error in cmake code at > /usr/src/packages/BUILD/openvas-libraries-3.0.0.beta2/base/CMakeLists.txt:32: > Unknown CMake command "cmake_policy". > > It would be great if you could come up with some solution so it works > there as well if possible or define a proper minimum cmake version > which is checked. We've set the proper cmake version in trunk already, so that will be in beta3. -- 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 greenbone.net Wed Sep 30 11:11:55 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 30 Sep 2009 11:11:55 +0200 Subject: [Openvas-devel] openvas-client 3.0.0-beta1 ready for testing Message-ID: <200909301111.58455.Jan-Oliver.Wagner@greenbone.net> Hello, the first beta of openvas-client 3.0 is now out for testing: http://wald.intevation.org/frs/download.php/644/openvas-client-3.0.0.beta1.tar.gz Any help on translations is welcome. Please report any IPv6 test results here as well. The OMP part is a bit fragile yet. We will test and fix it a bit more. I do expect quick beta2, beta3 etc. following up. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Tue Sep 29 16:56:13 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Tue, 29 Sep 2009 16:56:13 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1125=5D_openvas-li?= =?utf-8?q?braries_does_not_build_properly?= Message-ID: <20090929145613.3E0EE85C7303@pyrosoma.intevation.org> Bugs item #1125, was opened at 2009-09-29 14:56 Status: Open Priority: 3 Submitted By: Stephan Kleine (bitshuffler) Assigned to: Nobody (None) Summary: openvas-libraries does not build properly Architecture: None Resolution: None Severity: blocker Version: v3.0-beta Component: openvas-libraries Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: TBH I'm a bit confused how I am supposed to compile that thing since it's some mix of autoconf & cmake. The problem is that if I use "%configure" (which sets --prefix, --exec-prefix, --mandir et al automatically) it fails with http://pastebin.ca/1582809 . Also you can see that it uses e.g. -DOPENVAS_STATE_DIR=\"/usr/var/lib/openvas\" and -DOPENVAS_SYSCONFDIR=\"/usr/etc/openvas\" - as in it prepends the prefix where it doesn't belong. Contrary, if I just use "./configure" without any arguments it compiles fine but all the stuff is bellow /usr/local which isn't right either. So how am I supposed to set a proper prefix? In other words, you should IMHO either use cmake or autoconf and not mix them but if you insist on mixing them make it so "%configure" can be used since it sets all the proper locations automatically. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1125&group_id=29