IRC channel log

[07:58:40]*mwiegand (~michael@aktaia.intevation.org) entered the channel
[07:58:49]mwiegandmorning
[10:03:29]*felix (~Felix@aktaia.intevation.org) entered the channel
[10:03:34]felixmorning
[10:15:06]felixkost: bug #825 its a pity that the backtrace is so unverbose :)
[10:36:51]kostfelix morning
[10:37:18]kostI tried to compile my own libgpgme on openvas, so I can have debug symbols for libgpgme
[10:37:30]kostand with my own compiled version of libgpgme - it does not crash
[10:37:38]kostsame lib versions
[10:37:49]felixouch
[10:37:57]kostSeems backtrack have problems with their version of libgpgme
[10:38:26]felixand it were the same version numbers, the compiled one and the preinstalled one?
[10:38:41]kostSo, I thought that I should do cp -af /opt/openvas/lib/libgpgme* /usr/lib/ when doing "openvas-setup" script
[10:41:16]kostLD_LIBRARY_PATH seems boring solution, because I had to do it before every command (or I should put it in the profile of bash).
[10:41:33]felixgpg(me)-dev mailinglist is down at the moment, but maybe the folks there can help about the gpgme backtrack issue
[10:41:37]kostanother solution is to have /etc/ld.so.conf with 1 line /opt/openvas/lib (with correct libgpgme)
[10:43:23]felixkost: did you talk to the backtrack people?
[10:44:07]felixkost: but that also means that there will be a backtrack live cd with openvas2.0.0beta2, right? good news!
[10:44:22]kostfelix: what binaries require libgpgme?
[10:44:27]kostonly openvasd?
[10:46:32]felixi do not know about the mk-cert etc. i would guess they need libgpgme as well
[10:46:34]kostfelix: I hope I will make 2.0.0beta2 version, but need above version to decide lib decision I will make.
[10:50:45]kostfelix: Just checked.
[10:51:02]kostopenvasd and openvas-nasl have libgpgme depends
[10:51:10]kostmk-cert and the rest are scripts...
[10:55:44]*Chandan (~chandan@122.167.81.96) entered the channel
[11:19:12]*mattm (~mattm@87-194-56-101.bethere.co.uk) entered the channel
[11:30:23]mwiegandhello mattm
[11:31:02]mattmhi mwiegand
[11:56:28]kostkost finished .lzm module for beta2. it's working.
[11:57:03]kostmade wrapper script for openvasd and openvasl-nasl to set LD_LIBRARY_PATH first to working libgpgme version
[11:57:05]felixkost: cool. which method did you choose? :)
[11:57:11]felixok
[11:57:45]kostthere is only two of binaries, so I decided to use script. So I don't break any other app which is working(?) with that broken version of libgpgme
[12:03:24]felixdid you post the problem to the backtrack forum? So that they dont get frustrated if they later want to include openvas.
[12:16:15]mwiegand[machine]: I'm about to test the solaris NVTs, do you remember what your issue with gather-package-list.nasl was?
[12:40:35]mwiegandhmm, gather-package-list.nasl seems to think SunOS is SuSE ;)
[12:40:48]mwiegand1226921866 1 ssh/login/uname=SunOS qasol 5.10 Generic_137138-09 i86pc i386 i86pc\n
[12:40:51]mwiegand1226921869 1 ssh/login/release=SUSE
[13:12:29]*Chandan (~chandan@122.167.81.96) has quit (Ping timeout: 480 seconds)
[13:17:39]*atomicturtle (~sshinn@wsip-70-184-242-83.dc.dc.cox.net) entered the channel
[13:19:58]felixhi atomicturtle. finally you can have your questions answered directly... ;)
[13:20:28]atomicturtlehaha, thanks
[13:20:52]atomicturtleI think the last one was in reference to OVAL
[13:21:49]atomicturtlelargely Ive managed to take care of all the packaging issues on my own. The only one outstanding, and I dont think this is anything for the openvas team really, is with the X interface under CentOS/RHEL 4
[13:22:37]atomicturtleas of right now, that wont build. I don't see that as a major issue really, the command line version does
[13:24:35]felixatomicturtle: good to hear. oval- integration is in progress (can be seen as experimental) and will hopefully work soon
[13:24:49]atomicturtleis that in 2.0.0-beta1?
[13:24:54]felixif you are interested in the internals or want to help, here is a reference about that http://www.openvas.org/openvas-cr-13.html
[13:25:21]atomicturtleIm certainly available for packaging support, Ive done both 1.x and 2.x packages form RHEL 4/5, centos 4/5, and Fedora 4-10 already
[13:26:02]atomicturtleand I can take care of ovaldi packages for those platforms too
[13:26:37]felixvery nice. mwiegand is your guy to talk about that.
[13:27:36]atomicturtleall the packages are available here, via yum now: http://www.atomicorp.com/channels/atomic/
[13:54:11]mwiegandmwiegand is back
[13:55:01]mwiegandatomicturtle: oval integration is in 2.0-beta2, although a patched version of ovaldi is required
[13:55:22]atomicturtlegot a link for the patch? Im doing ovaldi rpms now
[13:56:53]mwiegandsee http://www.openvas.org/integrated-tools.html -> ovaldi
[13:57:50]atomicturtleoh neat, I didnt know it used hydra
[13:57:59]atomicturtleI just did that last week
[13:58:08]mwiegandI'd recommend rev 138 of ovaldi, I haven't yet had the time to write a patch for the latest ovaldi release
[13:58:35]atomicturtleno problem
[13:59:08]atomicturtleI can get all these bundled up, Ive got something of my own to add to SLAD as well
[13:59:34]mwiegandthe integration will likely improve with future release of ovaldi and openvas
[14:00:34]atomicturtleno problem, packaging this kind of thing is more or less my full time job
[14:00:53]mwiegandwow, great :)
[14:01:10]mwiegandwe can use someone like you :)
[14:01:30]atomicturtlewe're also the guys that do all the mod_security rules
[14:01:35]atomicturtlegotroot.com
[14:02:19]mwiegandpackaging for distros other than debian is not yet very extensive in OpenVAS, I'm afraid
[14:02:56]mwiegandso if you want to take a look at the packaging files in SVN, you're more than welcome
[14:02:57]atomicturtleIts no problem for me to do the CentOS, RHEL and Fedora packages
[14:03:25]atomicturtleyeah I started working with the fc8 .spec
[14:03:40]atomicturtleand made some changes for the build system I use
[14:03:42]atomicturtlehttp://3es.atomicrocketturtle.com/packages/openvas-server/openvas-server.spec
[14:03:55]atomicturtleits conditional, so I basically build all distros from a single .spec file
[14:04:49]mwiegandsounds good
[14:05:07]mwiegandI've you want to add something there, just send me a patch
[14:05:18]mwiegands/I've/If/
[14:05:22]atomicturtleso far its just been some minor .spec updates
[14:05:48]atomicturtleconditionals when the package name is different between environments. Like libpcap
[14:06:11]mwiegandmind if I add a link to your packages to the OpenVAS website?
[14:06:30]atomicturtleno problem!
[14:07:52]mwiegandmwiegand found the bug in gather-package-list.nasl
[14:08:36]atomicturtleonce I get the packaging part nailed down, I'll probably do some work on developing nasl checks as well
[14:09:02]mwiegandsounds great!
[14:09:04]atomicturtleIve got a lot of vulnerability checks in ASL that would be a good place to converge
[14:09:34]atomicturtleIve been doing ones a bit deeper into an application, like dangerous PHP settings, or detecting a kernel with an executable stack
[14:10:34]mwiegandhaha, doing "rls = toupper(ssh_cmd(socket:sock, cmd:"cat /etc/SuSE-release"));" and then evaluating ("SUSE"><rls) : Not a good idea.
[14:14:18]mwiegandsounds good, if you have questions regarding NASL Chandan and chandra are probably the guys to ask
[14:14:47]mwiegandI'm only good at spotting broken NASL scripts ;)
[14:23:31]atomicturtledefinitely, at this point the main thing I wanted to get working are the local vulnerability checks on rhel and centos
[14:23:40]atomicturtlewhich I assume the oval stuff will do
[14:40:06]mwiegandyes, pretty much
[14:41:40]mwiegandyou can do local checks for RHEL with NASL already if I'm not mistaken, but OVAL is supported as well with the ovaldi patch
[14:42:09]atomicturtleyeah you can, there just arent any local checks for rhel or centos in it
[14:42:19]atomicturtlehence oval
[14:42:39]atomicturtleplus redhat maintains it, so no extra work required
[14:45:35]mwiegandthat was our motivation as well ;)
[14:45:46]atomicturtleheh, Im all about that
[14:45:56]atomicturtleless is more
[14:48:21]atomicturtlehave you used portbunny at all?
[14:48:57]atomicturtlepacking it is a bit more complicated since it has kernel version dependency
[14:49:52]atomicturtleunless its a major improvement in terms of performance over strobe/nmap/etc I think Im going to skip it for now
[14:55:16]mwiegandI think kost and [machine] were busy with the portbunny thing
[14:55:29]mwiegandbetter ask them
[14:55:33]kostatomicturtle: portbunny is good for internal scans. it beats nmap+openvas combination because of this (I don't like repeating):
[14:56:01]atomicturtlethats what I figured
[14:56:02]kosthttp://www.nessus.org/documentation/index.php?doc=nmap-usage
[14:56:17]atomicturtleIm old school, I still use strobe
[14:56:50]kost(because how nessus/openvas work, nmap can consume lot of RAM if you're doing scan of lot of IPs)
[14:57:02]atomicturtleyes indeed
[14:57:49]kostbut, make sure to include PortBunny261008-dev.tar.gz or later
[14:58:02]atomicturtleI probably wont be packaging that one today
[14:58:22]kostthey accepted my patch to fix some issues in portbunny
[14:58:25]atomicturtleit looks compelling though, if its faster than strobe
[15:01:36]koststrobe doesn't detect all ports when I tested it
[15:01:52]kostEspecially it's not nice with embeded devices
[15:02:09]atomicturtleyou should see how we used to do it with Ballista
[15:02:17]atomicturtlewe used strobe and udp_scan
[15:03:13]atomicturtlewe had to have a timer on udp_scan to kill it after so many seconds
[15:04:27]mwiegandhehe
[15:04:42]mwiegandkost: I think I got solaris scans working
[15:05:04]kostcongrats mwiegand
[15:05:29]kostfix for that checking for suse fixed the problem?
[15:12:03]mwiegandI've commented it out until we think of something more reliable, I'm about to commit and post a mail to -plugins
[16:17:59]*mwiegand (~michael@aktaia.intevation.org) has quit (Quit: leaving)
[16:28:17]atomicturtleOk Ive gotten everything done except for PortBunny
[16:28:26]atomicturtleand testing it... :P
[16:29:04]atomicturtleand SLAD, but thats a different project
[16:43:50]JoeyHow long does one have to wait until the web-uploaded public ssh key is available in wald for svn+ssh?
[16:59:01]JoeyApparently, I just waited the proper amount of time (now getting an svn error). Sorry for the noise.
[17:01:40]atomicturtleis there a version requirement on Glib2?
[17:01:53]atomicturtleIm getting build errors on RHEL/CentOS4
[17:02:03]atomicturtlewith beta2, I didnt have issues with beta1
[17:02:22]atomicturtlenasl.c:119: error: `GOptionContext' undeclared (first use in this function)
[17:03:32]Joeylooks like
[17:06:39]atomicturtlethats against glib2-2.4.7-1
[17:06:53]atomicturtleglib2-2.12.3-2 seems OK
[17:07:19]atomicturtleI dont think upgrading glib2 is an option though
[17:07:48]atomicturtleit ties into way too many other packages
[17:26:14]Joeyyou can install several glib *runtime* versions
[17:26:47]Joeythat way the other programs can continue to link against 2.4.7 while the newer one can link to 2.13
[17:27:02]Joey(at least in general you can, I know nothing about CentOS interna)
[17:33:59]atomicturtleyeah I could do a -compat package
[18:17:15]*mattm (~mattm@87-194-56-101.bethere.co.uk) has quit (Remote host closed the connection)
[18:34:00]*mattm (~mattm@87-194-56-101.bethere.co.uk) entered the channel
[21:00:53]*mattm (~mattm@87-194-56-101.bethere.co.uk) has quit (Ping timeout: 480 seconds)

Last 30 days: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3

Log for