Bug 187219 - net-analyzer/nessus-bin version 3.2.0 has been released
|
Bug#:
187219
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: netmon@gentoo.org
|
Reported By: paternotte@fox-it.com
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: net-analyzer/nessus-bin version 3.2.0 has been released
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-07-31 09:29 0000
|
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.
(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...
>
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) [details]
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] [details]
> 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] [details]
> > 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 ;)
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.
>
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!
