From michael.wiegand at intevation.de Fri Jan 2 08:38:05 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Fri, 2 Jan 2009 08:38:05 +0100 Subject: [Openvas-devel] CR#24 (Subdirectories for NVTs): Call for vote In-Reply-To: <200812292014.21450.jan-oliver.wagner@intevation.de> References: <200812292014.21450.jan-oliver.wagner@intevation.de> Message-ID: <20090102073804.GA12628@intevation.de> * Jan-Oliver Wagner [29. Dec 2008]: > Hello, > > I've updated the Change Request slightly: > > http://www.openvas.org/openvas-cr-24.html > > (However, the most important info is a working patch as recently sent > by Stjepan :-) +1 from me as well. Happy New Year, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Fri Jan 2 13:35:27 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 2 Jan 2009 13:35:27 +0100 Subject: [Openvas-devel] CR#24 (Subdirectories for NVTs): Call for vote In-Reply-To: <200812292014.21450.jan-oliver.wagner@intevation.de> References: <200812292014.21450.jan-oliver.wagner@intevation.de> Message-ID: <200901021335.31269.jan-oliver.wagner@intevation.de> On Montag, 29. Dezember 2008, Jan-Oliver Wagner wrote: > I've updated the Change Request slightly: > > http://www.openvas.org/openvas-cr-24.html > > (However, the most important info is a working patch as recently sent > by Stjepan :-) > > I call for a vote for this feature, because it hasn't been done yet at > a formal level. thanks for so many votes over the last days :-) We've updated the CR accordingly. Stjepan: I started to integrate your patch into OpenVAS, starting with openvas-libraries. I can't apply it 1:1 because I try to not break compaibility with the other modules. There is also quite some reformatting and renaming in your patch. This means I need some time for the integration. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Fri Jan 2 14:10:52 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 2 Jan 2009 14:10:52 +0100 Subject: [Openvas-devel] IPv6 In-Reply-To: <4d7b043c0812291111l1b66c356y6401bf5213d32de5@mail.gmail.com> References: <4d7b043c0812290253w11f5d9dh6f526aff15967b2e@mail.gmail.com> <200812291701.16421.jan-oliver.wagner@intevation.de> <4d7b043c0812291111l1b66c356y6401bf5213d32de5@mail.gmail.com> Message-ID: <200901021410.55209.jan-oliver.wagner@intevation.de> On Montag, 29. Dezember 2008, Stjepan Gros wrote: > On Mon, Dec 29, 2008 at 5:01 PM, Jan-Oliver Wagner > wrote: > > On Montag, 29. Dezember 2008, Stjepan Gros wrote: > > >> but what caught my attention was the mention of IPv6. It turns out > >> that OpenVAS doesn't support it? Is it true? > > > > I'd be thankful if anyone could clearly define or specify what "IPv6 Support in OpenVAS" > > is or should be. So far I received only foggy answers. > > It could mean few things: > > 1. It means that you can enter IPv6 address(es) in the OpenVAS client > and then those hosts, whith those addresses, are scanned. > > This is not so simple as just entering IPv6 address because the socket > code is different: > - for a start, addresses are stored in sockaddr_in6 structure instead > of sockaddr_in > - AF_INET6 has to be used in place of AF_INET (e.g. creating socket, > converting ascii adresses with inet_pton/inet_ntop) > - constants like INADDR_ANY can not be used with IPv6 > > after the socket is created and bound (or connected) I believe it > doesn't matter any more if IPv4 or IPv6 is used. > > 2. It means that when you enter hostname (or FQDN) which resolves to > IPv6 address, this address will be used > > 3. There is a code in openvas for forging IP packets. This code has to > be enhanced to know how to construct IPv6 packets. > > 4. NASL laguage has to be enhanced to accept IPv6 addresses, and > potentially IPv6 specific extensions. > > And IMHO, with all the recent hype around IPv4 address shortages, and > IPv6 mandatory use, and a like, i think that it would be good to > introduce IPv6 as soon as possible, but that obviously won't be easy. This all sounds like a pretty good plan. Anyone interested in transfering this into a initial Change Request document? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Sun Jan 4 01:52:31 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sun, 4 Jan 2009 01:52:31 +0100 Subject: [Openvas-devel] Changes to cache file handling Message-ID: <200901040152.32235.jan-oliver.wagner@intevation.de> Hello, I just comitted some further changes on the handling of cache files (.desc). It still needs some testing whether it works compatible with openvas-server 2.0.0 release. The main change is that the cache files now have different names (".desc" now appended, instead of replacing ".nasl" by ".desc"). In fact this is yet another patch that was derived from Stjepans patch for CR #24 (subdirs for plugins). Next planned patch is to finalize changes to openvas-libraries so that it allows for the new feature and can be released eventually as 2.0.1. Stjepans patch then extends to -libnasl and -server. The reason the progress is slow is that I had to do several cleanups of the code. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Tue Jan 6 09:16:23 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 6 Jan 2009 09:16:23 +0100 Subject: [Openvas-devel] Changes to cache file handling In-Reply-To: <200901040152.32235.jan-oliver.wagner@intevation.de> References: <200901040152.32235.jan-oliver.wagner@intevation.de> Message-ID: <20090106081623.GA31099@intevation.de> * Jan-Oliver Wagner [ 4. Jan 2009]: > I just comitted some further changes on the handling of cache files (.desc). > It still needs some testing whether it works compatible with openvas-server > 2.0.0 release. The main change is that the cache files now have different names > (".desc" now appended, instead of replacing ".nasl" by ".desc"). Just a quick follow-up: I've tested openvas-libraries from trunk yesterday with -libnasl and -server from 2.0.0. AFAICT there seem to be no compatibility issues, additional testers are of course welcome. Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Tue Jan 6 12:10:41 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 6 Jan 2009 12:10:41 +0100 Subject: [Openvas-devel] Replacing libopenvas with glib... In-Reply-To: <4d7b043c0811200346vc2fda16oc3efc00eb5050998@mail.gmail.com> References: <4d7b043c0811200346vc2fda16oc3efc00eb5050998@mail.gmail.com> Message-ID: <200901061210.41703.felix.wolfsteller@intevation.de> On Thursday 20 November 2008 12:46:42 Stjepan Gros wrote: > I was looking a bit into arglists.c and it seems basically to be a > hash table that allows different objects to be stored and quickly > retrieved. The closest data structure in GLib seems to be GHashTable. > The problem is that GHashTable stores pointers so another layer above > it is necessary in order to replace arglists.c. In conclusion, it > would be relatively easy to modify arglists.c to use glib's functions > while the rest of the code stays unchanged. About arglist removal from client: The arglist idea is heavily misused all over the place. I think the way to go is to identify places where the content (key and type) of the arglist are actually known in the right beginning and to transform these code segments one by one. Sometimes a new structure will be born, sometimes maybe not, because a plain list or GHashTable suffices. For example in the client, nearly all GTK- Widgets are indexed by arglists, making it a mess to access them, because 1) You have to know under which key the widget is stored. 2) Some arglists are indeed lists of arglist containing similar or the same keys (grep for "FRAME") So, to access a widget, arg_get_xyz has to be called, comparing the key string against every key string in one or many arglists until it has been found. Replacing this mechanism (quite a ton of work) would 1) reduce the code base 2) make it faster 3) make OpenVAS client use less memory 4) make the gui easier to handle for developers. Might be worth a change request in the middle near future. Maybe we can collect some ideas about arglist removal, I have to admit that I think that I did not quite get Jans idea (below). --felix On Thursday 20 November 2008 12:46:42 Stjepan Gros wrote: > > > I am not aware of anyone approaching this. > > It is not a too simple task. > > > > My idea was that we should start with a > > struct NVT_Desc {} in OpenVAS-Client and step-by-step > > change to this strucure (which members are some Glib Datacontainers) > > all over the client. Probably some lessons need to be learned. > > Once finished this, the gained experience should be good > > enough to approach the server. > > I couldn't figure out from this short description what you exactly intend > to do. >> > > > In the meantime we'll try to make the server as light as possible > > to increase readability of this code ;-) > > _______________________________________________ > 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 felix.wolfsteller at intevation.de Tue Jan 6 12:15:23 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 6 Jan 2009 12:15:23 +0100 Subject: [Openvas-devel] Replacing libopenvas with glib... In-Reply-To: <200901061210.41703.felix.wolfsteller@intevation.de> References: <4d7b043c0811200346vc2fda16oc3efc00eb5050998@mail.gmail.com> <200901061210.41703.felix.wolfsteller@intevation.de> Message-ID: <200901061215.23528.felix.wolfsteller@intevation.de> OK, my desperation let me exaggerate a bit: > So, to access a widget, arg_get_xyz has to be called, comparing the key > string against every key string in one or many arglists until it has been > found. It uses some hashing, so not dramatically many string comparisons have to be done (anyway in this case even a single one is too much). --felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From sgros.ml at gmail.com Tue Jan 6 14:40:29 2009 From: sgros.ml at gmail.com (Stjepan Gros) Date: Tue, 6 Jan 2009 14:40:29 +0100 Subject: [Openvas-devel] Changes to cache file handling In-Reply-To: <200901040152.32235.jan-oliver.wagner@intevation.de> References: <200901040152.32235.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0901060540m36814b47y450768f62e1c1f7@mail.gmail.com> Ok, I'm allive so to give some small comments on this. :) On Sun, Jan 4, 2009 at 1:52 AM, Jan-Oliver Wagner wrote: > Hello, > > I just comitted some further changes on the handling of cache files (.desc). > It still needs some testing whether it works compatible with openvas-server > 2.0.0 release. The main change is that the cache files now have different names > (".desc" now appended, instead of replacing ".nasl" by ".desc"). This could cause slight compatibility problem (annoyance better to say), not visible at first. Namely, existing cache with .desc will be left and not deleted, while the new one will be created with .nasl.desc extension. This should be taken care of during the upgrade. > In fact this is yet another patch that was derived from Stjepans patch > for CR #24 (subdirs for plugins). > > Next planned patch is to finalize changes to openvas-libraries so > that it allows for the new feature and can be released eventually as 2.0.1. > Stjepans patch then extends to -libnasl and -server. Should this be better versioned as 2.1 because the third numeral usually means only bug fixes and minor changes? > The reason the progress is slow is that I had to do several cleanups of the > code. Well, I see this progresses well. :) There is one optimization when cache is created that could be made. Namely, when plugin is loaded and parsed then it's stored in cache and then reloaded. I have to see if this reloading could be avoided. This will save one disk access (even though it is cached by the OS). SG From sgros.ml at gmail.com Tue Jan 6 16:16:16 2009 From: sgros.ml at gmail.com (Stjepan Gros) Date: Tue, 6 Jan 2009 16:16:16 +0100 Subject: [Openvas-devel] IPv6 In-Reply-To: <200901021410.55209.jan-oliver.wagner@intevation.de> References: <4d7b043c0812290253w11f5d9dh6f526aff15967b2e@mail.gmail.com> <200812291701.16421.jan-oliver.wagner@intevation.de> <4d7b043c0812291111l1b66c356y6401bf5213d32de5@mail.gmail.com> <200901021410.55209.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0901060716m3a42f046g85383f1dd122e31b@mail.gmail.com> On Fri, Jan 2, 2009 at 2:10 PM, Jan-Oliver Wagner wrote: > On Montag, 29. Dezember 2008, Stjepan Gros wrote: >> On Mon, Dec 29, 2008 at 5:01 PM, Jan-Oliver Wagner >> wrote: >> > On Montag, 29. Dezember 2008, Stjepan Gros wrote: >> >> >> but what caught my attention was the mention of IPv6. It turns out >> >> that OpenVAS doesn't support it? Is it true? >> > >> > I'd be thankful if anyone could clearly define or specify what "IPv6 Support in OpenVAS" >> > is or should be. So far I received only foggy answers. >> >> It could mean few things: >> >> 1. It means that you can enter IPv6 address(es) in the OpenVAS client >> and then those hosts, whith those addresses, are scanned. >> >> This is not so simple as just entering IPv6 address because the socket >> code is different: >> - for a start, addresses are stored in sockaddr_in6 structure instead >> of sockaddr_in >> - AF_INET6 has to be used in place of AF_INET (e.g. creating socket, >> converting ascii adresses with inet_pton/inet_ntop) >> - constants like INADDR_ANY can not be used with IPv6 >> >> after the socket is created and bound (or connected) I believe it >> doesn't matter any more if IPv4 or IPv6 is used. >> >> 2. It means that when you enter hostname (or FQDN) which resolves to >> IPv6 address, this address will be used >> >> 3. There is a code in openvas for forging IP packets. This code has to >> be enhanced to know how to construct IPv6 packets. >> >> 4. NASL laguage has to be enhanced to accept IPv6 addresses, and >> potentially IPv6 specific extensions. >> >> And IMHO, with all the recent hype around IPv4 address shortages, and >> IPv6 mandatory use, and a like, i think that it would be good to >> introduce IPv6 as soon as possible, but that obviously won't be easy. > > This all sounds like a pretty good plan. > Anyone interested in transfering this into a initial Change Request document? Well, since no one did it yet, here is one proposal. SG -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-cr-26.htm4 Type: application/octet-stream Size: 3660 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090106/2c90eb03/openvas-cr-26.obj From gautam.chekuri at gmail.com Wed Jan 7 06:59:45 2009 From: gautam.chekuri at gmail.com (gautam chekuri) Date: Wed, 7 Jan 2009 11:29:45 +0530 Subject: [Openvas-devel] OTP 1.0 client in ruby Message-ID: <44265ba90901062159q77e52b0amf62d87aa6bc3a66a@mail.gmail.com> Hi all, 1. I use OpenVAS on my debian laptops to identify any potential unpatched programs. I find it especially useful because it warns about potential security holes in Firefox and thunderbird. Sometimes, I also use it to scan the machines of my friends. 2. The OpenVAS client written in C is great, but I would love to have scriptable client(preferably a library in a scripting language) :-p 3. Hence, I trying to write a OpenVAS client in ruby. My immediate goal is to be able to ask the server to launch attacks from a ruby script and receive the results from the server. 4. To implement this I choose ruby (because that's the language I've been working on nowadays). I am referring to the compendium and the code in openvas-client-2.0.1/nessus/*.c. For example to understand how to tell the server to start and attack I referred to attack_host() in attack.c 5. I just wanted to ask if there is anything else that I might want to refer to. 6. I am hosting the code on github : http://github.com/gautamc/ovasotp-ruby/tree/master (its pretty dumb right now, but I will be improving on it .. :) ) Thanks, Gautam Chekuri Programmer - Azri Solutions Pvt Ltd. "May the source be with GNU" From michael.wiegand at intevation.de Wed Jan 7 09:04:30 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 7 Jan 2009 09:04:30 +0100 Subject: [Openvas-devel] OTP 1.0 client in ruby In-Reply-To: <44265ba90901062159q77e52b0amf62d87aa6bc3a66a@mail.gmail.com> References: <44265ba90901062159q77e52b0amf62d87aa6bc3a66a@mail.gmail.com> Message-ID: <20090107080430.GB11600@intevation.de> * gautam chekuri [ 7. Jan 2009]: > 5. I just wanted to ask if there is anything else that I might want to refer to. One thing you should keep in mind is that the days of OTP are numbered as we are planning on replacing it with a new and improved protocol as described by Jan in http://lists.wald.intevation.org/pipermail/openvas-devel/2008-December/001227.html . This protocol will probably make writing other clients a lot easier, so it might be worth it for you to wait a little while and save a lot of time and headaches. ;) I will most likely put up a first draft of the protocol specification in the next few days and write a change request which will then be discussed. I'd recommend you keep an eye on openvas-devel and join us on IRC if you want to stay up-to-date. Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Thu Jan 8 01:21:17 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 8 Jan 2009 01:21:17 +0100 Subject: [Openvas-devel] Changes to cache file handling In-Reply-To: <4d7b043c0901060540m36814b47y450768f62e1c1f7@mail.gmail.com> References: <200901040152.32235.jan-oliver.wagner@intevation.de> <4d7b043c0901060540m36814b47y450768f62e1c1f7@mail.gmail.com> Message-ID: <200901080121.17825.jan-oliver.wagner@intevation.de> Hello Stjepan, I've further analysed your API requirements for openvas-libraries. You introduced a "subdir" param for two functions of store.c. AFAIU, this subdir is the path between the cache_dir and the actual filename. My changes to store_plugin and store_load_plugin allow to have arbitrary paths for filename. So you can combine subdir and filename when calling the function. (Perhaps use g_build_filename() for this). You should now be in the position to narrow down your patch in a way that you do not need to patch anything in openvas-libraries anymore (just use the latest SVN checkout). Next I will try to understand the concept of the include dirs list you have implemented. On Tuesday 06 January 2009 14:40:29 Stjepan Gros wrote: > On Sun, Jan 4, 2009 at 1:52 AM, Jan-Oliver Wagner > > I just comitted some further changes on the handling of cache files > > (.desc). It still needs some testing whether it works compatible with > > openvas-server 2.0.0 release. The main change is that the cache files now > > have different names (".desc" now appended, instead of replacing ".nasl" > > by ".desc"). > > This could cause slight compatibility problem (annoyance better to > say), not visible at first. Namely, existing cache with .desc will be > left and not deleted, while the new one will be created with > .nasl.desc extension. This should be taken care of during the upgrade. yes. This should also be explained in the release/announce text for the next version of openvas-libraries. > > In fact this is yet another patch that was derived from Stjepans patch > > for CR #24 (subdirs for plugins). > > > > Next planned patch is to finalize changes to openvas-libraries so > > that it allows for the new feature and can be released eventually as > > 2.0.1. Stjepans patch then extends to -libnasl and -server. > > Should this be better versioned as 2.1 because the third numeral > usually means only bug fixes and minor changes? Well, there is no API change so far. So I thought, += 0.0.1 is OK ;-) > > The reason the progress is slow is that I had to do several cleanups of > > the code. > > Well, I see this progresses well. :) There is one optimization when > cache is created that could be made. Namely, when plugin is loaded and > parsed then it's stored in cache and then reloaded. I have to see if > this reloading could be avoided. This will save one disk access (even > though it is cached by the OS). but this is outside of openvas-libraries, AFAIU. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Thu Jan 8 11:41:59 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 8 Jan 2009 11:41:59 +0100 Subject: [Openvas-devel] Planning openvas-compendium 1.0.1 Message-ID: <20090108104159.GA2586@intevation.de> Hello, since the 1.0.0 version of the OpenVAS compendium does not yet reflect the release of OpenVAS 2.0.0 and a few other changes, I would like to release an update version of the compendium. I would like to do the 1.0.1 release on Wednesday, Jan 14. If there is anything you would like to add or update, please do so until Tuesday. Please let me know if you need help incorporating your changes or have any other questions. Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Thu Jan 8 14:25:52 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 8 Jan 2009 14:25:52 +0100 Subject: [Openvas-devel] IPv6 In-Reply-To: <4d7b043c0901060716m3a42f046g85383f1dd122e31b@mail.gmail.com> References: <4d7b043c0812290253w11f5d9dh6f526aff15967b2e@mail.gmail.com> <200901021410.55209.jan-oliver.wagner@intevation.de> <4d7b043c0901060716m3a42f046g85383f1dd122e31b@mail.gmail.com> Message-ID: <200901081425.54848.jan-oliver.wagner@intevation.de> Hi Stjepan, On Dienstag, 6. Januar 2009, Stjepan Gros wrote: > On Fri, Jan 2, 2009 at 2:10 PM, Jan-Oliver Wagner > > This all sounds like a pretty good plan. > > Anyone interested in transfering this into a initial Change Request document? > > Well, since no one did it yet, here is one proposal. thanks! Meanwhile Chandra comitted it an put it online. (since there was yet another CR, it became #27) http://www.openvas.org/openvas-cr-27.html Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From timb at nth-dimension.org.uk Thu Jan 8 15:30:19 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Thu, 8 Jan 2009 14:30:19 +0000 Subject: [Openvas-devel] OTP 1.0 client in ruby In-Reply-To: <44265ba90901062159q77e52b0amf62d87aa6bc3a66a@mail.gmail.com> References: <44265ba90901062159q77e52b0amf62d87aa6bc3a66a@mail.gmail.com> Message-ID: <200901081430.19705.timb@nth-dimension.org.uk> You might want to have a chat with the Metasploit guys, I know HD has implemented an OpenVAS compatible server in Ruby which allows him to drive Metasploit from the OpenVAS-Client GUI. Cheers, Tim -- Tim Brown From gautam.chekuri at gmail.com Wed Jan 7 05:24:40 2009 From: gautam.chekuri at gmail.com (gautam chekuri) Date: Wed, 7 Jan 2009 09:54:40 +0530 Subject: [Openvas-devel] OTP 1.0 client in ruby Message-ID: <44265ba90901062024o4dec2dccw7561e591c25afafe@mail.gmail.com> Hi all, 1. I use OpenVAS on my debian laptops to identify any potential unpatched programs. I find it especially useful because it warns about potential security holes in Firefox and thunderbird. Sometimes, I also use it to scan the machines of my friends. 2. The OpenVAS client written in C is great, but I would love to have scriptable client(preferably a library in a scripting language) :-p 3. Hence, I trying to write a OpenVAS client in ruby. My immediate goal is to be able to ask the server to launch attacks from a ruby script and receive the results from the server. 4. To implement this I choose ruby (becuase that's the language I've been working on nowadays). I am refering to the compendium and the code in openvas-client-2.0.1/nessus/*.c. For example to understand how to tell the server to start and attack I referred to attack_host() in attack.c 5. I just wanted to ask if there is anything else that I might want to refer to. 6. I am hosting the code on github : http://github.com/gautamc/ovasotp-ruby/tree/master (its pretty dumb right now, but I will be improving on it .. :) ) Thanks, Gautam Chekuri Programmer - Azri Solutions Pvt Ltd. "May the source be with GNU" From openvas-bugs at wald.intevation.org Thu Jan 8 23:02:40 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 8 Jan 2009 23:02:40 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B867=5D_OpenVAS_Cli?= =?utf-8?q?ent_Error_in_XML_output_Coruption?= Message-ID: <20090108220240.E417F40730@pyrosoma.intevation.org> Bugs item #867, was opened at 2009-01-08 16:02 Status: Open Priority: 3 Submitted By: MadHat Unspecific (unspecific) Assigned to: Nobody (None) Summary: OpenVAS Client Error in XML output Coruption Resolution: None Severity: minor Version: v2.0 Component: openvas-client Operating System: All Product: OpenVAS Hardware: None URL: Initial Comment: When ouputing to XML, the entry for nessus/openvas breaks because it has a "/" in the name. The code is below but I don't have the time or knowledge to fix it right now. In the NBE it looks like this: results|localhost|scanner.localhost|nessus/openvas (1241/tcp) In the XML it looks like this: This is either doing a conversion from the NBE or doing a direct XML output. This is from the SVN version, just updated. Updated to revision 2170. xml_output_ng.c:Line 498 getproto (char *str) { int i=0, offset=0, len=strlen (str); char *ret = emalloc (len); for (i=0;i References: <200901040152.32235.jan-oliver.wagner@intevation.de> <4d7b043c0901060540m36814b47y450768f62e1c1f7@mail.gmail.com> <200901080121.17825.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0901091353l3fe35231x14d460b9b261d1a2@mail.gmail.com> On Thu, Jan 8, 2009 at 1:21 AM, Jan-Oliver Wagner wrote: > Hello Stjepan, > > I've further analysed your API requirements for openvas-libraries. > You introduced a "subdir" param for two functions of store.c. > AFAIU, this subdir is the path between the cache_dir and the actual > filename. > > My changes to store_plugin and store_load_plugin > allow to have arbitrary paths for filename. So you can > combine subdir and filename when calling the function. > (Perhaps use g_build_filename() for this). I can't remember why I did this that way (i.e. that subdir is separately handled). Probably there could be some optimization in combining the subdir and filename. But, one of the possible problems, as I remember, is that implicit include dir is subdirectory, relative to a top level plugin directory, where plugin resides. If I combine the two (filename and subdir) than I have a problem to get back subdir in order to put it into a list of include directories. SG > You should now be in the position to narrow down your patch > in a way that you do not need to patch anything in openvas-libraries > anymore (just use the latest SVN checkout). > Next I will try to understand the concept of the include dirs list > you have implemented. > > On Tuesday 06 January 2009 14:40:29 Stjepan Gros wrote: >> On Sun, Jan 4, 2009 at 1:52 AM, Jan-Oliver Wagner >> > I just comitted some further changes on the handling of cache files >> > (.desc). It still needs some testing whether it works compatible with >> > openvas-server 2.0.0 release. The main change is that the cache files now >> > have different names (".desc" now appended, instead of replacing ".nasl" >> > by ".desc"). >> >> This could cause slight compatibility problem (annoyance better to >> say), not visible at first. Namely, existing cache with .desc will be >> left and not deleted, while the new one will be created with >> .nasl.desc extension. This should be taken care of during the upgrade. > > yes. This should also be explained in the release/announce text for the > next version of openvas-libraries. > >> > In fact this is yet another patch that was derived from Stjepans patch >> > for CR #24 (subdirs for plugins). >> > >> > Next planned patch is to finalize changes to openvas-libraries so >> > that it allows for the new feature and can be released eventually as >> > 2.0.1. Stjepans patch then extends to -libnasl and -server. >> >> Should this be better versioned as 2.1 because the third numeral >> usually means only bug fixes and minor changes? > > Well, there is no API change so far. So I thought, += 0.0.1 is OK ;-) > >> > The reason the progress is slow is that I had to do several cleanups of >> > the code. >> >> Well, I see this progresses well. :) There is one optimization when >> cache is created that could be made. Namely, when plugin is loaded and >> parsed then it's stored in cache and then reloaded. I have to see if >> this reloading could be avoided. This will save one disk access (even >> though it is cached by the OS). > > but this is outside of openvas-libraries, AFAIU. > > Best > > Jan > > -- > Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ > Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel > From jan-oliver.wagner at intevation.de Fri Jan 9 23:23:27 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 9 Jan 2009 23:23:27 +0100 Subject: [Openvas-devel] Changes to cache file handling In-Reply-To: <4d7b043c0901091353l3fe35231x14d460b9b261d1a2@mail.gmail.com> References: <200901040152.32235.jan-oliver.wagner@intevation.de> <200901080121.17825.jan-oliver.wagner@intevation.de> <4d7b043c0901091353l3fe35231x14d460b9b261d1a2@mail.gmail.com> Message-ID: <200901092323.29863.jan-oliver.wagner@intevation.de> On Freitag, 9. Januar 2009, Stjepan Gros wrote: > > My changes to store_plugin and store_load_plugin > > allow to have arbitrary paths for filename. So you can > > combine subdir and filename when calling the function. > > (Perhaps use g_build_filename() for this). > > I can't remember why I did this that way (i.e. that subdir is > separately handled). Probably there could be some optimization in > combining the subdir and filename. But, one of the possible problems, > as I remember, is that implicit include dir is subdirectory, relative > to a top level plugin directory, where plugin resides. If I combine > the two (filename and subdir) than I have a problem to get back subdir > in order to put it into a list of include directories. Directory "." can easily be determined by removing the filename. Directory "/" for the plugin dir can't. But thats not necessary, because this directory is (should) always be set via store_init(). But maybe there are other good reasons for doing so. Once we find one it is fairly easy to switch to the subdir idea. For the time being I thought it would be good to not break API. BTW: Have you tested how your patch works for dependencies on other NASLs? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From sgros.ml at gmail.com Sat Jan 10 10:29:57 2009 From: sgros.ml at gmail.com (Stjepan Gros) Date: Sat, 10 Jan 2009 10:29:57 +0100 Subject: [Openvas-devel] Changes to cache file handling In-Reply-To: <200901092323.29863.jan-oliver.wagner@intevation.de> References: <200901040152.32235.jan-oliver.wagner@intevation.de> <200901080121.17825.jan-oliver.wagner@intevation.de> <4d7b043c0901091353l3fe35231x14d460b9b261d1a2@mail.gmail.com> <200901092323.29863.jan-oliver.wagner@intevation.de> Message-ID: <4d7b043c0901100129l1a4f24e9nbd6df3be45edb7b4@mail.gmail.com> On Fri, Jan 9, 2009 at 11:23 PM, Jan-Oliver Wagner wrote: > On Freitag, 9. Januar 2009, Stjepan Gros wrote: >> > My changes to store_plugin and store_load_plugin >> > allow to have arbitrary paths for filename. So you can >> > combine subdir and filename when calling the function. >> > (Perhaps use g_build_filename() for this). >> >> I can't remember why I did this that way (i.e. that subdir is >> separately handled). Probably there could be some optimization in >> combining the subdir and filename. But, one of the possible problems, >> as I remember, is that implicit include dir is subdirectory, relative >> to a top level plugin directory, where plugin resides. If I combine >> the two (filename and subdir) than I have a problem to get back subdir >> in order to put it into a list of include directories. > > Directory "." can easily be determined by removing the filename. At this point this is obviously equivalent, either subdirectory is handed explicitly or it is determined implicitly. > Directory "/" for the plugin dir can't. But thats not necessary, > because this directory is (should) always be set via store_init(). I just saw that you depricated store_init_{user,sys} which is good. This functions confused me as I didn't know what is their purpose. Anyway, I'm not very fond of global variables, and IMHO, I would remove them, but there could be advantages to their use. So, I'll leave this decision to you. And while I'm at deprecated functions that can not be removed until next major release it could be good to mark them as deprecated so that people know that and also, when the time comes for removal, that they are not forgotten. There is an attribute supported by gcc, __attribute__ ((__deprecated__)), that can be added to the deprecated functions so that compiler clearly warns about those functions when they are used. > But maybe there are other good reasons for doing so. Once we find > one it is fairly easy to switch to the subdir idea. For the time being > I thought it would be good to not break API. I think there are no more reasons for subdir parameter, especially when you can deduce what it is from the filename of a plugin. Anyway, I haven't had in mind the API compatibility, so maybe if I did, I would probably do it the way you did. > BTW: Have you tested how your patch works for dependencies on other > NASLs? Hm, I tried to load all the NASLs that are in trunk and that worked. I don't know is that the question, or you mean something else? Stjepan From lists at securityspace.com Wed Jan 14 16:07:15 2009 From: lists at securityspace.com (Thomas Reinke) Date: Wed, 14 Jan 2009 10:07:15 -0500 Subject: [Openvas-devel] [Openvas-commits] r2195 - trunk/openvas-plugins/scripts In-Reply-To: <20090114050923.EE88E40708@pyrosoma.intevation.org> References: <20090114050923.EE88E40708@pyrosoma.intevation.org> Message-ID: <496DFFA3.40000@securityspace.com> Are we keeping the "Windows : Microsoft Bulletins" family or has it been discontinued? Thomas scm-commit at wald.intevation.org wrote: > script_category(ACT_GATHER_INFO); > - script_family(english:"Windows : Microsoft Bulletins"); > + script_family(english:"Windows"); > script_name(english:"SMB Remote Code Execution Vulnerability (957095)"); From bchandra at secpod.com Wed Jan 14 16:31:09 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 14 Jan 2009 21:01:09 +0530 Subject: [Openvas-devel] [Openvas-commits] r2195 - trunk/openvas-plugins/scripts In-Reply-To: <496DFFA3.40000@securityspace.com> References: <20090114050923.EE88E40708@pyrosoma.intevation.org> <496DFFA3.40000@securityspace.com> Message-ID: <444B76E571B74F4CB0D826403217EEEA@bchandra> We are keeping this family, not sure how this got overwritten, we'll revert to that. All MS bulletins are getting written with this family. Chandra. -----Original Message----- From: Thomas Reinke [mailto:lists at securityspace.com] Sent: Wednesday, January 14, 2009 8:37 PM To: openvas-devel at wald.intevation.org; bchandra at secpod.com Subject: Re: [Openvas-commits] r2195 - trunk/openvas-plugins/scripts Are we keeping the "Windows : Microsoft Bulletins" family or has it been discontinued? Thomas scm-commit at wald.intevation.org wrote: > script_category(ACT_GATHER_INFO); > - script_family(english:"Windows : Microsoft Bulletins"); > + script_family(english:"Windows"); > script_name(english:"SMB Remote Code Execution Vulnerability (957095)"); From openvas-bugs at wald.intevation.org Wed Jan 14 15:01:54 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Wed, 14 Jan 2009 15:01:54 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B870=5D_Links_not_c?= =?utf-8?q?reated_on_install=2C_libraries_not_found_although_are_th?= =?utf-8?q?ere!=3F?= Message-ID: <20090114140154.DE58C40717@pyrosoma.intevation.org> Bugs item #870, was opened at 2009-01-14 14:01 Status: Open Priority: 3 Submitted By: Darren Fuller (fully) Assigned to: Nobody (None) Summary: Links not created on install, libraries not found although are there!? Resolution: None Severity: None Version: v2.0 Component: openvas-libraries Operating System: Linux Product: OpenVAS Hardware: Other URL: Initial Comment: Trying to get this working on Kubuntu 8.10, ran make/make install etc. as root but get the following error: root at netbox:/tmp# openvasd openvasd: error while loading shared libraries: libopenvas.2: cannot open shared object file: No such file or directory Looking in to /usr/local/lib showed that the links for libopenvas.2 were pointing to an old version so I removed/recreated to point to the file directly: root at netbox:/tmp# ls -l /usr/local/lib/libopenvas.2 lrwxrwxrwx 1 root root 34 2009-01-14 13:19 /usr/local/lib/libopenvas.2 -> /usr/local/lib/libopenvas.so.2.0.0 root at netbox:/tmp# ls -l /usr/local/lib/libopenvas.so.2.0.0 -rwxr-xr-x 1 root root 288285 2009-01-14 13:11 /usr/local/lib/libopenvas.so.2.0.0 So.. the library exists but isn't loaded? root at netbox:/tmp# cat /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf /usr/local/lib root at netbox:/tmp# ldd `which openvasd` linux-gate.so.1 => (0xb7f96000) libopenvasnasl.so.2 => /usr/local/lib/libopenvasnasl.so.2 (0xb7f2b000) libgpgme.so.11 => /usr/lib/libgpgme.so.11 (0xb7f01000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb7efc000) libopenvas.so.2 => /usr/local/lib/libopenvas.so.2 (0xb7e76000) libopenvas_hg.so.2 => /usr/local/lib/libopenvas_hg.so.2 (0xb7e6f000) libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7e6b000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7e52000) libpcap.so.0.8 => /usr/lib/libpcap.so.0.8 (0xb7e27000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb7d89000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7d75000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7d71000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7cba000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b5c000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb7af2000) libopenvas.2 => not found libopenvas_hg.2 => not found libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7ae0000) libz.so.1 => /usr/lib/libz.so.1 (0xb7aca000) /lib/ld-linux.so.2 (0xb7f7c000) libpcre.so.3 => /lib/libpcre.so.3 (0xb7aa0000) Let me know if you need any further info. Fully ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=870&group_id=29 From openvas-bugs at wald.intevation.org Thu Jan 15 04:02:56 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 15 Jan 2009 04:02:56 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B871=5D_False_posit?= =?utf-8?q?ives_in_OpenVAS_with_relation_to_SMB=2C_ssh_and_HTTP_ser?= =?utf-8?q?vices?= Message-ID: <20090115030256.2D9EC40729@pyrosoma.intevation.org> Bugs item #871, was opened at 2009-01-15 11:02 Status: Open Priority: 3 Submitted By: Pavan Tekur (atbash) Assigned to: Nobody (None) Summary: False positives in OpenVAS with relation to SMB, ssh and HTTP services Resolution: None Severity: normal Version: v2.0 Component: None Operating System: Linux Product: OpenVAS Hardware: HP URL: Initial Comment: I just completed openVAS scans on 3 large network ranges. There are some specific concerns I would like to hightlight in making the report easier to analyse. For all the IPs in the network range OpenVAS returns the following port results, SMB: All of them have failed the test. This is documented in the report SSH: All except the real ssh ports have failed the test but still listed in the report HTTP: All except the real web services have failed but is still listed as empty nikto scan. It would be great if we can remove these false positives or excessive information making analysis of results faster and more effective. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=871&group_id=29 From hans.ullrich at loop.de Thu Jan 15 11:41:03 2009 From: hans.ullrich at loop.de (Hans-J. Ullrich) Date: Thu, 15 Jan 2009 11:41:03 +0100 Subject: [Openvas-devel] Just a simple question Message-ID: <200901151141.03579.hans.ullrich@loop.de> Dear developers, first of all: thank you for openvas! Thank you for GPL in openvas! I just have a simple question: I miss the option, to list all existing users added with openvas-adduser. Did I miss a command or a file? I searched everything, but I could not find it. Nor any file, where the added users are named. It would be nice, if you could add such a feature in your next version. Just in case, if I forgot about my added users during some weeks..... Thank you very much for your help and your work! Kind regards Hans-J. Ullrich From jan-oliver.wagner at intevation.de Fri Jan 16 00:22:52 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 16 Jan 2009 00:22:52 +0100 Subject: [Openvas-devel] Just a simple question In-Reply-To: <200901151141.03579.hans.ullrich@loop.de> References: <200901151141.03579.hans.ullrich@loop.de> Message-ID: <200901160022.53326.jan-oliver.wagner@intevation.de> On Thursday 15 January 2009 11:41:03 Hans-J. Ullrich wrote: > I just have a simple question: > > I miss the option, to list all existing users added with openvas-adduser. > Did I miss a command or a file? I searched everything, but I could not find > it. Nor any file, where the added users are named. > > It would be nice, if you could add such a feature in your next version. > Just in case, if I forgot about my added users during some weeks..... hm, the most simple command that comes to my mind is: $ ls /var/lib/openvas/users/ :-) Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Fri Jan 16 13:07:02 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 16 Jan 2009 13:07:02 +0100 Subject: [Openvas-devel] Updated CR#25 on WMI Message-ID: <200901161307.11338.jan-oliver.wagner@intevation.de> Hi, Chandra updated CR#25 into direction of WMI support: http://www.openvas.org/openvas-cr-25.html IMHO it is almost ready for voting. Chandra: the sample code shows no return of results? I move my mind about daemon approach: Perhaps it is easier to have a wrapper library for wmi-calls and have a "wmi_init();" mandatory. This init function will lower privileges of the current process. IMHO this would simply the solution a lot while taking care no additional security problems are introduced. Am I right with miy thougths? Does this idea make sense? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Fri Jan 16 15:14:18 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 16 Jan 2009 19:44:18 +0530 Subject: [Openvas-devel] Updated CR#25 on WMI In-Reply-To: <200901161307.11338.jan-oliver.wagner@intevation.de> References: <200901161307.11338.jan-oliver.wagner@intevation.de> Message-ID: <55745107C7C24D749350D3F50E9580E3@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: Friday, January 16, 2009 5:37 PM To: openvas-devel at wald.intevation.org Subject: [Openvas-devel] Updated CR#25 on WMI > Hi, > Chandra updated CR#25 into direction of WMI support: > http://www.openvas.org/openvas-cr-25.html > IMHO it is almost ready for voting. > Chandra: the sample code shows no return of results? Updated with example response > I move my mind about daemon approach: Perhaps it is easier > to have a wrapper library for wmi-calls and have a "wmi_init();" > mandatory. This init function will lower privileges of the current > process. > IMHO this would simply the solution a lot while taking care no additional > security problems are introduced. > Am I right with miy thougths? Does this idea make sense? Yes, this can be done too. Thanks, Chandra. From bh at intevation.de Fri Jan 16 20:42:01 2009 From: bh at intevation.de (Bernhard Herzog) Date: Fri, 16 Jan 2009 20:42:01 +0100 Subject: [Openvas-devel] [Openvas-commits] r2172 - in trunk/openvas-client: . src/util In-Reply-To: <20090109101057.06C0E4073E@pyrosoma.intevation.org> References: <20090109101057.06C0E4073E@pyrosoma.intevation.org> Message-ID: <200901162042.03970.bh@intevation.de> On 09.01.2009, scm-commit at wald.intevation.org wrote: > Modified: > trunk/openvas-client/ChangeLog > trunk/openvas-client/src/util/g_hash_table_file.c > trunk/openvas-client/src/util/g_hash_table_file.h > Log: > * src/util/g_hash_table_file.c (g_hash_table_read): renamed to > g_hash_table_file_read. We should avoid function names and other identifiers that use prefixes of libraries we use. In this particular case, g_hash_table_file_read looks like a name that glib might actually define at some point in the future and then we will run into linking problems. Also, when someone see g_hash_table_file_read in the openvas code they will assume that this function comes from glib and wonder why they can't find it there. All functions and other identifiers defined by OpenVAS that are not limited to a single file should have prefixes that clearly identify them as parts of OpenVAS. Bernhard -- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090116/5fc707b7/attachment.pgp From matt at mundell.ukfsn.org Fri Jan 16 20:54:04 2009 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 16 Jan 2009 19:54:04 GMT Subject: [Openvas-devel] File naming Message-ID: <20090116195402.84106DEEB8@mail.ukfsn.org> C files are usually named with underscores. openvas-manager/ovas-mngr-comm.h openvas-manager/ovas-mngr-comm.c Is there a reason you've used dashes in these two? From matt at mundell.ukfsn.org Fri Jan 16 21:39:24 2009 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 16 Jan 2009 20:39:24 GMT Subject: [Openvas-devel] XML OMP Questions Message-ID: <20090116203922.51DFADEEA0@mail.ukfsn.org> 1) Are the XML entities ordered. That is, does asdf3235saf3kjBVF... Scan Webserver Hourly scan of the webserver mean that must come before ? 2) In modify_task, can there be more than one parameter value pair? For example 254cd3ef-bbe1-4d58-859d-21b8d0c046c6 task_file HAFawrAsfdgJFGE374... comment New comment. 3) Should the new_task "task_file" element be named just "file", for consistency? Or perhaps, should "identifier" and "comment" be "task_identifier" and "task_comment", to match "task_file"? Similarly, should the "task_id" elements be named just "id"? 4) People might take the new_task "identifier" element to be for a task id. Perhaps it should be called "name" instead? 5) Are the responses to start_task garaunteed to come back in the order they were given? If so, is this going to hinder running OMP over certain protocols like HTTP, where (I think) one response could beat an earlier response back to the client? Perhaps start_task_response should have an id field? From jan-oliver.wagner at intevation.de Sat Jan 17 21:14:46 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sat, 17 Jan 2009 21:14:46 +0100 Subject: [Openvas-devel] File naming In-Reply-To: <20090116195402.84106DEEB8@mail.ukfsn.org> References: <20090116195402.84106DEEB8@mail.ukfsn.org> Message-ID: <200901172114.47039.jan-oliver.wagner@intevation.de> On Friday 16 January 2009 20:54:04 Matthew Mundell wrote: > C files are usually named with underscores. > > openvas-manager/ovas-mngr-comm.h > openvas-manager/ovas-mngr-comm.c > > Is there a reason you've used dashes in these two? actually it is not unusual to use dashes. I've seen this use in many C projects for years now. Does there exist a style guide that recommends not to use dashes for such filenames? I thought the underscores are especially used for function and variable names in C. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Sat Jan 17 21:32:02 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sat, 17 Jan 2009 21:32:02 +0100 Subject: [Openvas-devel] XML OMP Questions In-Reply-To: <20090116203922.51DFADEEA0@mail.ukfsn.org> References: <20090116203922.51DFADEEA0@mail.ukfsn.org> Message-ID: <200901172132.02773.jan-oliver.wagner@intevation.de> On Friday 16 January 2009 21:39:24 Matthew Mundell wrote: > 1) Are the XML entities ordered. That is, does > > > asdf3235saf3kjBVF... > Scan Webserver > Hourly scan of the webserver > > > mean that must come before ? I guess that the sequence is not mandatory. > 2) In modify_task, can there be more than one parameter value pair? For > example > > > 254cd3ef-bbe1-4d58-859d-21b8d0c046c6 > task_file > HAFawrAsfdgJFGE374... > comment > New comment. > this is no good XML style. Probably it is a good idea to allow for more than one parameter to update within one modify_task (Michael: or did you have something special in mind with this). I would choose a format like this: New Comment Or ways are possible as well. > 3) Should the new_task "task_file" element be named just "file", for > consistency? Or perhaps, should "identifier" and "comment" be > "task_identifier" and "task_comment", to match "task_file"? > > Similarly, should the "task_id" elements be named just "id"? hm, in case the node appear anywhere in the very same format, this might be an option. > 4) People might take the new_task "identifier" element to be for a task id. > Perhaps it should be called "name" instead? Michael? > 5) Are the responses to start_task garaunteed to come back in the order > they were given? If so, is this going to hinder running OMP over certain > protocols like HTTP, where (I think) one response could beat an earlier > response back to the client? > > Perhaps start_task_response should have an id field? Michael? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From matt at mundell.ukfsn.org Sun Jan 18 16:37:44 2009 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 18 Jan 2009 15:37:44 GMT Subject: [Openvas-devel] File naming In-Reply-To: Message of Sat, 17 Jan 2009 21:14:46 +0100. <200901172114.47039.jan-oliver.wagner@intevation.de> Message-ID: <20090118153741.CE1A7DEBDE@mail.ukfsn.org> > > C files are usually named with underscores. > > > > openvas-manager/ovas-mngr-comm.h > > openvas-manager/ovas-mngr-comm.c > > > > Is there a reason you've used dashes in these two? > > actually it is not unusual to use dashes. I've seen this use > in many C projects for years now. OK. I'm pretty sure I've predominately seen underscores. > Does there exist a style guide that recommends not to use > dashes for such filenames? It's more for consistency. I've already started naming the tests in that module with underscores. A quick look at the other modules made me think that all the OpenVAS C source used underscores. Now I've looked again and see files like openvas-server/ssl/openvas-mkrand.c. I guess more OpenVAS files are named with underscores though. I propose that one style is chosen for all new files names. The GNU standard doc, 5.4 Naming Variables, Functions, and Files, suggests underscores for variable and function names, but just mentions the length of file names. > I thought the underscores are especially used for function and > variable names in C. Yes, I think that's because a dash is taken as a minus in some contexts. From joey at infodrom.org Sun Jan 18 19:03:15 2009 From: joey at infodrom.org (Joey Schulze) Date: Sun, 18 Jan 2009 19:03:15 +0100 Subject: [Openvas-devel] OpenVAS-client Usability Improvements In-Reply-To: <20081219141348.GF16832@intevation.de> References: <20081219104056.GB25418@finlandia.home.infodrom.org> <20081219141348.GF16832@intevation.de> Message-ID: <20090118180315.GC27491@finlandia.home.infodrom.org> Michael Wiegand wrote: > > another issue that I notice frequently when I want to read a report in > > the Client is that I have to click on each and every port and priority > > to have the associated output displayed. > > > > It would be nice if there would be an "expand all" and "collapse all" > > button in the right report TreeView. > > Sounds useful to me. You seem to have a lot of good ideas for the client > GUI, it might be a good idea to collect them in a change request so they > don't get buried in the mailing list. What do you think? Please go ahead. I have no idea where to collect such ideas best. Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier From michael.wiegand at intevation.de Mon Jan 19 09:15:50 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 19 Jan 2009 09:15:50 +0100 Subject: [Openvas-devel] XML OMP Questions In-Reply-To: <200901172132.02773.jan-oliver.wagner@intevation.de> References: <20090116203922.51DFADEEA0@mail.ukfsn.org> <200901172132.02773.jan-oliver.wagner@intevation.de> Message-ID: <20090119081550.GB17972@intevation.de> * Jan-Oliver Wagner [17. Jan 2009]: > On Friday 16 January 2009 21:39:24 Matthew Mundell wrote: > > 1) Are the XML entities ordered. That is, does > > > > > > asdf3235saf3kjBVF... > > Scan Webserver > > Hourly scan of the webserver > > > > > > mean that must come before ? > I guess that the sequence is not mandatory. No, it is not. > > 2) In modify_task, can there be more than one parameter value pair? For > > example > > > > > > 254cd3ef-bbe1-4d58-859d-21b8d0c046c6 > > task_file > > HAFawrAsfdgJFGE374... > > comment > > New comment. > > > > this is no good XML style. > > Probably it is a good idea to allow for more than one parameter to > update within one modify_task (Michael: or did you have something special > in mind with this). Agreed. I think this is just a bad example, not sure what I was thinking. ;) > I would choose a format like this: > New Comment > Or ways are possible as well. Yes, something like that. I'll look into that and update the specs accordingly. > > 3) Should the new_task "task_file" element be named just "file", for > > consistency? Or perhaps, should "identifier" and "comment" be > > "task_identifier" and "task_comment", to match "task_file"? > > > > Similarly, should the "task_id" elements be named just "id"? > > hm, in case the node appear anywhere in the very same format, > this might be an option. Yes, I think the spec for new_task might need a few changes. The settings may come as an openvasrc file for now, but over time a change to something more XMLified might happen. The spec should anticipate that. I'll revise the syntax for new_task and update the specs accordingly. > > 4) People might take the new_task "identifier" element to be for a task id. > > Perhaps it should be called "name" instead? Good idea. See 3. > > 5) Are the responses to start_task garaunteed to come back in the order > > they were given? If so, is this going to hinder running OMP over certain > > protocols like HTTP, where (I think) one response could beat an earlier > > response back to the client? > > > > Perhaps start_task_response should have an id field? Indeed. Responses should be more verbose and should say which task/report they are referring to. Thank you for you suggestion, I'll work them into the specs. Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Mon Jan 19 09:23:20 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 19 Jan 2009 09:23:20 +0100 Subject: [Openvas-devel] [Openvas-commits] r2172 - in trunk/openvas-client: . src/util In-Reply-To: <200901162042.03970.bh@intevation.de> References: <20090109101057.06C0E4073E@pyrosoma.intevation.org> <200901162042.03970.bh@intevation.de> Message-ID: <200901190923.20870.felix.wolfsteller@intevation.de> You are absolutely right, Bernhard. It bugs me is that I was actually thinking about it and did not want to name it that way but apparently did so. Seems that there was a devil riding me. Michael suggest it was an out-of-coffee error. Fixed in rev 2275. Thanks for spotting it. felix > > * src/util/g_hash_table_file.c (g_hash_table_read): renamed to > > g_hash_table_file_read. > > We should avoid function names and other identifiers that use prefixes of > libraries we use. In this particular case, g_hash_table_file_read looks > like a name that glib might actually define at some point in the future and > then we will run into linking problems. Also, when someone see > g_hash_table_file_read in the openvas code they will assume that this > function comes from glib and wonder why they can't find it there. > Bernhard -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Mon Jan 19 09:51:34 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 19 Jan 2009 09:51:34 +0100 Subject: [Openvas-devel] [Openvas-commits] r2251 - in trunk/openvas-client: . nessus nessus/prefs_dialog In-Reply-To: <20090117194035.CD61C40743@pyrosoma.intevation.org> References: <20090117194035.CD61C40743@pyrosoma.intevation.org> Message-ID: <200901190951.34669.felix.wolfsteller@intevation.de> Does not compile (trunk/openvas-client/nessus/html_graph_output.c: host_details). 1) false_positives is later referenced as false_positive. 2) some functions that were moved (not exactly, as they were duplicates) are not referenced correctly, are in 'html_output_' now. The appended patch makes building possible, but I have not put any thought into or checked it. --felix On Saturday 17 January 2009 20:40:35 scm-commit at wald.intevation.org wrote: > Author: joeyschulze > Date: 2009-01-17 20:40:33 +0100 (Sat, 17 Jan 2009) > New Revision: 2251 > Modified: trunk/openvas-client/nessus/html_graph_output.c > =================================================================== > --- trunk/openvas-client/nessus/html_graph_output.c 2009-01-17 15:13:00 UTC > (rev 2250) +++ trunk/openvas-client/nessus/html_graph_output.c 2009-01-17 > + struct arglist * false_positives; > port = ports->name; > report = arg_get_value(ports->value, "REPORT"); > if(report)while(report && report->next) > @@ -659,6 +662,35 @@ > } > note = note->next; > } > + false_positive = arg_get_value(ports->value, "FALSE"); > + if(false_positive)while(false_positive && false_positive->next) > + { > + if(!report){ > + char * name = portname_to_ahref(ports->name, hostname); > + fprintf(file, "",name); > + efree(&name); > + } > + if(strlen(false_positive->value)) > + { > + char * name; > + desc = emalloc(strlen(false_positive->value)+1); > + strncpy(desc, false_positive->value, strlen(false_positive->value)); > + /* > + * Convert the \n to

