Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
Version 3.0.6 of nessus has been released. Reproducible: Always Steps to Reproduce: 1.check version of nessus available in gentoo Actual Results: 3.0.5 Expected Results: 3.0.6
Hello, I have been using nessus-bin 3.0.6 without problems. - copied nessus-bin-3.0.5.ebuild to nessus-bin-3.0.6.ebuild in my overlay - copied nessusd-initd and 90nessus-bin from net-analyzer/nessus-bin/files/ - built digest and it installs and runs fine
I assume you also edited the ebuild to use the newer nessus rpm, and downloaded it... Which version of OpenSSL are you using? The official 3.0.5 needs 0.9.7, but the 0.9.7 series doesn't have the newer security fixes (it's actually not available anymore because of that...). Did you find a release linked against 0.9.8?
(In reply to comment #2) > I assume you also edited the ebuild to use the newer nessus rpm, and downloaded > it... Yes of course. > > > Which version of OpenSSL are you using? The official 3.0.5 needs 0.9.7, but the > 0.9.7 series doesn't have the newer security fixes (it's actually not available > anymore because of that...). Did you find a release linked against 0.9.8? > dev-libs/openssl-0.9.8g - works for me with nessus 3.0.6 That package provides both /usr/lib/libssl.so.0.9.7 and /usr/lib/libcrypto.so.0.9.7 in addition to the 0.9.8 libs
Nope! I don't think so. openssl-0.9.8g doesn't provide /usr/lib/libcrypto.so.0.9.7 and /usr/lib/libssl.so.0.9.7. It just keeps the old files intact. To confirm this. Move the two files to an alternate location and try emerging openssl-0.9.8g. It will not install these two files. However, you can make soft links for both these files with their newer versions and nessus would still work (However I don't think this is really safe). (In reply to comment #3) > (In reply to comment #2) > > I assume you also edited the ebuild to use the newer nessus rpm, and downloaded > > it... > > Yes of course. > > > > > > > Which version of OpenSSL are you using? The official 3.0.5 needs 0.9.7, but the > > 0.9.7 series doesn't have the newer security fixes (it's actually not available > > anymore because of that...). Did you find a release linked against 0.9.8? > > > > dev-libs/openssl-0.9.8g - works for me with nessus 3.0.6 > > That package provides both /usr/lib/libssl.so.0.9.7 and > /usr/lib/libcrypto.so.0.9.7 in addition to the 0.9.8 libs >
The latest version is 3.2.0. Please, change the summary.
Guys, I have submitted to new ebuilds to sectools overlay: http://gentoo.o0o.nu/portage/net-analyzer/nessus-bin/nessus-bin-3.2.0.ebuild http://gentoo.o0o.nu/portage/net-analyzer/nessus-client/nessus-client-3.2.0.ebuild Check it out. *nessus-bin-3.2.0 (18 Apr 2008) 18 Apr 2008; Erwin Paternotte <erwinp@dds.nl> +nessus-bin-3.2.0.ebuild: Switched to the Red Hat binaries, because they use OpenSSL 0.9.8 and offer a 64 bit version of nessus-bin.
Why do we need app-arch/rpm for nessus-bin-3.2.0 whereas nessus-bin-3.0.6 doesn't require it? I tried to install by removing app-arch/rpm dependency but the installation failed. As both 3.0.6 and 3.2 install from rpm files, I cannot understand why installation fails without app-arch/rpm. Can somebody please explain? Both the ebuilds inherit rpm (In reply to comment #6) > Guys, > > I have submitted to new ebuilds to sectools overlay: > http://gentoo.o0o.nu/portage/net-analyzer/nessus-bin/nessus-bin-3.2.0.ebuild > http://gentoo.o0o.nu/portage/net-analyzer/nessus-client/nessus-client-3.2.0.ebuild > > Check it out. > > *nessus-bin-3.2.0 (18 Apr 2008) > > 18 Apr 2008; Erwin Paternotte <erwinp@dds.nl> +nessus-bin-3.2.0.ebuild: > Switched to the Red Hat binaries, because they use OpenSSL 0.9.8 and > offer a 64 bit version of nessus-bin. >
(In reply to comment #7) > Why do we need app-arch/rpm for nessus-bin-3.2.0 whereas nessus-bin-3.0.6 > doesn't require it? Because it's uses updated rpm format and thus we need rpm2cpio binary (part of rpm package) to unpack that. May be it's better to use debian packages, but neither I'm sure nor I tested that...
Hi, Can I use rpm2cpio-file-roller (belonging to app-arch/file-roller) which already exists on my system? I don't want to download and install that monster (rpm) just to uncompress Nessus Binary. I can successfully uncompress Nessus-3.2.0-es5.i386.rpm by using rpm2cpio-file-roller. Can I somehow modify the ebuild to use rpm2cpio-file-roller (from app-arch/file-roller) rather than using rpm2cpio (from app-arch/rpm)?? Thanks! (In reply to comment #8) > (In reply to comment #7) > > Why do we need app-arch/rpm for nessus-bin-3.2.0 whereas nessus-bin-3.0.6 > > doesn't require it? > > Because it's uses updated rpm format and thus we need rpm2cpio binary (part of > rpm package) to unpack that. > > May be it's better to use debian packages, but neither I'm sure nor I tested > that... >
(In reply to comment #9) > Can I use rpm2cpio-file-roller (belonging to app-arch/file-roller) which > already exists on my system? That's very interesting idea, but it's not an official way for now. Wouldn't it be better if we file a separate bug report with that suggestion, fix rpm.class and update the following manual: http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/rpm-sources/index.html ?
I think that will be much better than using app-arch/rpm. Meanwhile I tried emerging nessus-bin-3.2.0 by commenting rpm dependency and making a symbolic link rpm2cpio to rpm2cpio-file-roller. The CPIO conversion works (as I can see "CPIO archive found!"). However there is an error. ================== <..........snipped......to maintain sanity> ecompressdir: bzip2 -9 /opt/nessus/man ecompressdir: bzip2 -9 /opt/nessus/share/man * QA Notice: Found an absolute symlink in a library directory: * usr/lib/libcrypto.so.6 -> /usr/lib/libcrypto.so.0.9.8 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Found an absolute symlink in a library directory: * usr/lib/libssl.so.6 -> /usr/lib/libssl.so.0.9.8 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * checking 20873 files for package collisions 1000 files checked ... 2000 files checked ... 3000 files checked ... 4000 files checked ... 5000 files checked ... 6000 files checked ... 7000 files checked ... 8000 files checked ... 9000 files checked ... 10000 files checked ... 11000 files checked ... 12000 files checked ... 13000 files checked ... 14000 files checked ... 15000 files checked ... 16000 files checked ... 17000 files checked ... 18000 files checked ... 19000 files checked ... 20000 files checked ... [Errno 7] Argument list too long: bash -c source '/usr/lib/portage/bin/isolated-functions.sh' ; eerror "This package will overwrite one or more files that may belong to other" ; eerror "packages (see list below). You can use a command such as \`portageq" ; eerror "owners / <filename>\` to identify the installed package that owns a" ; eerror "file. If portageq reports that only one package owns a file then do" ; eerror "NOT file a bug report. A bug report is only useful if it identifies at" ; eerror "least two or more packages that are known to install the same file(s)." ; eerror "If a collision occurs and you can not explain where the f <snipped .........to maintain sanity.......> ================== And the install doesn't work. Can you tell me where am I going wrong? (In reply to comment #10) > (In reply to comment #9) > > Can I use rpm2cpio-file-roller (belonging to app-arch/file-roller) which > > already exists on my system? > > That's very interesting idea, but it's not an official way for now. > Wouldn't it be better if we file a separate bug report with that suggestion, > fix rpm.class and update the following manual: > http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/rpm-sources/index.html > ? >
(In reply to comment #11) > I think that will be much better than using app-arch/rpm. No, forget about it. rpm2cpio-file-roller pools entire Gnome and I don't want to install it. > And the install doesn't work. Can you tell me where am I going wrong? try this instead: DEPEND="=sys-libs/db-4.3* dev-libs/openssl app-arch/file-roller" # app-arch/rpm" src_unpack () { #check syntactics here: rpm2cpio-file-roller ${A} }
Hi, A little investigation shows that the main reason we cannot uncompress the new Nessus rpm is that the rpmoffset program (on which rpm2targz is based) fails to locate the magic bytes. Changing the RPMBUFSIZ to 3MB (currently it is 2MB) in rpmoffset.c will make it work with the new rpm also. Now only if we could submit a patch for rpmoffset.c and get it included, our troubles will be gone. (In reply to comment #12) > (In reply to comment #11) > > I think that will be much better than using app-arch/rpm. > No, forget about it. rpm2cpio-file-roller pools entire Gnome and I don't want > to install it. > > > And the install doesn't work. Can you tell me where am I going wrong? > > try this instead: > DEPEND="=sys-libs/db-4.3* > dev-libs/openssl > app-arch/file-roller" > # app-arch/rpm" > > src_unpack () { > #check syntactics here: > rpm2cpio-file-roller ${A} > } >
(In reply to comment #13) > Changing the RPMBUFSIZ to 3MB (currently it is 2MB) in rpmoffset.c will > make it work with the new rpm also. Nice catch. rpm2targz-9.0-r7 is in portage.
Created an attachment (id=151307) [edit] New rpmoffset (independent of rpm size) Hi, This patch removes size restriction from rpmoffset, so that it can work with all rpm sizes (and keep us all away from app-arch/rpm for as long as possible ;)). Can we include this one? I have tested it with the following rpms: 1. RealPlayer-10.0.9.809-20070726.i586.rpm 2. NessusClient-3.2.0-es5.i386.rpm 3. flash-plugin-9.0.124.0-release.i386.rpm 4. Nessus-3.0.6-suse10.0.i586.rpm
(In reply to comment #15) > Created an attachment (id=151307) [edit] > New rpmoffset (independent of rpm size) > Correct me if I'm wrong, but the following code looks 2 and 3 byte out of border: char p[3]; p[1] == '\213'; p[2] == '\010'; char p[3] should give you only 3 bytes: p[0]-p[2].
yes I will get only 3 bytes and only 3 bytes are needed. Where is it going out of border? I am only referring to p[0] (i.e equivalent to *p), p[1] and p[2] (In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=151307) [edit] > > New rpmoffset (independent of rpm size) > > > > Correct me if I'm wrong, but the following code looks 2 and 3 byte out of > border: > char p[3]; > p[1] == '\213'; > p[2] == '\010'; > > char p[3] should give you only 3 bytes: p[0]-p[2]. >
(In reply to comment #17) > yes I will get only 3 bytes and only 3 bytes are needed. Where is it going out > of border? I am only referring to p[0] (i.e equivalent to *p), p[1] and p[2] > > p[1] == '\213'; > > p[2] == '\010'; ah, '' is a 1 character only. You are right. Sorry! Nice one! btw, you can also remove: > /* chunk of RAM right away so that we have enough. Yeah, horrible */ > /* quick and dirty implementation, but hey -- it gets the job done. */ as it clean now ;)
Created an attachment (id=151312) [edit] Complete code. Here is the complete code. Have cleaned up the comments which don't apply now ;)
Guys, this bug is about nessus-bin. For rpm2targz open a new feature request and attach patch there, not full sources code. Also as I already told you rpm2targz-9.0-r7 fixes the problem with nessus but your solution I like more, so, please, open new bug.
Opened bug# 219711. Thanks. (In reply to comment #20) > Guys, this bug is about nessus-bin. For rpm2targz open a new feature request > and attach patch there, not full sources code. > > Also as I already told you rpm2targz-9.0-r7 fixes the problem with nessus but > your solution I like more, so, please, open new bug. >
I have updated the nessus-bin ebuild and it does not require that heavy rpm package: http://gentoo.o0o.nu/portage/net-analyzer/nessus-bin/nessus-bin-3.2.0-r1.ebuild Thanks Cyberjun.
After (fresh) install: # /opt/nessus/sbin/nessus-adduser nessusd: error while loading shared libraries: libnessus.so.3: cannot open shared object file: No such file or directory Adding "/opt/nessus/lib/" to /etc/ld.so.conf and doing `ldconfig` fixed this. So, it should be added to ebuild (sorry, I don't know how to do it correctly)
...and init script is missing :(
(In reply to comment #23) > Adding "/opt/nessus/lib/" to /etc/ld.so.conf and doing `ldconfig` fixed this. > ...and init script is missing :( You forgot to download the "files" directory too. The easiest way is to add this overlay to layman list and do layman -S. See main page for details.
(In reply to comment #25) > (In reply to comment #23) > > Adding "/opt/nessus/lib/" to /etc/ld.so.conf and doing `ldconfig` fixed this. > > ...and init script is missing :( > > You forgot to download the "files" directory too. > The easiest way is to add this overlay to layman list and do layman -S. > See main page for details. > Oh, so why there were no errors/warnings?
(In reply to comment #26) > Oh, so why there were no errors/warnings? I'm sure you'll find a warning message on a screen or it'll be in a log file then it compiled using 'ebuilld nessus.ebuild install' command and it's good enough for developers. btw, I just had the same problem in the bug #209900 so you're not alone :)
Hi guys, 3.2.0 is now in cvs, thanks to your contributions. Cheers!
