This forces a downgrade from net-libs/gnutls-3.3.10-r2.
it doesn't work with gnutls-3
(In reply to Agostino Sarubbo from comment #1) > it doesn't work with gnutls-3 Would be nice if someone figured out why. I gave it a semi-serious attempt, but it seems to be something above casual poking.
Seems to be working: ndadm@ndspc045:~ $ equery -q l gnutls net-libs/gnutls-3.3.10-r2 ndadm@ndspc045:~ $ equery -q l openvas* net-analyzer/openvas-7.0.7 net-analyzer/openvas-cli-1.3.1 net-analyzer/openvas-libraries-7.0.9 net-analyzer/openvas-manager-5.0.9 net-analyzer/openvas-scanner-4.0.6 net-analyzer/openvas-tools-0_pre20512 What problems have you seen?
(In reply to Norman Shulman from comment #3) > Seems to be working: > Keyword: *seems*. Yes, the chain *builds* just fine, but start openvassd;openvasmd;gsad (well, there are a few more steps required to set the chain up, but you probably already know that) and - for example - try to go to the control web page... You won't connect and the log will offer very little info why.
We don't use gsad. If it requires gnutls-2, then that's where the dependency belongs, not in openvas-libraries. While I can't claim to have performed extensive testing, we can perform vulnerability scans.
@crypto herd: regardless of the status of this bug, would you mind to chime in again ? I'm basically repeating your arguments from bug 543280, but here it seems someone who's actually uses this app claims contrary results...
(In reply to Rafał Mużyło from comment #6) > @crypto herd: regardless of the status of this bug, would you mind to chime > in again ? > > I'm basically repeating your arguments from bug 543280, but here it seems > someone who's actually uses this app claims contrary results... not sure what you refer to. crypto will be very happy if openvas-libraries will use gnutls-3, gnutls-2 is not maintained any more at upstream, if it is not maintained in upstream we cannot maintain it either, nor do openvas people. this is the only package that has issues with gnutls migration and it should be addressed at upstream of this package and not downstream. the other option is to remove this package, as at first CVE of gnutls-2 without upstream patches, we probably drop gnutls-2 from tree.
From Wald: Release Name: 7.0.2 [openvas-libraries] Change Log Main changes since 7.0.1: * Fix build with GnuTLS 3.x As I said, openvas seems to work with gnutls-3; the dependency on gnutls-2 is in gsad, not in openvas-libraries. The ebuilds should be modified accordingly.
(In reply to Norman Shulman from comment #8) > From Wald: > > Release Name: 7.0.2 [openvas-libraries] > > Change Log > > Main changes since 7.0.1: > * Fix build with GnuTLS 3.x > > As I said, openvas seems to work with gnutls-3; the dependency on gnutls-2 > is in gsad, not in openvas-libraries. The ebuilds should be modified > accordingly. Good! Reassigning to maintainers.
(In reply to Alon Bar-Lev from comment #9) > (In reply to Norman Shulman from comment #8) > > From Wald: > > > > Release Name: 7.0.2 [openvas-libraries] > > > > Change Log > > > > Main changes since 7.0.1: > > * Fix build with GnuTLS 3.x > > > > As I said, openvas seems to work with gnutls-3; the dependency on gnutls-2 > > is in gsad, not in openvas-libraries. The ebuilds should be modified > > accordingly. > > Good! > > Reassigning to maintainers. It compiles but doesn't work. Come back when it works!
@comment 10: that's about what I've repeated, but comment 5 seems to suggest, that there's still some minimal functionality preserved... @reporter: would you elaborate in what way *exactly* is it *working* ? That is, how exactly did you run those scans and retrieved the report ?
From the developer: First, get OpenVas code for file formats nbe=`/usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 -F | grep NBE | gawk '{print \$1}'` html=`/usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 -F | grep HTML | gawk '{print \$1}'` Get Scan types supported safe=`/usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 -g | grep 'Full and fast ultimate' | gawk '{print \$1}'` unsafe=`/usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 -g | grep 'Full and very deep ultimate' | gawk '{print \$1}'` Set $type to $safe or $unsafe Create a Target cmd="/usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 --xml='<create_target><name>vscan</name><hosts>${ip}</hosts></create_target>' | gawk '{print \$2}' | gawk -F \"=\" '{print \$2}'" newtarget=`eval ${cmd}` Create a Task cmd="/usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 --xml='<create_task><name>vscantask</name><config id=\"${type}\" /><target id=\"${target}\" /></create_task>' | gawk '{print \$2}' | gawk -F \"=\" '{print \$2}'" newtask=`eval ${cmd}` Start the Task pid=`/usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 -S ${task}` Fetch Task state and wait for completion state=`/usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 -G | grep ${task} | gawk '{print \$2}'` while [ "${state}" != "Done" ]; do sleep 60 state=`/usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 -G | grep ${task} | gawk '{print \$2}'` done Fetch Report /usr/bin/omp -u ${user} -w ${pswd} -h 127.0.0.1 -p 9390 -R ${pid} -f ${html} > /tmp/vscanreport$$.html
@comment 12: Hmm... OK, I can't say if it really works, however openvas indeed seems to be doing something when given the above chain and produces something looking like a valid report (well, for my untrained eye)...
(In reply to Rafał Mużyło from comment #13) > @comment 12: Hmm... > > OK, I can't say if it really works, however openvas indeed seems to be doing > something when given the above chain and produces something looking like a > valid report (well, for my untrained eye)... Try to set up openvas on a clean system using gnutls3. It doesn't work. Watch out for connection errors.
(In reply to Justin Lecher from comment #14) > (In reply to Rafał Mużyło from comment #13) > > @comment 12: Hmm... > > > > OK, I can't say if it really works, however openvas indeed seems to be doing > > something when given the above chain and produces something looking like a > > valid report (well, for my untrained eye)... > > Try to set up openvas on a clean system using gnutls3. It doesn't work. > Watch out for connection errors. :roll: yes, I'm well aware of this, as well as "the dependency on gnutls-2 is in gsad, not in openvas-libraries" claim being false... Yet, it seems that the key functionality (that is the scanner) is working. Did anyone who actually knows gnutls tried testing what exactly goes wrong (and why) ?
(In reply to Rafał Mużyło from comment #15) > Did anyone who actually knows gnutls tried testing what exactly goes wrong > (and why) ? Neither I know gnutls very well nor I could track it down. It just shows connection errors.
Reopening as this is currently blocking gnutls 2.x removal that is needed in security bug 553690.
commit d91c938896457ce366ea399bb79a809b56fecb36 Author: Justin Lecher <jlec@gentoo.org> Date: Wed Nov 18 16:28:26 2015 +0100 net-analyzer/openvas-libraries: Version Bump fixes gnutls-3 support and compilation problems Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=544664 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=555544 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=556788 Package-Manager: portage-2.2.25 Signed-off-by: Justin Lecher <jlec@gentoo.org> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d91c938896457ce366ea399bb79a809b56fecb36