> + */ > + desc = convert_cr_to_html(false_positive->value); > + name = portname_to_ahref("toc", hostname); > + fprintf(file, "

\n", > + name); > + fprintf(file, "False positive found on port %s

    \n", > port); + efree(&name); > + print_data_with_links(file, desc, false_positive->name); > + fprintf(file, "

\n"); > + efree(&desc); > + } > + false_positive = false_positive->next; > + } > -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: html_graph_output.patch Type: text/x-diff Size: 2001 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090119/37b492d3/html_graph_output.bin From felix.wolfsteller at intevation.de Mon Jan 19 10:34:24 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 19 Jan 2009 10:34:24 +0100 Subject: [Openvas-devel] XML OMP Questions 2 Message-ID: <200901191034.24401.felix.wolfsteller@intevation.de> 1) I miss the point where plugin preferences are sent to the client (I guess it is get_nvt_details_all / get_nvt_details?). 2) Could not get_nvt_details_all and get_nvt_details_oid be merged? would become something like all to keep it simple. The response looks pretty much the same, anyway. 3) The same element might be used by the server to indicate if there are problems with an nvt (unsigned/ missing deps etc.). Currently there is no channel for this kind of information. 200 ... No ... (I know 'executable' is not a good name). 4) About the TODO point (TODO: Are protocol command desirable to request details for specific groups of NVTs (e.g. GET_NVT_DETAILS_FAMILY)? Or should this kind of filtering happen in the client?): If one wants to have that, a intuitive way would be to allow all fields that are possible in the corresponding response: 1.3.6.1.4.1.25623.* CVE-2008* *local* where fields are automatically AND- connected. --felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From joey at infodrom.org Mon Jan 19 10:52:51 2009 From: joey at infodrom.org (Joey Schulze) Date: Mon, 19 Jan 2009 10:52:51 +0100 Subject: [Openvas-devel] [Openvas-commits] r2251 - in trunk/openvas-client: . nessus nessus/prefs_dialog In-Reply-To: <200901190951.34669.felix.wolfsteller@intevation.de> References: <20090117194035.CD61C40743@pyrosoma.intevation.org> <200901190951.34669.felix.wolfsteller@intevation.de> Message-ID: <20090119095251.GA29960@finlandia.home.infodrom.org> Felix Wolfsteller wrote: > Does not compile (trunk/openvas-client/nessus/html_graph_output.c: > host_details). > 1) false_positives is later referenced as false_positive. Oh! How could that happen? It compiled here. I'll fix this today. Regards, Joey -- Reading is a lost art nowadays. -- Michael Weber From michael.wiegand at intevation.de Mon Jan 19 14:17:48 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 19 Jan 2009 14:17:48 +0100 Subject: [Openvas-devel] XML OMP Questions 2 In-Reply-To: <200901191034.24401.felix.wolfsteller@intevation.de> References: <200901191034.24401.felix.wolfsteller@intevation.de> Message-ID: <20090119131748.GC17972@intevation.de> * Felix Wolfsteller [19. Jan 2009]: > 1) I miss the point where plugin preferences are sent to the client (I guess > it is get_nvt_details_all / get_nvt_details?). This not yet considered, good point. > 2) Could not get_nvt_details_all and get_nvt_details_oid be merged? > > would become something like > > all > > to keep it simple. The response looks pretty much the same, anyway. Yes, this could indeed be simplified, I will look into that. But this topic leads us to a design decision we need to make. Do we want to keep the manager and thus the protocol as lean and as small as possible and leave more complicated tasks to the client? Or do we want the manager and the protocol to offer a lot of functionality, so we can keep the client as small as possible? This is a decision we need to agree upon before we finalize the OMP specs and of course before Matthew finishes the implementation. If we want a small manager, I would suggest we only allow a command to retrieve details for all NVTs and leave the sorting and complex selections to the client. OTOH, if we want small clients (which might be useful for example for a web client), we should move filtering and selecting to the manager and consider this in the protocol. This will of course add a certain amount of overhead for this functionality to the manager. Opinions? > 3) The same element might be used by the server to indicate if there are > problems with an nvt (unsigned/ missing deps etc.). Currently there is no > channel for this kind of information. > > 200 > > ... > No > ... > > > (I know 'executable' is not a good name). Yes. The example is not meant to contain all desired fields. Additional useful information can certainly be added; we should discuss which fields would be useful. Keep in mind that the manager will still need to retrieve the information from the server via OTP, so we cannot include information the server does not transmit via OTP. > 4) About the TODO point (TODO: Are protocol command desirable to request > details for specific groups of NVTs (e.g. GET_NVT_DETAILS_FAMILY)? Or should > this kind of filtering happen in the client?): > If one wants to have that, a intuitive way would be to allow all fields that > are possible in the corresponding response: > > 1.3.6.1.4.1.25623.* > CVE-2008* > *local* > > > where fields are automatically AND- connected. See my response to 2); this touches the same design decision. I think it would be a good thing if we could agree on a design soon so we don't block Matthews implementation. I'm looking forward to your opinions! Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Mon Jan 19 15:18:38 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 19 Jan 2009 15:18:38 +0100 Subject: [Openvas-devel] =?iso-8859-1?q?=5BOpenvas-commits=5D_r2251_-_in_t?= =?iso-8859-1?q?runk/openvas-client=3A_=2E_nessus=09nessus/prefs=5F?= =?iso-8859-1?q?dialog?= In-Reply-To: <20090119095251.GA29960@finlandia.home.infodrom.org> References: <20090117194035.CD61C40743@pyrosoma.intevation.org> <200901190951.34669.felix.wolfsteller@intevation.de> <20090119095251.GA29960@finlandia.home.infodrom.org> Message-ID: <200901191518.41096.jan-oliver.wagner@intevation.de> On Montag, 19. Januar 2009, Joey Schulze wrote: > Felix Wolfsteller wrote: > > Does not compile (trunk/openvas-client/nessus/html_graph_output.c: > > host_details). > > 1) false_positives is later referenced as false_positive. > > Oh! How could that happen? > It compiled here. probably because you are not configuring with libgdc. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Mon Jan 19 15:23:36 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 19 Jan 2009 15:23:36 +0100 Subject: [Openvas-devel] XML OMP Questions 2 In-Reply-To: <20090119131748.GC17972@intevation.de> References: <200901191034.24401.felix.wolfsteller@intevation.de> <20090119131748.GC17972@intevation.de> Message-ID: <200901191523.38592.jan-oliver.wagner@intevation.de> On Montag, 19. Januar 2009, Michael Wiegand wrote: > But this topic leads us to a design decision we need to make. Do we want > to keep the manager and thus the protocol as lean and as small as > possible and leave more complicated tasks to the client? > > Or do we want the manager and the protocol to offer a lot of > functionality, so we can keep the client as small as possible? > > This is a decision we need to agree upon before we finalize the OMP > specs and of course before Matthew finishes the implementation. > > If we want a small manager, I would suggest we only allow a command to > retrieve details for all NVTs and leave the sorting and complex > selections to the client. > > OTOH, if we want small clients (which might be useful for example for a > web client), we should move filtering and selecting to the manager and > consider this in the protocol. This will of course add a certain amount > of overhead for this functionality to the manager. First target should be to integrate support for OMP into OpenVAS-Client. This one is already clever, so so smaller openvas-manager is sufficient. For a web client we should follow the principle that it should not be avoided to store anything on the web-server side, i.e. only in-memory stuff. At least as far as possible. Maybe OMP 2.0 will allow for more openvas-manager cleverness. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From joey at infodrom.org Mon Jan 19 16:32:13 2009 From: joey at infodrom.org (Joey Schulze) Date: Mon, 19 Jan 2009 16:32:13 +0100 Subject: [Openvas-devel] [Openvas-commits] r2251 - in trunk/openvas-client: . nessus nessus/prefs_dialog In-Reply-To: <200901190951.34669.felix.wolfsteller@intevation.de> References: <20090117194035.CD61C40743@pyrosoma.intevation.org> <200901190951.34669.felix.wolfsteller@intevation.de> Message-ID: <20090119153213.GD29960@finlandia.home.infodrom.org> Felix Wolfsteller wrote: > Does not compile (trunk/openvas-client/nessus/html_graph_output.c: > host_details). Thanks for the notes. > 1) false_positives is later referenced as false_positive. That code was not compiled on my system (NO_GDCHART defined). It should compile again. > 2) some functions that were moved (not exactly, as they were duplicates) are > not referenced correctly, are in 'html_output_' now. Could you be more verbose? I don't seem to be able to understand what you tried to tell me. I'm sorry. > The appended patch makes building possible, but I have not put any thought > into or checked it. That does it. Applied. Regards, Joey -- Reading is a lost art nowadays. -- Michael Weber From felix.wolfsteller at intevation.de Tue Jan 20 08:41:22 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 20 Jan 2009 08:41:22 +0100 Subject: [Openvas-devel] =?iso-8859-1?q?=5BOpenvas-commits=5D_r2251_-_in_t?= =?iso-8859-1?q?runk/openvas-client=3A_=2E_nessus=09nessus/prefs=5F?= =?iso-8859-1?q?dialog?= In-Reply-To: <20090119153213.GD29960@finlandia.home.infodrom.org> References: <20090117194035.CD61C40743@pyrosoma.intevation.org> <200901190951.34669.felix.wolfsteller@intevation.de> <20090119153213.GD29960@finlandia.home.infodrom.org> Message-ID: <200901200841.22783.felix.wolfsteller@intevation.de> > > 2) some functions that were moved (not exactly, as they were duplicates) > > are not referenced correctly, are in 'html_output_' now. > > Could you be more verbose? I don't seem to be able to understand what you > tried to tell me. I'm sorry. Well, _I_ am sorry, In more detail: Pre-Revision ~1874 the modules that dealt with html output in one or another form (html_output.c , latex_output.c, html_graph_output.c) all contained code duplicates of functions like cr_to_href, print_data_with_links, portname_to_href etc etc. I removed the duplicates in favor of bundling this functionality in html_output.c . The former static portname_to_href in html_graph_output.c is gone, same functionality is now made available through html_output_portname_to_href in html_output.c/h. Compilation of html_graph_output.c fails because it still references the functions that were "moved". The original patch that I sent fixes that (prepending html_output_ to the functions in question), but again, i did not verify the output. Hope that is more clear. --felix On Monday 19 January 2009 16:32:13 Joey Schulze wrote: > Felix Wolfsteller wrote: > > Does not compile (trunk/openvas-client/nessus/html_graph_output.c: > > host_details). > > Thanks for the notes. > > > 1) false_positives is later referenced as false_positive. > > That code was not compiled on my system (NO_GDCHART defined). > > It should compile again. > > > 2) some functions that were moved (not exactly, as they were duplicates) > > are not referenced correctly, are in 'html_output_' now. > > Could you be more verbose? I don't seem to be able to understand what you > tried to tell me. I'm sorry. > > > The appended patch makes building possible, but I have not put any > > thought into or checked it. > > That does it. Applied. > > Regards, > > Joey -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From joey at infodrom.org Tue Jan 20 09:48:05 2009 From: joey at infodrom.org (Joey Schulze) Date: Tue, 20 Jan 2009 09:48:05 +0100 Subject: [Openvas-devel] [Openvas-commits] r2251 - in trunk/openvas-client: . nessus?nessus/prefs_dialog In-Reply-To: <200901200841.22783.felix.wolfsteller@intevation.de> References: <20090117194035.CD61C40743@pyrosoma.intevation.org> <200901190951.34669.felix.wolfsteller@intevation.de> <20090119153213.GD29960@finlandia.home.infodrom.org> <200901200841.22783.felix.wolfsteller@intevation.de> Message-ID: <20090120084805.GL29960@finlandia.home.infodrom.org> Felix Wolfsteller wrote: > > > 2) some functions that were moved (not exactly, as they were duplicates) > > > are not referenced correctly, are in 'html_output_' now. > > > > Could you be more verbose? I don't seem to be able to understand what you > > tried to tell me. I'm sorry. > Well, _I_ am sorry, > In more detail: > Pre-Revision ~1874 the modules that dealt with html output in one or another > form (html_output.c , latex_output.c, html_graph_output.c) all contained code > duplicates of functions like cr_to_href, print_data_with_links, > portname_to_href etc etc. Ok, now I understand. > I removed the duplicates in favor of bundling this functionality in > html_output.c . The former static portname_to_href in html_graph_output.c is > gone, same functionality is now made available through > html_output_portname_to_href in html_output.c/h. Good idea! > The original patch that I sent fixes that (prepending html_output_ to the > functions in question), but again, i did not verify the output. Fixed. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book From jan-oliver.wagner at intevation.de Wed Jan 21 01:00:05 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 21 Jan 2009 01:00:05 +0100 Subject: [Openvas-devel] Changes to cache file handling In-Reply-To: <4d7b043c0901100129l1a4f24e9nbd6df3be45edb7b4@mail.gmail.com> References: <200901040152.32235.jan-oliver.wagner@intevation.de> <200901092323.29863.jan-oliver.wagner@intevation.de> <4d7b043c0901100129l1a4f24e9nbd6df3be45edb7b4@mail.gmail.com> Message-ID: <200901210100.05854.jan-oliver.wagner@intevation.de> On Saturday 10 January 2009 10:29:57 Stjepan Gros wrote: > I just saw that you depricated store_init_{user,sys} which is good. > This functions confused me as I didn't know what is their purpose. > Anyway, I'm not very fond of global variables, and IMHO, I would > remove them, but there could be advantages to their use. So, I'll > leave this decision to you. well, its only gobal for this module. I am not a big fan of such either. > And while I'm at deprecated functions that can not be removed until > next major release it could be good to mark them as deprecated so that > people know that and also, when the time comes for removal, that they > are not forgotten. There is an attribute supported by gcc, > __attribute__ ((__deprecated__)), that can be added to the deprecated > functions so that compiler clearly warns about those functions when > they are used. I applied this now. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Fri Jan 23 09:11:14 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 23 Jan 2009 09:11:14 +0100 Subject: [Openvas-devel] subdirs / cache_folder Message-ID: <200901230911.16090.jan-oliver.wagner@intevation.de> Hi, derived from Stjepans patch for http://www.openvas.org/openvas-cr-24.html I comitted the feature of "cache_folder", i.e. to habe cache data written to /var/cache/openvas/ instead brain-dead into /lib/openvas/plugins. As usual, some cleanup work was done along the actual change. Next step is to work on the actual subdirs feature. Stjepan: your patch should have shrinked a lot now. Have you had time to sync with my changes (sorry, not straightly possible as I needed to adapt your changes)? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Fri Jan 23 15:54:39 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 23 Jan 2009 15:54:39 +0100 Subject: [Openvas-devel] OpenVAS SSH Keymanager issues Message-ID: <200901231554.41653.jan-oliver.wagner@intevation.de> Hi, I realized a couple of issues with the ssh keymanager: * after creating a key: $ ls -l ~/.openvas/.ssh/ -rw-rw-r-- 1 jan greenbone 1821 2009-01-23 15:30 ovaslsc.p8 -rw------- 1 jan greenbone 1743 2009-01-23 15:30 ovaslsc.pub -rw-r--r-- 1 jan greenbone 386 2009-01-23 15:30 ovaslsc.pub.pub the .pub is a private and the .pub.pub is the public key. * Removing the key files will not be noticed by the manager. It is even impossible to remove the entry in the GUI. Shouldn't there be a remove option? * It would be good if the keymanager would stat the files and warn the user if they are not found, offering to either delete the entry or specify a new file. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Sun Jan 25 16:44:06 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Sun, 25 Jan 2009 16:44:06 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B883=5D_getting_the?= =?utf-8?q?_error=3A_Empty_data_string_--_closing_comm=2E_channel?= =?utf-8?q?=2C_when_executing_a_scope?= Message-ID: <20090125154406.3094F406E7@pyrosoma.intevation.org> Bugs item #883, was opened at 2009-01-25 17:44 Status: Open Priority: 3 Submitted By: Najib Abi Fadel (najib) Assigned to: Nobody (None) Summary: getting the error: Empty data string -- closing comm. channel, when executing a scope Resolution: None Severity: major Version: v2.0 Component: openvas-client Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: I have installed OpenVas 2 source packages (server and client) on Debian 4.0 sarge. I added the plugins to the server and launched it. I started the client and executed a scope. I am getting the following messages in the server log: [Sun Jan 25 17:06:29 2009][32665] openvasd 2.0.0. started [Sun Jan 25 17:17:24 2009][32665] connection from 127.0.0.1 [Sun Jan 25 17:17:24 2009][8454] Client requested protocol < OTP/1.0 > . [Sun Jan 25 17:17:25 2009][8454] successful login of najib from 127.0.0.1 [Sun Jan 25 17:19:50 2009][8454] Empty data string -- closing comm. channel The client is loading the plugins from the server and connecting to the server sucessfully. However when running a scope the progression window is not appearing and i am getting empty reports. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=883&group_id=29 From felix.wolfsteller at intevation.de Mon Jan 26 09:28:37 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 26 Jan 2009 09:28:37 +0100 Subject: [Openvas-devel] OpenVAS SSH Keymanager issues In-Reply-To: <200901231554.41653.jan-oliver.wagner@intevation.de> References: <200901231554.41653.jan-oliver.wagner@intevation.de> Message-ID: <200901260928.38081.felix.wolfsteller@intevation.de> On Friday 23 January 2009 15:54:39 Jan-Oliver Wagner wrote: > * after creating a key: > $ ls -l ~/.openvas/.ssh/ > -rw-rw-r-- 1 jan greenbone 1821 2009-01-23 15:30 ovaslsc.p8 > -rw------- 1 jan greenbone 1743 2009-01-23 15:30 ovaslsc.pub > -rw-r--r-- 1 jan greenbone 386 2009-01-23 15:30 ovaslsc.pub.pub > > the .pub is a private and the .pub.pub is the public key. Fixed in (latest) Rev. 2321. > * Removing the key files will not be noticed by the manager. > It is even impossible to remove the entry in the GUI. > Shouldn't there be a remove option? > * It would be good if the keymanager would stat the files and > warn the user if they are not found, offering to either delete the > entry or specify a new file. At the moment removing a .pub or .p8 file should let the key dissappear from the list and delete all information about it in .openvas/.ssh/.logins. I agree that this is neither transparent nor handy. However, I wanted .openvas/.ssh/* to be consistent and ideally all keys being created by the manager only. That means, I would not like to allow selection of files. Rather, in the case of a missing file I would prefer the options [delete|create_new]. Special wishes for debugging or migration can still be fulfilled, but mean fiddling with the (utterly simple) .openvas/.ssh/.logins file before starting the client. In a resume and ordered by priority: * we want a delete button for the logins. * in case of missing files for a login the user should be warned and given options to fix the problem. -- 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 openvas-bugs at wald.intevation.org Mon Jan 26 12:57:51 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Mon, 26 Jan 2009 12:57:51 +0100 (CET) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B884=5D_Can=27t_lau?= =?utf-8?q?nch_openVAS_client_after_fresh_install?= Message-ID: <20090126115751.DBB2C406C8@pyrosoma.intevation.org> Bugs item #884, was opened at 2009-01-26 11:57 Status: Open Priority: 3 Submitted By: Baronne Mouton (baronne) Assigned to: Nobody (None) Summary: Can't launch openVAS client after fresh install Resolution: Accepted As Bug Severity: normal Version: v2.0 Component: openvas-client Operating System: Windows XP Product: OpenVAS Hardware: PC URL: Initial Comment: Hi, I have followed the install and have a fresh install of openvas 2.0 - I am trying to connect to the openvas server using the windows client v1.0.3 and get the following error: Remote host is not using the good version of the Nessus communication protocol (1.2) or is tcpwrapped Any ideas? cheers, Baronne Mouton ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=884&group_id=29 From chriswoodut at gmail.com Wed Jan 28 17:37:55 2009 From: chriswoodut at gmail.com (Chris Wood) Date: Wed, 28 Jan 2009 09:37:55 -0700 Subject: [Openvas-devel] Cygwin x11 forwarding, error? Message-ID: I've setup OpenVas 2.0 on Debian etch. Because there isn't a windows client for 2.0 yet, I'm trying to use cygwin with x11 forwarding to run the scanner from my laptop. (My server is in a closet and doesn't have a monitor, so running locally on the server would be a pain.) When I start OpenVas-Client, it starts up just fine. As soon as I hover my mouse cursor over one of the buttons on the toolbar, the program crashes with the error below. Any suggestions? ---------- svr:~# /usr/local/bin/OpenVAS-Client The program 'OpenVAS-Client' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 3936 error_code 3 request_code 38 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090128/e3919f19/attachment.htm From jan-oliver.wagner at intevation.de Thu Jan 29 09:31:35 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 29 Jan 2009 09:31:35 +0100 Subject: [Openvas-devel] Cygwin x11 forwarding, error? In-Reply-To: References: Message-ID: <200901290932.54813.jan-oliver.wagner@intevation.de> On Mittwoch, 28. Januar 2009, Chris Wood wrote: > I've setup OpenVas 2.0 on Debian etch. Because there isn't a windows client > for 2.0 yet, I'm trying to use cygwin with x11 forwarding to run the scanner > from my laptop. (My server is in a closet and doesn't have a monitor, so > running locally on the server would be a pain.) > > When I start OpenVas-Client, it starts up just fine. As soon as I hover my > mouse cursor over one of the buttons on the toolbar, the program crashes > with the error below. > > Any suggestions? I have never tried this method. Maybe it uncovers a bug that usually does no harm. However, we are now working on the Windows port of OpenVAS-Client 2.0. Especially we take care that from now on the Windows stuff is build always together with a new realease. If you can't wait for it, we'll investigate in your report, but I do not know whether it is a OpenVAS-Client bug or perhaps a GTK+ bug. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335083-0 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Thu Jan 29 10:24:56 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 29 Jan 2009 10:24:56 +0100 Subject: [Openvas-devel] Updated OMP Specification Message-ID: <20090129092456.GB21185@intevation.de> Hello, I have updated the OMP specification, based on your feedback, analysis of the client code and a few new ideas. :) You can find the update specification together with the change request at: http://www.openvas.org/openvas-cr-28.html Main changes include: - The unique ID is now assigned by the client; this should help the client to better differntiate between response for multiple new_task requests. - IDs are included in most responses to improve error handling. - A lot of information has been moved from elements to attributes to improve the OMP structure and to simplify parsing. - Four new commands have been added: get_rules, get_certificates, get_preferences and get_dependencies. - Some elements and attributes have been renamed in favor of a more consistent naming scheme. - The get_nvt_details_oid and get_nvt_details_all commands have been merged into the get_nvt_details command which now takes an optional oid attribute. Those decisions are not intended to be final, especially the placement of data in elements or attributes. If you have any suggestions, I am looking forward to your feedback. Please do not hesitate to ask questions and to point out inconsistencies. Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 206 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090129/9b013f0a/attachment.pgp From chriswoodut at gmail.com Thu Jan 29 17:44:49 2009 From: chriswoodut at gmail.com (Chris Wood) Date: Thu, 29 Jan 2009 09:44:49 -0700 Subject: [Openvas-devel] Cygwin x11 forwarding, error? In-Reply-To: <200901290932.54813.jan-oliver.wagner@intevation.de> References: <200901290932.54813.jan-oliver.wagner@intevation.de> Message-ID: On Thu, Jan 29, 2009 at 1:31 AM, Jan-Oliver Wagner < jan-oliver.wagner at intevation.de> wrote: > > I have never tried this method. Maybe it uncovers a bug that usually does > no harm. > > However, we are now working on the Windows port of OpenVAS-Client 2.0. > Especially we take care that from now on the Windows stuff is build > always together with a new realease. > If you can't wait for it, we'll investigate in your report, but I do not > know whether > it is a OpenVAS-Client bug or perhaps a GTK+ bug. > > Best > > Jan > > Jan, I updated my cygwin to the latest version to see if I was behind in revisions and I was behind. The latest version works fine and the crash is gone. I'm attempting my first scan now. I'm not sure if it is doing anything, but I'll wait and see. Thanks! Chris Wood (resend: sorry, forgot to send it to the list instead of directly.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090129/59909b50/attachment.htm