greenbone / gvmd Goto Github PK

View Code? Open in Web Editor NEW

272.0 19.0 154.0 103.48 MB

Greenbone Vulnerability Manager - The database backend for the Greenbone Community Edition

License: GNU Affero General Public License v3.0

CMake 1.32% XSLT 1.14% Shell 6.53% Python 0.25% C 90.69% Dockerfile 0.06%

greenbone openvas vulnerability vulnerability-management vulnerability-scanners openvas-manager c gea backend extended

gvmd's Introduction

Greenbone Vulnerability Manager

The Greenbone Vulnerability Manager is the central management service between security scanners and the user clients.

It manages the storage of any vulnerability management configurations and of the scan results. Access to data, control commands and workflows is offered via the XML-based Greenbone Management Protocol (GMP). Controlling scanners like OpenVAS is done via the Open Scanner Protocol (OSP).

Releases

All release files are signed with the Greenbone Community Feed integrity key. This gpg key can be downloaded at https://www.greenbone.net/GBCommunitySigningKey.asc and the fingerprint is 8AE4 BE42 9B60 A59B 311C 2E73 9823 FAA6 0ED1 E580.

Installation and Usage

This module can be configured, built and installed with following commands:

cmake .
make install

For detailed installation requirements and instructions, please see the file INSTALL.md. The file also contains instructions for setting up gvmd and for connecting gvmd to vulnerability scanners and to the GSA web interface.

In case everything was installed using the defaults, then starting the manager daemon can be done with this simple command:

gvmd

To see all available command line options of gvmd enter this command:

gvmd --help

If you are not familiar or comfortable building from source code, we recommend that you use the Greenbone Enterprise TRIAL, a prepared virtual machine with a readily available setup. Information regarding the virtual machine is available at https://www.greenbone.net/en/testnow.

Support

For any question on the usage of gvmd please use the Greenbone Community Portal. If you found a problem with the software, please create an issue on GitHub. If you are a Greenbone customer you may alternatively or additionally forward your issue to the Greenbone Support Portal.

Maintainer

This project is maintained by Greenbone AG.

Contributing

Your contributions are highly appreciated. Please create a pull request on GitHub. Bigger changes need to be discussed with the development team via the issues section at GitHub first.

License

Licensed under the GNU Affero General Public License v3.0 or later.

gvmd's People

Contributors

Stargazers

Watchers

Forkers

jjnicola kroosec timopollmeier mattmundell romasamojlenko janowagner falegk ktosiek davidak pkjmesra whutsongy tuxmaster5000 normanshulman diverops bithex iammosespaulr shanghaiwudun argusb criteo-forks iensis hoijui bennylangston pombredanne apriorit simbazad gizzmoasus anianios zh3ngcha0 admirito shifoumy trev0r91 lonewolffcoder rootorben cikk3y vulnbe geckrdhrff thymos-cloud-engineering mettatu kweik drmendes jamesber50 saberlynx arnostiefvater cptguo ziqi521 egberdun y0urself qha emme1990 rrenkert skyghostliu ph0eby root-secure rcguidewire hiyao cheese1 bk5839 swastikdey175 jongoldman7 robodom tuto193 vicosurge kddco cfloy66-v12o usamabinladen zeitgist-labs sgarc57 usteiner9 s-l-teichmann pedromreis andreasbrett testdaveoffice72 aplater thorsten-passfeld p-libradilla halilibrahimdirik marckll xaviermarquez-alba dgonzc01 kraemii lhannigbrinck hartl3y94 jhelmold ariffinaldo harrypod wilsonfr4nco cbrauman-sjrwmd rtkwlf sinsixx nickdannenberg dexus-forks stjordanis clivebi secureonelabs maczal manuelbeiras introntech fzaleta s0u1sb4n3 thebenmeadows

gvmd's Issues

gvm-portnames-update points to the wrong db path

Expected behavior

the script 'gvm-portnames-update' should update the gvm database with new port names from IANA website at "http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml".
NB: i found a similar issue with title "gvm-portnames-update has a hardcoded old db name (tasks) #175" but is closed. I found that the problem is still present.

Current behavior

the script works, but it points to the wrong path
`root@debian-test:/usr/local/src/gse/openvas-scanner/build# /usr/local/sbin/gvm-portnames-update
Update port names data from a port names XML file.

Currently supports the official IANA Services Names list.
In order to update the DB, download the port names list and
provide its path as an argument to this script.
$ wget http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
$ openvas-portnames-update service-names-port-numbers.xml
$ rm service-names-port-numbers.xml
--2019-01-10 16:44:04-- http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
Length: unspecified [text/xml]
Saving to: ‘service-names-port-numbers.xml’

service-names-port-numbers.xml [ <=> ] 3.52M 541KB/s in 6.7s

2019-01-10 16:44:11 (541 KB/s) - ‘service-names-port-numbers.xml’ saved [3690073]

root@debian-test:/usr/local/src/gse/openvas-scanner/build# /usr/local/sbin/gvm-portnames-update service-names-port-numbers.xml
/usr/local/var/lib/openvas/gvmd/gvmd.db not found. Rebuild DB before updating port names.
`
but "/usr/local/var/lib/openvas/gvmd/gvmd.db "is the wrong path, the right path is "/usr/local/var/lib/gvm/gvmd/gvmd.db"

Steps to reproduce

see above

Environment

gsa: (gsad --version)
Greenbone Security Assistant 8.0+beta3
GIT revision 29acdd6-master

gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0+beta2
GIT revision 6e48194-master

openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0+beta3
GIT revision 6f209c9-master

gvm-libs:
gvm-libs 1.0+beta2 (2018-12-04)
Environment

Operating system:
Debian 9.6

Installation method / source: (packages, source installation)
git source installation

[7.0.2] Unable to login without the "help" permission

When an user don't have the "help" right, the he can't log in any more.

Steps to Reproduce:

remove the help right for the user
let the user log in.

Actual results:
Log in impossible

Expected results:
That the user can use the manager, but without the help menu.

Delete user issue

Hi guys,

When I try to delete a user whose tasks have been run by another user then there is a problem.
As shown below, report_counts belong to another "user" so they are not deleted, and then when it is trying to delete the reports raises a "violates foreign key constraint" problem.

This is likely to happen with other tables like host_identifiers

openvasmd-pg --version
OpenVAS Manager 7.0.3
Manager DB revision 184

md manage:WARNING:2018-04-13 00h33.18 EEST:27339: sql_exec_internal: SQL: DELETE FROM reports WHERE owner = 57;
md manage:WARNING:2018-04-13 00h33.18 EEST:27339: sqlv: sql_exec_internal failed
md manage:WARNING:2018-04-13 14h45.24 EEST:29936: sql_exec_internal: PQexec failed: 
ERROR:  update or delete on table "reports" violates foreign key constraint "report_counts_report_fkey" on table "report_counts"
DETAIL:  Key (id)=(3587) is still referenced from table "report_counts".
 (7)

Edit: Of course if I use an inheritor, works correctly.

error: implicit declaration of function ‘gvm_auth_tear_down’

Expected behavior

make compiles sources

Current behavior

make returns error:

gvmd.c:921:3: error: implicit declaration of function ‘gvm_auth_tear_down’ [-Werror=implicit-function-declaration]
   gvm_auth_tear_down ();
   ^~~~~~~~~~~~~~~~~~

Steps to reproduce

cd gvmd-8.0-beta2
mkdir build
cd build
cmake ..
make

GVM versions

gvmd-8.0-beta2

Environment

Operating system: Debian GNU/Linux 9

Installation method / source: source installation

Logfiles

[  3%] Building C object src/CMakeFiles/gvmd-sqlite.dir/gvmd.c.o
/root/install/openvas10/gvmd-8.0-beta2/src/gvmd.c: In function ‘cleanup’:
/root/install/openvas10/gvmd-8.0-beta2/src/gvmd.c:921:3: error: implicit declaration of function ‘gvm_auth_tear_down’ [-Werror=implicit-function-declaration]
   gvm_auth_tear_down ();
   ^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
src/CMakeFiles/gvmd-sqlite.dir/build.make:62: recipe for target 'src/CMakeFiles/gvmd-sqlite.dir/gvmd.c.o' failed
make[2]: *** [src/CMakeFiles/gvmd-sqlite.dir/gvmd.c.o] Error 1
CMakeFiles/Makefile2:154: recipe for target 'src/CMakeFiles/gvmd-sqlite.dir/all' failed
make[1]: *** [src/CMakeFiles/gvmd-sqlite.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

[7.0.2] When an task is requestet an sql error will be show

I simple add an IP as an scan target and let the "System Discovery" scan run.

d manage: INFO:2018-02-09 05h56.30 UTC:22201: nvt_selector_plugins: NVTs not explicitly activated anymore for this config: 1.3.6.1.4.1.25623.1.0.10265;1.3.6.1.4.1.25623.1.0.103914;1.3.6.1.4.1.25623.1.0.103978
;1.3.6.1.4.1.25623.1.0.95888;1.3.6.1.4.1.25623.1.0.12241;1.3.6.1.4.1.25623.1.0.108298;1.3.6.1.4.1.25623.1.0.11933;1.3.6.1.4.1.25623.1.0.12288;1.3.6.1.4.1.25623.1.0.80010;1.3.6.1.4.1.25623.1.0.810010;1.3.6.1.4.1.
25623.1.0.10870;1.3.6.1.4.1.25623.1.0.108215;1.3.6.1.4.1.25623.1.0.80011;1.3.6.1.4.1.25623.1.0.103585;1.3.6.1.4.1.25623.1.0.103697;1.3.6.1.4.1.25623.1.0.100509;1.3.6.1.4.1.25623.1.0.80104;1.3.6.1.4.1.25623.1.0.8
0086;1.3.6.1.4.1.25623.1.0.900238;. Please adjust the config if you think this is wrong.
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: sql_prepare_internal: sqlite3_prepare failed: near "(": syntax error
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: init_iterator: sql_prepare failed
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: manage_cleanup_process_error: Error exit, setting running task to Internal Error
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: sql_prepare_internal: sqlite3_prepare failed: near "(": syntax error
md manage:WARNING:2018-02-09 05h56.31 UTC:22201: init_iterator: sql_prepare failed

Gvm-cli connections fail under openvassd load

I'm using gvm-cli (gvm-cli 2.0.0.beta1. API version 1.0.0.dev1) to connect to openvasmd on the local server to start and manage tasks, download reports etc.

An openvassd scan will spawn a lot of processes, and as a result the load on my system will increase.

At some level of load to openvassd, the gvm-cli will not connect with openvasmd and throws an error. If the load stays particularly high for some time, gvm-cli will not connect at all.
This seems to be a persistent bug, tested on two different systems, easily reproducible.

Using "gvm-cli socket -c --xml ..." or "gvm-cli socket --gmp-username foo --gmp-password foo --xml ..." will yield same results. The xml string itself has no effect on this behaviour.

Error message:

$ gvm-cli socket -c --xml "<get_version/>"
Traceback (most recent call last):
File "/usr/local/bin/gvm-cli", line 11, in
sys.exit(main())
File "/usr/local/lib/python3.6/dist-packages/gvmtools/cli.py", line 251, in main
gvm.authenticate(args.gmp_username, args.gmp_password)
File "/home/asgeir/.local/lib/python3.6/site-packages/gvm/protocols/gmpv7.py", line 198, in authenticate
response = self._read()
File "/home/asgeir/.local/lib/python3.6/site-packages/gvm/protocols/base.py", line 54, in _read
response = self._connection.read()
File "/home/asgeir/.local/lib/python3.6/site-packages/gvm/connections.py", line 275, in read
data = self._socket.recv(BUF_SIZE)
ConnectionResetError: [Errno 104] Connection reset by peer

$ uptime
11:03:24 up 4 days, 46 min, 2 users, load average: 32.38, 20.21, 8.70

Each time this happens, the openvasmd.log will print:

md manage:WARNING:2019-01-22 10h59.29 utc:16364: sql_exec_internal: sqlite3_step failed: interrupted
md manage:WARNING:2019-01-22 10h59.29 utc:16364: sqlv: sql_exec_internal failed

Somehow, I feel this must be a bug in openvasmd, possibly within src/sql_sqlite3.c, sql_exec_internal() or any other function?

Is it possible that the openvasmd code is not honoring timeouts, or the timeouts are too short in the code? This problem happens constantly when openvassd comes under load. openvasmd itself takes no load at all.

It should be noted that at the same time, the tasks.db database can easily be accessed with just any sqlite command, and will answer instantly, like:

$ sudo sqlite3 /usr/local/var/lib/openvas/mgr/tasks.db "select * from tasks;"

So, the sqlite database file (tasks.db) itself is not at all under load or inaccessible in any way (local or remotely over ssh) under these circumstances.

My system:

$ openvassd --version
OpenVAS Scanner 5.1.3

$ openvasmd --version
OpenVAS Manager 7.0.4
GIT revision 0356381-openvas-manager-7.0
Manager DB revision 184

$ gvm-cli --version
gvm-cli 2.0.0.beta1. API version 1.0.0.dev1

$ uname -a
Linux xxx 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[beta3] Build faills

The beta3 build fails with:

In file included from /usr/include/string.h:638:0,
from /usr/include/glib-2.0/glib/gtestutils.h:30,
from /usr/include/glib-2.0/glib.h:82,
from /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_base.h:29,
from /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.h:29,
from /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:33:
In function 'memset',
inlined from 'create_ticket_reset' at /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:351:10:
/usr/include/bits/string3.h:84:3: error: call to __builtin___memset_chk will always overflow destination buffer [-Werror]
return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
^
In function 'memset',
inlined from 'modify_ticket_reset' at /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:635:10:
/usr/include/bits/string3.h:84:3: error: call to __builtin___memset_chk will always overflow destination buffer [-Werror]
return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
^
In function 'memset',
inlined from 'create_ticket_start' at /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:366:10:
/usr/include/bits/string3.h:84:3: error: call to __builtin___memset_chk will always overflow destination buffer [-Werror]
return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
^
In function 'memset',
inlined from 'modify_ticket_start' at /builddir/build/BUILD/gvmd-8.0-beta3/src/gmp_tickets.c:650:10:
/usr/include/bits/string3.h:84:3: error: call to __builtin___memset_chk will always overflow destination buffer [-Werror]
return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
^
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/gvmd-pg.dir/gmp_tickets.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/builddir/build/BUILD/gvmd-8.0-beta3/src/manage_sql.c: In function 'escalate_2':
/builddir/build/BUILD/gvmd-8.0-beta3/src/manage_sql.c:12810:24: error: 'filter' may be used uninitialized in this function [-Werror=maybe-uninitialized]
body = alert_message_print (message, event, event_data,
^
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/gvmd-pg.dir/gmp_tickets.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/builddir/build/BUILD/gvmd-8.0-beta3/src/manage_sql.c: In function 'escalate_2':
/builddir/build/BUILD/gvmd-8.0-beta3/src/manage_sql.c:12810:24: error: 'filter' may be used uninitialized in this function [-Werror=maybe-uninitialized]
body = alert_message_print (message, event, event_data,
^
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/gvmd-pg.dir/manage_sql.c.o] Error 1
make[2]: Leaving directory /builddir/build/BUILD/gvmd-8.0-beta3' make[1]: Leaving directory /builddir/build/BUILD/gvmd-8.0-beta3'
make[1]: *** [src/CMakeFiles/gvmd-pg.dir/all] Error 2
make: *** [all] Error 2

OS: CentOS 7.6

Hi I have an issue running Openvas scanner and the error is Openvas scanner is not working it shows an fix to run openvassd but I'm unable to run it. please recommend what to do on this

Expected behavior

Current behavior

Steps to reproduce

GVM versions

gsa: (gsad --version)

gvm: (gvmd --version)

openvas-scanner: (openvassd --version)

gvm-libs:

openvas-smb:

Environment

Operating system:

Installation method / source: (packages, source installation)

Logfiles

TLS failed to read from client (remote scanner)

Expected behavior

Connecting to a remote scanner (slave gvmd) listenining on an interface can be triggered by "master gvmd" running a GUI when you select the scanner within task creation.

Current behavior

I am getting the following error on the remote scanner when i start a scan on the master

event target:MESSAGE:2018-08-20 18h31.31 UTC:28662: Target 81fb7e58-5e65-4174-9066-xxxxxxxxxxxx for test03 (ad5fbf1e-1042-4d20-b854-xxxxxxxxxx) has been created by remote_host md main:WARNING:2018-08-20 18h31.31 UTC:28662: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.

when i do a downgrade to the recommended packages (latest releases) remote scanner works, but local scanning seems to have an issue there.

Once, i also added the scanner via CLI (not GUI) had even more trouble getting that thingy to rock.

Steps to reproduce

Install latest version from source on master and on remote
add a remote scanner (GMP + credentials + CA Cert)
create a scan and try to run it on the remote scanner

You will get above error message (TLS error) on the remote.
You will need to restart gvmd to interrupt the scan an be able to delte the scan

GVM versions

gsa: (gsad --version)
Greenbone Security Assistant 8.0+beta2 GIT revision 6884548aa-master

gvm: (gvmd --version)
enbone Vulnerability Manager 8.0+beta1 GIT revision 3b8ede38-master

openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0+beta2 GIT revision 2348b7a-master

gvm-libs:
latest from git

the whole build has been re-setup from scratch today.

Environment

debian stretch - up2date
Installation method / source: (packages, source installation)
source installation from git

Logfiles

gvmd.log on remote
event target:MESSAGE:2018-08-20 18h31.31 UTC:28662: Target 81fb7e58-5e65-4174-9066-xxxxxxxxxxxx for test03 (ad5fbf1e-1042-4d20-b854-xxxxxxxxxx) has been created by box911 md main:WARNING:2018-08-20 18h31.31 UTC:28662: read_from_client_tls: failed to read from client: The TLS connection was non-properly terminated.

gvmd.log on master
Task test03 (e7b59478-6534-4873-b7a7-xxxxxxxxxxxx) has been requested to start by admin

Multiple database issues with PostgreSQL 9.6

Expected behavior

No scary error messages.

Current behavior

Multiple messages in postgres log, including:

root@gvmd ERROR: relation "public.meta" does not exist at character 19
root@gvmd ERROR: duplicate key value violates unique constraint "nvt_preferences_name_key" (Key (name)=(IT-Grundschutz M4.023: Sicherer Aufruf ausführbarer Dateien[checkbox]:Alle Dateien Auflisten) already exists.)
-LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT; (on regular basis)

Steps to reproduce

Standard installation of OpenVAS with Postgres 9.6 backend.

GVM versions

gsa: (gsad --version)
Today's snapshot from Github.

gvm: (gvmd --version)
Today's snapshot from Github.

openvas-scanner: (openvassd --version)
Today's snapshot from Github.

gvm-libs:
Today's snapshot from Github.

openvas-smb:
None.

Environment

Operating system:
Debian 9 Stretch.

Installation method / source: (packages, source installation)
Build from source.

Logfiles

2018-08-27 21:09:28.714 UTC [20756] LOG:  database system was shut down at 2018-08-27 21:09:27 UTC
2018-08-27 21:09:28.716 UTC [20756] LOG:  MultiXact member wraparound protections are now enabled
2018-08-27 21:09:28.718 UTC [20755] LOG:  database system is ready to accept connections
2018-08-27 21:09:28.718 UTC [20760] LOG:  autovacuum launcher started
2018-08-27 21:09:29.192 UTC [20762] [unknown]@[unknown] LOG:  incomplete startup packet
2018-08-27 21:51:21.155 UTC [10544] root@gvmd ERROR:  relation "public.meta" does not exist at character 19
2018-08-27 21:51:21.155 UTC [10544] root@gvmd STATEMENT:  SELECT value FROM public.meta WHERE name = 'database_version';
2018-08-27 21:51:21.648 UTC [10544] root@gvmd WARNING:  column "type" has type "unknown"
2018-08-27 21:51:21.648 UTC [10544] root@gvmd DETAIL:  Proceeding with relation creation anyway.
2018-08-27 21:51:47.270 UTC [10581] root@gvmd ERROR:  duplicate key value violates unique constraint "nvt_preferences_name_key"
2018-08-27 21:51:47.270 UTC [10581] root@gvmd DETAIL:  Key (name)=(IT-Grundschutz M4.023: Sicherer Aufruf ausführbarer Dateien[checkbox]:Alle Dateien Auflisten) already exists.
2018-08-27 21:51:47.270 UTC [10581] root@gvmd STATEMENT:  INSERT into nvt_preferences (name, value) VALUES ('IT-Grundschutz M4.023: Sicherer Aufruf ausführbarer Dateien[checkbox]:Alle Dateien Auflisten', 'no');
2018-08-27 21:55:49.095 UTC [10573] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-27 21:55:49.095 UTC [10573] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-27 21:55:59.176 UTC [10573] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-27 21:55:59.176 UTC [10573] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-27 22:54:13.748 UTC [10578] root@gvmd ERROR:  relation "cert_bund_advs" does not exist at character 30
2018-08-27 22:54:13.748 UTC [10578] root@gvmd STATEMENT:  SELECT EXISTS (SELECT * FROM cert_bund_advs  WHERE creation_time        > coalesce (CAST ((SELECT value FROM meta                           WHERE name                                 = 'cert_check_time')                          AS INTEGER),                    0));
2018-08-28 08:07:57.250 UTC [19078] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 08:07:57.250 UTC [19078] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 08:10:31.964 UTC [19078] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 08:10:31.964 UTC [19078] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 08:54:14.005 UTC [19078] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 08:54:14.005 UTC [19078] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 10:09:39.311 UTC [20755] LOG:  received fast shutdown request
2018-08-28 10:09:39.311 UTC [20755] LOG:  aborting any active transactions
2018-08-28 10:09:39.311 UTC [20760] LOG:  autovacuum launcher shutting down
2018-08-28 10:09:39.315 UTC [20757] LOG:  shutting down
2018-08-28 10:09:39.336 UTC [20755] LOG:  database system is shut down
2018-08-28 10:10:18.422 UTC [670] LOG:  database system was shut down at 2018-08-28 10:09:39 UTC
2018-08-28 10:10:18.429 UTC [670] LOG:  MultiXact member wraparound protections are now enabled
2018-08-28 10:10:18.431 UTC [674] LOG:  autovacuum launcher started
2018-08-28 10:10:18.431 UTC [669] LOG:  database system is ready to accept connections
2018-08-28 10:10:18.867 UTC [712] [unknown]@[unknown] LOG:  incomplete startup packet
2018-08-28 10:17:37.364 UTC [1339] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 10:17:37.364 UTC [1339] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 10:23:03.679 UTC [1339] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 10:23:03.679 UTC [1339] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 10:32:00.030 UTC [1339] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 10:32:00.030 UTC [1339] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 10:44:18.703 UTC [1339] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 10:44:18.703 UTC [1339] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 12:08:43.193 UTC [669] LOG:  received fast shutdown request
2018-08-28 12:08:43.193 UTC [669] LOG:  aborting any active transactions
2018-08-28 12:08:43.194 UTC [674] LOG:  autovacuum launcher shutting down
2018-08-28 12:08:43.195 UTC [671] LOG:  shutting down
2018-08-28 12:08:43.243 UTC [669] LOG:  database system is shut down
2018-08-28 12:09:24.360 UTC [654] LOG:  database system was shut down at 2018-08-28 12:08:43 UTC
2018-08-28 12:09:24.366 UTC [654] LOG:  MultiXact member wraparound protections are now enabled
2018-08-28 12:09:24.368 UTC [658] LOG:  autovacuum launcher started
2018-08-28 12:09:24.368 UTC [653] LOG:  database system is ready to accept connections
2018-08-28 12:09:24.822 UTC [669] [unknown]@[unknown] LOG:  incomplete startup packet
2018-08-28 13:39:57.678 UTC [7667] postgres@postgres ERROR:  role "root" already exists
2018-08-28 13:39:57.678 UTC [7667] postgres@postgres STATEMENT:  CREATE ROLE root NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;
2018-08-28 13:39:58.240 UTC [7684] postgres@tasks ERROR:  role "dba" already exists
2018-08-28 13:39:58.240 UTC [7684] postgres@tasks STATEMENT:  create role dba with superuser noinherit; grant dba to root; create extension "uuid-ossp";
2018-08-28 13:40:14.711 UTC [7738] postgres@postgres ERROR:  role "root" already exists
2018-08-28 13:40:14.711 UTC [7738] postgres@postgres STATEMENT:  CREATE ROLE root NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;
2018-08-28 13:40:14.771 UTC [7743] postgres@postgres ERROR:  database "tasks" already exists
2018-08-28 13:40:14.771 UTC [7743] postgres@postgres STATEMENT:  CREATE DATABASE tasks OWNER root;
2018-08-28 13:40:14.848 UTC [7755] postgres@tasks ERROR:  role "dba" already exists
2018-08-28 13:40:14.848 UTC [7755] postgres@tasks STATEMENT:  create role dba with superuser noinherit; grant dba to root; create extension "uuid-ossp";
2018-08-28 15:04:05.061 UTC [10581] postgres@postgres ERROR:  database "tasks" does not exist
2018-08-28 15:04:05.061 UTC [10581] postgres@postgres STATEMENT:  DROP DATABASE tasks;
2018-08-28 15:04:43.411 UTC [10634] postgres@tasks ERROR:  role "dba" already exists
2018-08-28 15:04:43.411 UTC [10634] postgres@tasks STATEMENT:  create role dba with superuser noinherit; grant dba to root;
2018-08-28 15:11:05.622 UTC [11654] root@tasks ERROR:  relation "public.meta" does not exist at character 19
2018-08-28 15:11:05.622 UTC [11654] root@tasks STATEMENT:  SELECT value FROM public.meta WHERE name = 'database_version';
2018-08-28 15:33:20.854 UTC [12110] root@tasks ERROR:  canceling statement due to user request
2018-08-28 15:33:20.854 UTC [12110] root@tasks STATEMENT:  SELECT pg_advisory_xact_lock (1);
2018-08-28 15:33:28.875 UTC [12103] root@tasks ERROR:  duplicate key value violates unique constraint "nvt_preferences_name_key"
2018-08-28 15:33:28.875 UTC [12103] root@tasks DETAIL:  Key (name)=(Microsoft Windows: Configure registry policy processing (background processing)[radio]:Value) already exists.
2018-08-28 15:33:28.875 UTC [12103] root@tasks STATEMENT:  INSERT into nvt_preferences (name, value) VALUES ('Microsoft Windows: Configure registry policy processing (background processing)[radio]:Value', '0;1');
2018-08-28 15:35:16.168 UTC [12451] root@tasks ERROR:  canceling statement due to user request
2018-08-28 15:35:16.168 UTC [12451] root@tasks STATEMENT:  SELECT pg_advisory_xact_lock (1);
2018-08-28 15:50:56.584 UTC [653] LOG:  received fast shutdown request
2018-08-28 15:50:56.584 UTC [653] LOG:  aborting any active transactions
2018-08-28 15:50:56.584 UTC [658] LOG:  autovacuum launcher shutting down
2018-08-28 15:50:56.589 UTC [655] LOG:  shutting down
2018-08-28 15:50:56.644 UTC [653] LOG:  database system is shut down
2018-08-28 15:51:35.342 UTC [653] LOG:  database system was shut down at 2018-08-28 15:50:56 UTC
2018-08-28 15:51:35.375 UTC [653] LOG:  MultiXact member wraparound protections are now enabled
2018-08-28 15:51:35.378 UTC [657] LOG:  autovacuum launcher started
2018-08-28 15:51:35.378 UTC [652] LOG:  database system is ready to accept connections
2018-08-28 15:51:35.763 UTC [667] [unknown]@[unknown] LOG:  incomplete startup packet
2018-08-28 16:28:47.004 UTC [1807] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 16:28:47.004 UTC [1807] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 16:36:39.134 UTC [1807] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 16:36:39.134 UTC [1807] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 16:44:38.367 UTC [652] LOG:  received fast shutdown request
2018-08-28 16:44:38.367 UTC [652] LOG:  aborting any active transactions
2018-08-28 16:44:38.367 UTC [657] LOG:  autovacuum launcher shutting down
2018-08-28 16:44:38.369 UTC [654] LOG:  shutting down
2018-08-28 16:44:38.428 UTC [652] LOG:  database system is shut down
2018-08-28 16:45:19.419 UTC [655] LOG:  database system was shut down at 2018-08-28 16:44:38 UTC
2018-08-28 16:45:19.426 UTC [655] LOG:  MultiXact member wraparound protections are now enabled
2018-08-28 16:45:19.428 UTC [659] LOG:  autovacuum launcher started
2018-08-28 16:45:19.428 UTC [654] LOG:  database system is ready to accept connections
2018-08-28 16:45:19.879 UTC [669] [unknown]@[unknown] LOG:  incomplete startup packet
2018-08-28 17:12:14.541 UTC [8528] root@gvmd ERROR:  duplicate key value violates unique constraint "nvt_preferences_name_key"
2018-08-28 17:12:14.541 UTC [8528] root@gvmd DETAIL:  Key (name)=(IT-Grundschutz M5.009: Protokollierung am Server[checkbox]:Alle Logfile-Einträge Auflisten) already exists.
2018-08-28 17:12:14.541 UTC [8528] root@gvmd STATEMENT:  INSERT into nvt_preferences (name, value) VALUES ('IT-Grundschutz M5.009: Protokollierung am Server[checkbox]:Alle Logfile-Einträge Auflisten', 'no');
2018-08-28 17:22:34.433 UTC [13935] root@gvmd LOG:  could not receive data from client: Connection reset by peer
2018-08-28 17:22:34.433 UTC [13935] root@gvmd LOG:  unexpected EOF on client connection with an open transaction
2018-08-28 17:25:17.049 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:25:17.049 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:25:29.062 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:25:29.062 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:25:41.057 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:25:41.057 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:27:04.094 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:27:04.094 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:27:16.055 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:27:16.055 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:28:16.060 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:28:16.060 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:32:24.158 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:32:24.158 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:33:00.552 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:33:00.552 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:36:22.143 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:36:22.143 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:39:52.444 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:39:52.444 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:41:31.391 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:41:31.391 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:42:22.444 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:42:22.444 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:42:42.520 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:42:42.520 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:47:31.428 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:47:31.428 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:48:00.375 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:48:00.375 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 17:52:57.343 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 17:52:57.343 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;
2018-08-28 18:02:42.287 UTC [13988] root@gvmd ERROR:  could not obtain lock on relation "reports"
2018-08-28 18:02:42.287 UTC [13988] root@gvmd STATEMENT:  LOCK table reports IN ACCESS EXCLUSIVE MODE NOWAIT;

"(Perhaps the db went down?)"

Expected behavior

Normal openvas scans to finish.

Current behavior

Normal openvas scan is created and started through "gvm-cli socket" commands with <create_target>, <create_task>, <start_task>.

Then, sometimes, the scan will halt/freeze and gvm-cli cannot even authenticate to openvasmd and the openvasmd.log will spew out errors endlessly (see below).

The openvassd is stuck (always at host_details.nasl):

19866 ? SN 0:00 | \_ openvassd: testing x.x.x.x (/usr/local/var/lib/openvas/plugins/2011/host_details.nasl)

gvm-cli socket -c --xml "<get_version/>" (and all other "gvm-cli socket" commands) will respond with errors:

Traceback (most recent call last):
  File "/usr/local/bin/gvm-cli", line 11, in <module>
    load_entry_point('gvm-tools==1.4.1', 'console_scripts', 'gvm-cli')()
  File "/usr/local/lib/python3.6/dist-packages/gmp/clients/gvm_cli.py", line 212, in main
    gvm.authenticate(args.gmp_username, args.gmp_password)
  File "/usr/local/lib/python3.6/dist-packages/gmp/gvm_connection.py", line 220, in authenticate
    return self.read()
  File "/usr/local/lib/python3.6/dist-packages/gmp/gvm_connection.py", line 103, in read
    response = self.readAll()
  File "/usr/local/lib/python3.6/dist-packages/gmp/gvm_connection.py", line 967, in readAll
    data = self.sock.recv(BUF_SIZE)
ConnectionResetError: [Errno 104] Connection reset by peer

The only resolution seems to be to restart openvasmd and openvassd, or restart the server platform, by which of course the scan is trashed and must be repeated.

Restarting the redis-server by itself has no effect.

GVM versions

gsa: (gsad --version)
Not in use.

gvm: (gvmd --version)
~$ openvasmd --version
OpenVAS Manager 7.0.4
GIT revision 1bbda35-openvas-manager-7.0
Manager DB revision 184

openvas-scanner: (openvassd --version)
OpenVAS Scanner 5.1.3

gvm-libs:
~/gvm-libs$ git log
commit db1306c117df6dde5324b75cb4517b2382a5ba98 (HEAD -> openvas-libraries-9.0, origin/openvas-libraries-9.0)

openvas-smb:

Environment

Operating system:
$ uname -a
Linux xxx 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Installation method / source:
(source installation)

Logfiles

/usr/local/var/log/openvas/openvasmd.log repeats the following over and over again:

md manage:WARNING:2018-10-04 14h48.40 utc:17917: sql_exec_internal: sqlite3_step failed: cannot start a transaction within a transaction
md manage:WARNING:2018-10-04 14h48.40 utc:17917: sqlv: sql_exec_internal failed
md manage:WARNING:2018-10-04 14h48.40 utc:17917: manage_schedule: manage_update_nvti_cache error (Perhaps the db went down?)
md manage:WARNING:2018-10-04 14h48.41 utc:22606: sql_exec_internal: sqlite3_step failed: interrupted
md manage:WARNING:2018-10-04 14h48.41 utc:22606: sqlv: sql_exec_internal failed
...

PostgreSQL error due to usage of reserved keyword

Expected behavior

Lists of tasks displaying severity and no PostgreSQL error

Current behavior

Tasks are working fine, I can see results of reports but every task is showing internal error as level of severity for last report.

Steps to reproduce

Start a task and wait for it to end
Catch logs at /var/log/postgresql/postgresql-9.6-main.log

Logs

2019-03-08 17:35:03.833 CET [2773] root@tasks ERREUR: l’opérateur n’existe pas : name = integer au caractère 84
2019-03-08 17:35:03.833 CET [2773] root@tasks ASTUCE : Aucun opérateur ne correspond au nom donné et aux types d’arguments.
Vous devez ajouter des conversions explicites de type.
2019-03-08 17:35:03.833 CET [2773] root@tasks INSTRUCTION : SELECT max(severity) FROM report_counts WHERE report = 8 AND override = 1 AND user = (SELECT id FROM users WHERE uuid = ‘cb9ea5dd-70da-410c-aa69-533dc138802b’) AND min_qod = 70 AND (end_time = 0 or end_time >= m_now ());

So I found out that the problem occurs when the keyword user is used because it's a reserved keyword and should not be used in data scheme.

When I enter manually in my database the following request, with "user" instead of user

SELECT max(severity) FROM report_counts WHERE report = 8 AND override = 1 AND “user” = (SELECT id FROM users WHERE uuid = ‘cb9ea5dd-70da-410c-aa69-533dc138802b’) AND min_qod = 70 AND (end_time = 0 or end_time >= m_now ());

I have no error.

[7.0.3] Unable to export user credentials for remote login as an rpm package.

When I try to create the rpm package under the gsa for remote log in I only get an rpm package with 0 bytes.
Let the openvas manger run in debug mode, then an error will shown, that the create process of the rpm package will fails with:

md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_recreate: rpm_path: /tmp/rpm_4oI5X3/p.rpm
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: create temporary directory
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: temporary directory: /tmp/lsc_user_rpm_create_7c63Ku
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: copy key to temporary directory
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: Attempting RPM build
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: Spawning in /usr/share/openvas: ./openvas-lsc-rpm-creator.sh --target /tmp/lsc_user_rpm_create_7c63Ku /tmp/lsc_user_rpm_create_7c63Ku/openvas_scanner.pub
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: failed to create the rpm: 256 (WIF 1, WEX 1)
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: stdout: Verifying archive integrity... All good.
Uncompressing OpenVAS LSC RPM creator.........................................
LC_ALL=C ls | egrep -v ".spec" | diff MANIFEST - | grep "^>" | sed 's/^..//' | xargs rm -rf
echo Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in
Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in
mkdir openvas-lsc-target-openvas_scanner-0.5
cp -ar Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in openvas-lsc-target-openvas_scanner-0.5/
tar cfzv openvas-lsc-target-openvas_scanner-0.5.tar.gz openvas-lsc-target-openvas_scanner-0.5
openvas-lsc-target-openvas_scanner-0.5/
openvas-lsc-target-openvas_scanner-0.5/openvas-lsc-target.spec.in
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/makeself.sh.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/makeself.lsm.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/TODO.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/makeself-header.sh.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/makeself.1.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/COPYING.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/text-base/README.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/prop-base/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/prop-base/makeself.sh.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/prop-base/makeself-header.sh.svn-base
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/props/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/tmp/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/tmp/text-base/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/tmp/prop-base/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/tmp/props/
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/entries
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/.svn/format
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/makeself.sh
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/makeself.lsm
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/TODO
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/makeself-header.sh
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/makeself.1
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/COPYING
openvas-lsc-target-openvas_scanner-0.5/makeself-2.1.5/README
openvas-lsc-target-openvas_scanner-0.5/lsc-pubkey.pub
openvas-lsc-target-openvas_scanner-0.5/create-rpm.sh
openvas-lsc-target-openvas_scanner-0.5/configure
openvas-lsc-target-openvas_scanner-0.5/VERSION
openvas-lsc-target-openvas_scanner-0.5/TODO
openvas-lsc-target-openvas_scanner-0.5/RPMBASENAME
openvas-lsc-target-openvas_scanner-0.5/README
openvas-lsc-target-openvas_scanner-0.5/PUBKEYNAME
openvas-lsc-target-openvas_scanner-0.5/NAME
openvas-lsc-target-openvas_scanner-0.5/Makefile
openvas-lsc-target-openvas_scanner-0.5/MANIFEST
openvas-lsc-target-openvas_scanner-0.5/Changelog
rm -rf openvas-lsc-target-openvas_scanner-0.5
mkdir SOURCES
mkdir RPMS
mkdir BUILD
mv openvas-lsc-target-openvas_scanner-0.5.tar.gz SOURCES/
Building target platforms: noarch
Building for target noarch
md manage: DEBUG:2018-04-16 07h01.26 UTC:36973: lsc_user_rpm_create: stderr: Creating directory /tmp/lsc_user_rpm_create_7c63Ku
error: line 41: second %install
cp: cannot stat ‘RPMS/noarch/*.rpm’: No such file or directory

Call the package creation script via hand will also fail:
mkdir /tmp/X
touch /tmp/X/sample-key.pub
/usr/share/openvas/openvas-lsc-rpm-creator.sh --target /tmp/X /tmp/X/sample-key.pub

Creating directory /tmp/X
Verifying archive integrity... All good.
Uncompressing OpenVAS LSC RPM creator.........................................
LC_ALL=C ls | egrep -v ".spec" | diff MANIFEST - | grep "^>" | sed 's/^..//' | xargs rm -rf
echo Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in
Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in
mkdir openvas-lsc-target-sample-key-0.5
cp -ar Changelog MANIFEST Makefile NAME PUBKEYNAME README RPMBASENAME TODO VERSION configure create-rpm.sh lsc-pubkey.pub makeself-2.1.5 openvas-lsc-target.spec.in openvas-lsc-target-sample-key-0.5/
tar cfzv openvas-lsc-target-sample-key-0.5.tar.gz openvas-lsc-target-sample-key-0.5
openvas-lsc-target-sample-key-0.5/
openvas-lsc-target-sample-key-0.5/openvas-lsc-target.spec.in
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/makeself.sh.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/makeself.lsm.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/TODO.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/makeself-header.sh.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/makeself.1.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/COPYING.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/text-base/README.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/prop-base/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/prop-base/makeself.sh.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/prop-base/makeself-header.sh.svn-base
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/props/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/tmp/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/tmp/text-base/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/tmp/prop-base/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/tmp/props/
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/entries
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/.svn/format
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/makeself.sh
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/makeself.lsm
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/TODO
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/makeself-header.sh
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/makeself.1
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/COPYING
openvas-lsc-target-sample-key-0.5/makeself-2.1.5/README
openvas-lsc-target-sample-key-0.5/lsc-pubkey.pub
openvas-lsc-target-sample-key-0.5/create-rpm.sh
openvas-lsc-target-sample-key-0.5/configure
openvas-lsc-target-sample-key-0.5/VERSION
openvas-lsc-target-sample-key-0.5/TODO
openvas-lsc-target-sample-key-0.5/RPMBASENAME
openvas-lsc-target-sample-key-0.5/README
openvas-lsc-target-sample-key-0.5/PUBKEYNAME
openvas-lsc-target-sample-key-0.5/NAME
openvas-lsc-target-sample-key-0.5/Makefile
openvas-lsc-target-sample-key-0.5/MANIFEST
openvas-lsc-target-sample-key-0.5/Changelog
rm -rf openvas-lsc-target-sample-key-0.5
mkdir SOURCES
mkdir RPMS
mkdir BUILD
mv openvas-lsc-target-sample-key-0.5.tar.gz SOURCES/
Building target platforms: noarch
Building for target noarch
error: line 41: second %install
cp: cannot stat ‘RPMS/noarch/*.rpm’: No such file or directory

The problem is the rpm macro in the commend block:
less /tmp/X/openvas-lsc-target.spec:
line 41:

%install section... do it now, and then disable it,

This line must be:

%%install section... do it now, and then disable it,

Because the script contains binary data and the source of it is missing in the git repo I can't create an patch for it.

[8.0.0-beta1] compile error utils.c on CentOS7

The build will fails with:
/usr/lib64/ccache/cc -DCACERT="/var/lib/gvm/CA/cacert.pem" -DCA_DIR="/var/lib/gvm/gvmd/trusted_certs" -DCLIENTCERT="/var/lib/gvm/CA/clientcert.pem" -DCLIENTKEY="/var/lib/gvm/private/CA/clientkey.pem" -DGMP_VERSION="8.0" -DGVMD_CERT_DATABASE_VERSION=6 -DGVMD_DATABASE_VERSION=191 -DGVMD_DATA_DIR="/usr/share/gvm/gvmd" -DGVMD_SCAP_DATABASE_VERSION=15 -DGVMD_STATE_DIR="/var/lib/gvm/gvmd" -DGVMD_VERSION="8.0+beta1" -DGVM_CERT_DATA_DIR="/var/lib/gvm/cert-data" -DGVM_CERT_RES_DIR="/usr/share/gvm/cert" -DGVM_DATA_DIR="/usr/share/gvm" -DGVM_LIB_INSTALL_DIR="/usr/lib" -DGVM_LOG_DIR="/var/log/gvm" -DGVM_NVT_DIR="/var/lib/openvas/plugins/" -DGVM_OS_NAME="Linux-3.10.0-862.6.3.el7.x86_64" -DGVM_RUN_DIR="/var/run" -DGVM_SCAP_DATA_DIR="/var/lib/gvm/scap-data" -DGVM_SCAP_RES_DIR="/usr/share/gvm/scap" -DGVM_SQLITE_SLEEP_MAX=0 -DGVM_STATE_DIR="/var/lib/gvm" -DGVM_SYSCONF_DIR="/etc/gvm" -DPREFIX="/usr" -DSBINDIR="/usr/sbin" -DSCANNERCERT="/var/lib/gvm/CA/servercert.pem" -DSCANNERKEY="/var/lib/gvm/private/CA/serverkey.pem" -I/usr/include/gvm -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/builddir/build/BUILD/gvm-8.0-beta1/helper/usr/include -I/usr/include/uuid -I/usr/include/p11-kit-1 -I/usr/pgsql-10/include/server -I/usr/pgsql-10/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wall -D_BSD_SOURCE -D_ISOC99_SOURCE -D_SVID_SOURCE -D_DEFAULT_SOURCE -D_FILE_OFFSET_BITS=64 -g -Werror -o CMakeFiles/manage.dir/utils.c.o -c /builddir/build/BUILD/gvm-8.0-beta1/src/utils.c
/builddir/build/BUILD/gvm-8.0-beta1/src/utils.c:69:3: error: implicit declaration of function 'nanosleep' [-Werror=implicit-function-declaration]
while ((ret = nanosleep (requested, remaining)) && (errno == EINTR))
^
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/manage.dir/utils.c.o] Error 1

In the git master the code are the same.

[5.1.2] Error while verifying the OpenVAS scanner

When the scanner are verified by the manager then errors will be logged.

call openvasmd --get-scanners
08b69003-5fc2-4037-a479-93b440211c73 OpenVAS Default
6acd0832-df90-11e4-b9d5-28d24461215b CVE
call openvasmd --verify-scanner 08b69003-5fc2-4037-a479-93b440211c73:
Scanner version: OTP/2.0.
But in the openvassd log this will show:
[6484] nsend():send Broken pipe
Client not present

openvas use masscan only , thats had no data found

Expected behavior

masscan could be used and the found data could be inserted into database

Current behavior

masscan could be used but the found data could not be inserted into database

Steps to reproduce

scan config -->choose port scanner--> choose masscan only
choose target one ip
creat one target

GVM versions

gsa: (gsad --version)
Greenbone Security Assistant 8.0+beta3
Copyright (C) 2010-2016 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0+beta2
Manager DB revision 200
Copyright (C) 2010-2017 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0+beta3
Most new code since 2005: (C) 2018 Greenbone Networks GmbH
Nessus origin: (C) 2004 Renaud Deraison [email protected]
License GPLv2: GNU GPL version 2
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gvm-libs:

openvas-smb:

Environment

Operating system:

Installation method / source: (packages, source installation)

Logfiles

verify_report_format throws error for predefined report formats

Expected behavior

When I click on "Verify Report Format" in RF-listpage for predefined RFs, I would expect either a message telling me that predefined ones can't be verified, or even better, do not allow me to click the button in the first place.

Current behavior

I get the error message "Failed to find report format '5057e5cc-b825-11e4-9d0e-28d24461215b'" (this is Anonymous XML).

Steps to reproduce

Click on Verify Report Format on ReportFormat listpage
Profit

GVM versions

gsa: (gsad --version)
current master
gvm: (gvmd --version)
current master

Solution option

Could be handled by GSA, if gvmd returns something like the tag in the xml. Maybe or something like that.

Resource temporarily unavailable

Expected behavior

I should be able to rebuild and update the cache (openvasmd --update --progress && openvasmd --rebuild --progress) and start the openvas-scanner.

Current behavior

I am not able to update or rebuild the cache via openvasmd nor I am able to restart the openvas-scanner.

When I try to update or rebuild the cache the whole process just hangs. When I attach strace to the process I get the following messages in an infinite loop:

select(17, [16], [], NULL, {tv_sec=0, tv_usec=822418}) = 0 (Timeout)
recvfrom(16, 0x7ffcaa7d20ff, 1, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
select(17, [16], [], NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
recvfrom(16, 0x7ffcaa7d20ff, 1, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
select(17, [16], [], NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
recvfrom(16, 0x7ffcaa7d20ff, 1, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
select(17, [16], [], NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
recvfrom(16, 0x7ffcaa7d20ff, 1, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)

I have no idea what is happening here. In the logs I can find the following events in the openvasmd.log:

The first bad message is this one here:

md manage:WARNING:2019-02-26 18h07.15 utc:13695: sql_exec_internal: sqlite3_step failed: cannot start a transaction within a transaction
md manage:WARNING:2019-02-26 18h07.15 utc:13695: sqlv: sql_exec_internal failed
[...]
md manage:WARNING:2019-02-26 18h07.15 utc:13695: sql_exec_internal: sqlite3_step failed: cannot start a transaction within a transaction
md manage:WARNING:2019-02-26 18h07.15 utc:13695: sqlv: sql_exec_internal failed
md manage:WARNING:2019-02-26 18h07.15 utc:13695: manage_schedule: manage_update_nvti_cache error (Perhaps the db went down?)
md manage:WARNING:2019-02-26 18h07.25 utc:13695: sql_exec_internal: sqlite3_step failed: cannot start a transaction within a transaction
md manage:WARNING:2019-02-26 18h07.25 utc:13695: sqlv: sql_exec_internal failed
[...]

Today I have restarted the service and it looks like this:

d   main:MESSAGE:2019-02-27 11h06.19 utc:2660:    OpenVAS Manager version 7.0.3 (DB revision 184)
md manage:   INFO:2019-02-27 11h06.19 utc:2660:    Getting users.
md   main:MESSAGE:2019-02-27 11h06.25 utc:2661:    OpenVAS Manager version 7.0.3 (DB revision 184)
md   main:   INFO:2019-02-27 11h06.25 utc:2661: rebuild_nvt_cache_retry: Reloading NVT cache
md   main:   INFO:2019-02-27 11h06.25 utc:2662: update_or_rebuild_nvt_cache: Updating NVT cache
base gpgme:MESSAGE:2019-02-27 11h06.25 utc:2662: Setting GnuPG dir to '/var/lib/openvas/openvasmd/gnupg'
base gpgme:MESSAGE:2019-02-27 11h06.25 utc:2662: Using OpenPGP engine version '2.2.4'
md   main:   INFO:2019-02-27 11h06.25 utc:2662:    Updating NVT cache.

When I try to start the scanner it just times out without any error message in the logs.

Steps to reproduce

Install OpenVAS on Ubuntu 18.04 via PPA
do a few scans
wait a few days.. (sorry no Idea how to reproduce this :( )

GVM versions

gsa: 7.0.3

gvm: 7.0.3

openvas-scanner: 5.1.3

gvm-libs: 9.0.3

openvas-smb: not existent?

Environment

Operating system: Ubuntu 18.04

Installation method / source: (packages, source installation) PPA

Logfiles

See logs above

[7.0.2] SQL Warning when verify the CVE scanner via gsa

When the function for verifying the CVE scanner is called, an SQL warning will thrown:

md manage:WARNING:2018-02-14 11h46.14 UTC:9969: sql_close: attempt to close db with open statement(s)

sql_exec_internal: sqlite3_step failed: error in view result_overrides: no such table: main.reports_196

To avoid that this gets lost:

Expected behavior

gvmd --migrate is running a successful migration

Current behavior

gvmd --migrate fails to execute a migration step

Steps to reproduce

Have a working Greenbone Vulnerability Manager version 8.0+beta1 setup with a database_version|197
Upgrade to current master branch aa88aec
Run gvmd --migrate

GVM versions

gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0+beta1
GIT revision aa88aec-master
Manager DB revision 200

Database backend: SQLite

Logfiles

md   main:MESSAGE:2018-11-26 15h12.42 utc:3099:    Greenbone Vulnerability Manager version 8.0+beta1 (GIT revision aa88aece-master) (DB revision 200)
md   main:   INFO:2018-11-26 15h12.42 utc:3099:    Migrating database.
md   main:   INFO:2018-11-26 15h12.42 utc:3099:    Migrating to 198
md manage:WARNING:2018-11-26 15h12.42 utc:3099: sql_exec_internal: sqlite3_step failed: error in view result_overrides: no such table: main.reports_196
md manage:WARNING:2018-11-26 15h12.42 utc:3099: sqlv: sql_exec_internal failed

[7.0.2] no ip will logged when log in with in invalid user/wrong pasword

When try to login with in invalid user or password then in the log file only the dummy value is logged as the source ip.

md omp:WARNING:2018-03-06 08h38.20 utc:1876: Authentication failure for 'inavlid' from 900::900:0:0:0

Config for the log:

[md    omp]
prepend=%t %p
prepend_time_format=%Y-%m-%d %Hh%M.%S %Z
file=/var/log/openvas/openvasmd.log
level=16

Validate timezone settings

The topic https://community.greenbone.net/t/modify-setting-api/671 in our user forum did spot an issues with setting the user timezone. It is possible to lock out the user completely by passing an invalid timezone string to modify_settings command e.g.

<modify_settings>
<name>Timezone</name>
<value>Foo</name>
</modify_settings>

Expected behavior

The <modify_settings> command should fail if the passed timezone isn't a valid base64 encoded timezone (or just not a valid base64 encoded timezone string).

Current behavior

It's possible to lock out the user from gvmd by passing a non valid base64 encoded string as timezone value. As a result the response to the command returns invalid xml.

Steps to reproduce

Issue a <modify_settings> command with gvm-cli

<modify_setting><name>Timezone</name><value>Europe/Berlin</value></modify_setting>

Try to authenticate
An invalid xml is returned because the non base64 string will be base64 decoded.

[7.0.3] openvas-lsc-rpm-creator.sh should not use md5 as hash algorithm.

call openvas-lsc-rpm-creator.sh --check
will result in:

Verifying archive integrity... MD5 checksums are OK. All good.

For security reasons md5 must replaced by sha-2. Like sha-512

sql_exec_internal: sqlite3_step failed: interrupted

Expected behavior

Current behavior

Steps to reproduce

GVM versions

gsa: (gsad --version)

gvm: (gvmd --version)

openvas-scanner: (openvassd --version)

gvm-libs:

openvas-smb:

Environment

Operating system:

Installation method / source: (packages, source installation)

Logfiles

No signed tarball for gvm / openvas-manager 7.0.3

Hello,
Can you please provide a signed tarball for openvas-manager 7.0.3? Thanks

Bad xml in nvts?

Hi,

Not sure if this should be reported here, but when querying nvt data over socket with tools gvm-cli and gvm-pyshell, I get errors which I suspect are caused by bad xml in nvt data.
Am I right, or is there something missing in my environment?

NB this only happens when querying some nvts from some of the IT-Grundschutz-* families.

$ gvm-cli socket -c --xml "<get_nvts nvt_oid=\"1.3.6.1.4.1.25623.1.0.94018\" details=\"1\" />"
'utf-8' codec can't decode byte 0xc3 in position 1023: unexpected end of data

And inside the gvm-pyshell, I get:

$ gvm-pyshell socket -c -i
badnvt = gmp.get_nvts(nvt_oid="1.3.6.1.4.1.25623.1.0.94018", details="1")
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/gmp/gvm_connection.py", line 525, in get_nvts
    return self.read()
  File "/usr/local/lib/python3.5/dist-packages/gmp/gvm_connection.py", line 99, in read
    self.checkCommandStatus(response)
  File "/usr/local/lib/python3.5/dist-packages/gmp/gvm_connection.py", line 136, in checkCommandStatus
    status = root.attrib['status']
AttributeError: 'NoneType' object has no attribute 'attrib'

/usr/local/var/log/gvm/gvmd.log:
md main:WARNING:2018-04-15 13h24.00 UTC:10287: read_from_client_unix: failed to read from client: Connection reset by peer

$ gvm-cli --version
gvm-cli 1.3.1

$ gvm-pyshell --version
gvm-pyshell 1.3.1

$ gvmd --version
Greenbone Vulnerability Manager 7.1+beta1
Manager DB revision 190

$ openvassd --version
OpenVAS Scanner 5.2+beta1

$ python3 --version
Python 3.5.2

Credential username can be created with underscore character but credential can't be used

Expected behavior

I would like to use my AD (active directory) account which contains an underscore, to performed credentialed (authenticated) scans.

Minimally I should be prevented from entering the credentials and saving it to avoid confusion if special characters are truly not allowed.

If special characters are not allowed (unlike other tools that leverage AD credentials) than I'll need to change my service account username or possible create another account.

Current behavior

I'm allowed to create the credentials with no error, but the authenticated scan fails (without disclosing why in the PDF report).
Going back to edit the password for the credential, I'm then warned that I can't use special characters in the username. May be related to: #185

Steps to reproduce

Created username with underscore character in the credentials section of OpenVAS. 'Configuration' --> 'Credentials' --> 'new credential' button. save it.
try to edit credential (receive warning about credential containing special characters.

GVM versions

gsa: (gsad --version)
7.0.3

gvm: (gvmd --version)
'command not found'
openvas-scanner: (openvassd --version)
5.1.3

gvm-libs:

openvas-smb:

Environment

Operating system: Kali Linux on VMware workstation 12

Installation method / source: (packages, source installation)
Download from Offensive security (VMware tools version of Kali)

Logfiles

Export PDF - broken

Expected behavior

PDF Export

Actual behavior

does not show the result.

Scan:

Broken PDF, error in the summary?

This document reports on the results of an automatic security scan. All dates are displayed using the timezone �America/SaoP aulo00, whichisabbreviated“ − 0300.T hetaskwas“Scan − Samaritano −
AllV alids00.T hescanstartedatMonF eb2521 : 20 : 052019 − 03andendedatMonF eb2522 : 00 : 202019 −
03.T hereportf irstsummarisestheresultsfound.T hen, foreachhost, thereportdescribeseveryissuefound.P leaseconsidertheadvicegivenineachdescription, inordertorectif ytheissue.

Texlive Installed:

Steps to reproduce

export to PDF

GVM versions

gsa: (gsad --version)

# gsad --version
Greenbone Security Assistant 9.0+alpha~git-4d71cc189-master
GIT revision 4d71cc189-master

gvm: (gvmd --version)

# gvmd --version
Greenbone Vulnerability Manager 9.0+alpha~git-b6d078e6-master
GIT revision b6d078e6-master
Manager DB revision 206

openvas-scanner: (openvassd --version)

# openvassd --version
OpenVAS Scanner 6.0+beta3
GIT revision 3e87367-master

gvm-libs:
git - checkout: 61ae9c01880fe120ad6f49c73c588a6c3927858f

Environment

Operating system:

# cat /etc/debian_version
9.7

https://cloud.docker.com/u/dgiorgio/repository/docker/dgiorgio/openvas-source
tag: master-2.4.3

Installation method / source: (packages, source installation)

Logfiles

No logs.

Reference to dropped create-credentials-encryption-key in INSTALL

The https://github.com/greenbone/gvmd/blob/master/INSTALL.md file currently contains the following statement:

gvmd --create-credentials-encryption-key

It seems this was dropped some time ago with 10f0632 and the text should be updated accordingly to point out that the manager needs to be restarted to re-generate the keys.

See: https://community.greenbone.net/t/cant-create-new-credential-encryption-key-via-openvasmd/1019/4

openvasmd will not tell the truth about scanners and more!

After an update (on release branches) of python-gvm, gvm-tools, gvm-libs, gvmd, openvas-scanner, gasd, it looks like openvasmd is not returning valid answers to gvm-cli, gsa/gsad and gvm-pyshell.

Command "openvasmd --get-scanners" will return valid data on openvassd scanners, whereas command 'gvm-cli socket -c --xml "<get_scanners/>"' returns data about 0 (zero) scanners .

Same goes for gsa, which show an empty scanners page (Configuration > Scanners).

And, "gvm-pyshell socket -c -i" gmp.get_scanners() also returns zero scanner count
<scanner_count>0<filtered>0</filtered><page>0</page></scanner_count>

To reproduce:
Query for active scanners with openvasmd (openvasmd.log output included):

$ sudo openvasmd --get-scanners
08b69003-5fc2-4037-a479-93b440211c73  OpenVAS Default
6acd0832-df90-11e4-b9d5-28d24461215b  CVE

md   main:MESSAGE:2018-11-08 15h29.41 utc:15493:    OpenVAS Manager version 7.0.4 (GIT revision 26b72751-openvas-manager-7.0) (DB revision 184)
md manage:   INFO:2018-11-08 15h29.41 utc:15493:    Getting scanners.

However, same query over "gvm-cli socket --xml" will receive 0 scanners (openvasmd.log output included):

$ gvm-cli socket -c --xml "<get_scanners/>"
<get_scanners_response status="200" status_text="OK"><filters id=""><term>first=1 rows=1000 sort=name</term><keywords><keyword><column>first</column><relation>=</relation><value>1</value></keyword><keyword><column>rows</column><relation>=</relation><value>1000</value></keyword><keyword><column>sort</column><relation>=</relation><value>name</value></keyword></keywords></filters><sort><field>name<order>ascending</order></field></sort><scanners start="1" max="1000"/>**<scanner_count>0<filtered>0</filtered><page>0</page></scanner_count>**</get_scanners_response>

md   main:  DEBUG:2018-11-08 15h32.34 utc:15498:    Serving OMP.
md   main:  DEBUG:2018-11-08 15h32.34 utc:15498: <= client  Input may contain password, suppressed.
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498: -> client: <authenticate_response status="200" status_text="OK"><role>Admin</role><timezone>UTC</timezone><severity>nist</severity></authenticate_response>
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498: => client  144 bytes
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498: => client  done
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498: <= client  "<get_scanners/>"
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498: -> client: <get_scanners_response status="200" status_text="OK">
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498: -> client: <filters id=""><term>first=1 rows=1000 sort=name</term><keywords><keyword><column>first</column><relation>=</relation><value>1</value></keyword><keyword><column>rows</column><relation>=</relation><value>1000</value></keyword><keyword><column>sort</column><relation>=</relation><value>name</value></keyword></keywords></filters><sort><field>name<order>ascending</order></field></sort><scanners start="1" max="1000"/><scanner_count>0<filtered>0</filtered><page>0</page></scanner_count></get_scanners_response>
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498: => client  560 bytes
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498: => client  done
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498:    EOF reading from client.
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498:    Cleaning up.
md   main:  DEBUG:2018-11-08 15h32.34 UTC:15498:    Exiting.

Now, reverting back to a commit from Sep. 14th, and rebuilding, all will work normally:

~/gvmd$ git checkout 210d8d0d2634a2918879c108320d16845d52b447
~/gvmd$ rm -r build
~/gvmd$ mkdir build
~/gvmd$ cd build
~/gvmd$ cmake ..
~/gvmd$ make
~/gvmd$ sudo make install
~/gvmd$ make rebuild_cache
~/gvmd$ sudo killall openvasmd
~/gvmd$ sudo /usr/local/sbin/openvasmd --unix-socket=/usr/local/var/run/gvmd.sock

~$ gvm-cli socket -c --xml "<get_scanners/>"
<get_scanners_response status="200" status_text="OK"><scanner id="6acd0832-df90-11e4-b9d5-28d24461215b"><owner><name></name></owner><name>CVE</name><comment></comment><creation_time>2018-11-06T20:14:28Z</creation_time><modification_time>2018-11-06T20:14:28Z</modification_time><writable>1</writable><in_use>0</in_use><permissions></permissions><user_tags><count>0</count></user_tags><host></host><port>0</port><type>3</type><ca_pub></ca_pub><credential id=""><name></name><trash>0</trash></credential></scanner><scanner id="08b69003-5fc2-4037-a479-93b440211c73"><owner><name></name></owner><name>OpenVAS Default</name><comment></comment><creation_time>2018-11-06T20:14:28Z</creation_time><modification_time>2018-11-06T20:14:28Z</modification_time><writable>1</writable><in_use>0</in_use><permissions></permissions><user_tags><count>0</count></user_tags><host>/usr/local/var/run/openvassd.sock</host><port>0</port><type>2</type><ca_pub></ca_pub><credential id=""><name></name><trash>0</trash></credential></scanner><filters id=""><term>first=1 rows=1000 sort=name</term><keywords><keyword><column>first</column><relation>=</relation><value>1</value></keyword><keyword><column>rows</column><relation>=</relation><value>1000</value></keyword><keyword><column>sort</column><relation>=</relation><value>name</value></keyword></keywords></filters><sort><field>name<order>ascending</order></field></sort><scanners start="1" max="1000"/><scanner_count>0<filtered>0</filtered><page>2</page></scanner_count></get_scanners_response>

GVM versions

gsa: (gsad --version)
Greenbone Security Assistant 7.0.4
GIT revision 293cf3c7f-gsa-7.0

gvm: (gvmd --version) / openvasmd --version
~$ openvasmd --version
OpenVAS Manager 7.0.4
GIT revision 26b7275-openvas-manager-7.0
Manager DB revision 184

openvas-scanner: (openvassd --version)
OpenVAS Scanner 5.1.3

gvm-libs:
git log:
commit db1306c117df6dde5324b75cb4517b2382a5ba98 (HEAD -> openvas-libraries-9.0, origin/openvas-libraries-9.0)

Environment

Operating system:
$ uname -a
Linux sknr1 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Description: Ubuntu 18.04.1 LTS

Installation method / source: (packages, source installation)
From source.

gvm-portnames-update has a hardcoded old db name (tasks)

Default database name has been changed to 'gvmd' in GVM-10, but the script still uses the hard-coded old name ('tasks') for PostgreSQL.

if [ $POSTGRES -eq 1 ] then SQL="psql -v ON_ERROR_STOP=1 -q --pset pager=off --no-align -d tasks -t" else TASKS_DB="$DB_DIR/tasks.db" if [ ! -f $TASKS_DB ]; then echo "$TASKS_DB not found. Rebuild DB before updating port names."; exit 1; fi SQL="sqlite3 $TASKS_DB" fi

Error during scanning https target.

I'm trying to scan an https target protected by Datapower. The .cert and .key files were generated inside Datapower and the pkcs file, was generated with openssl. Can you tell me how may I import the pkcs12 file in command line please? version:Openvas 9 so:Fedora24

Failed to start Open Vulnerability Assessment System Scanner Demon

Expected behavior

Scanner services booting when openvas-start is entered in the terminal.

Current behavior

The service doesn't start and thus scanning isn't possible.

Steps to reproduce

GVM versions

gsa: (gsad --version)
Greenbone Security Assistant 7.0.3

gvm: (gvmd --version)

openvas-scanner: (openvassd --version)
OpenVAS Scanner 5.1.3
gvm-libs:

openvas-smb:

Environment

Operating system:
Kali Linux
Installation method / source: (packages, source installation)
apt-get install openvas

Logfiles

No logs found

Cannot use space in username

Expected behavior

Successfully create a new credential with a space in the username.

Current behavior

(Status code: 400) Operation 'Create Credential' failed
Given login was invalid

Steps to reproduce

Create a new credential
Enter username with a space in it
Try to save credential

GVM versions

gsa: (gsad --version)
7.0.3

gvm: (gvmd --version)
/

openvas-scanner: (openvassd --version)
5.1.3

gvm-libs:

openvas-smb:

Environment

Operating system:
Greenbone Security Manager Community Edition

Installation method / source: (packages, source installation)
ISO from site

Logfiles

This issue was originaly opened under openvas-scanner.

While it is strongly discouraged because it may other systems, Windows (and perhaps other OSes) allow users to create accounts with a space in the username.

It'd be nice if the tool allows you to create such credential to be used by the scanner.
If not, I would suggest to at least include a more descriptive error message ( e.g. "Username cannot contain whitespace" or "Unsupported character used in field username").

sql_prepare_internal: sqlite3_prepare failed: no such table: tickets

Expected behavior

gvmd starting without exausting a "warning", then terminate.

Current behavior

After the warningsql_prepare_internal: sqlite3_prepare failed: no such table: tickets is written, gvmd terminates.

Steps to reproduce

Checkout, install and configure gvmd as required. Start gvmd.
Add some hosts and tasks, then delete a task receiving hint that the task could not be deleted and it is unknown if the task exists because there was no response from gvmd.
Check gvmd running, find it terminated, restart it. Have a look at the logs.

gvmd terminates, because it does not find table tickets. gvmd --migrate tells me the database is at an expected, supported version and nothing has to be done.

GVM Versions

Oops, secure memory pool already initialized
gsad:

ec066dd67 2019-01-08 | Merge pull request #1114 from swaterkamp/SMBAlertsFilePathType (HEAD -> master, origin/master, origin/HEAD)

Greenbone Security Assistant 8.0+beta3
GIT revision ec066dd67-master
Copyright (C) 2010-2016 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gvmd:

c094bc57 2019-01-10 | Merge pull request #319 from mattmundell/content-composer-support (HEAD -> master, origin/master, origin/HEAD)

Greenbone Vulnerability Manager 8.0+beta2
GIT revision c094bc57-master
Manager DB revision 201
Copyright (C) 2010-2017 Greenbone Networks GmbH
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

openvassd:

ad2274a 2019-01-10 | Merge pull request #240 from jjnicola/fix-rsa-pad (HEAD -> master, origin/master, origin/HEAD)

OpenVAS Scanner 6.0+beta3
GIT revision ad2274a-master
Most new code since 2005: (C) 2018 Greenbone Networks GmbH
Nessus origin: (C) 2004 Renaud Deraison <[email protected]>
License GPLv2: GNU GPL version 2
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gvm-libs:

6484f52e 2019-01-07 | Remove TODO. Since multiple KB backends are not supported, just Redis. (HEAD -> master, origin/master, origin/HEAD)

gvm-tools:

2be5246 2019-01-03 | Merge pull request #147 from wiegandm/scripts_style (HEAD -> master, origin/master, origin/HEAD)

node:

v11.6.0

redis-server:

Redis server v=5.0.3 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=23e95a3edb9c526b

Environment

Operating system:

Linux gvm10 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) x86_64 GNU/Linux

Debian testing (buster/sid)

Installation method / source:

source installation, git checkout

Logfiles

md manage:WARNING:2019-01-11 10h14.24 utc:65603: sql_prepare_internal: sqlite3_prepare failed: no such table: tickets
md manage:WARNING:2019-01-11 10h14.24 utc:65603: sqlv: sql_prepare_internal failed
md manage:WARNING:2019-01-11 10h14.24 utc:65603: sql_close: attempt to close db with open statement(s)

Incorrect progress indicator during the scans when a hostname resolves to multiple IP addresses

Expected behavior

Scan progress indicator goes from 0 to 100%.

Current behavior

Scan progress indicator goes from 0 to 200%.

Steps to reproduce

Run a scan against any DNS name which resolves to 2 IPs (e.g. with A and AAAA records).
Watch scan progress 10%, 40%, 120%, 146%, 180%...

GVM versions

gsa: (gsad --version)
Today's snapshot from github.

gvm: (gvmd --version)

openvas-scanner: (openvassd --version)

gvm-libs:

openvas-smb:

Environment

Operating system:
Debian Stretch 9.

Installation method / source: (packages, source installation)
Source.

[7.0.3] export an ssh key pair as debian package will fails

After I fix the rpm part, now I found the problem the debian package export also fails.
An 0 byte file will be generated.
/var/log/openvas/openvasmd.log:

md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_recreate: rpm_path: /tmp/rpm_7lViVe/p.rpm
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: create temporary directory
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: temporary directory: /tmp/lsc_user_rpm_create_oDV68U
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: copy key to temporary directory
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: Attempting RPM build
md manage: DEBUG:2018-04-16 08h20.07 UTC:555: lsc_user_rpm_create: Spawning in /usr/share/openvas: ./openvas-lsc-rpm-creator.sh --target /tmp/lsc_user_rpm_create_oDV68U /tmp/lsc_user_rpm_create_oDV68U/openvas_s
canner.pub
md manage: DEBUG:2018-04-16 08h20.08 UTC:555: lsc_user_rpm_create: new filename (rpm_path): /tmp/lsc_user_rpm_create_oDV68U/openvas-lsc-target-openvas_scanner-0.5-1.noarch.rpm
md manage: DEBUG:2018-04-16 08h20.08 UTC:555: --- executing alien.
md manage: DEBUG:2018-04-16 08h20.08 UTC:555: execute_alien: Spawning in /tmp/rpm_dOxwOC/: fakeroot -- alien --scripts --keep-version p.rpm

If I read the log right, then the rpm package will called /tmp/lsc_user_rpm_create_oDV68U/openvas-lsc-target-openvas_scanner-0.5-1.noarch.rpm , but alien is called with p.rpm

Running on the command line:
fakeroot -- alien --scripts --keep-version foo.rpm
will .deb package will created.
foo.rpm is the created downloaded rpm package from gsa.

[master] Repeated "Failed to remove lock file /var/run/gvm-create-functions: No such file or directory" messages

Running a current master/trunk installation with SQLite the following is shown repeatedly every few
seconds in the gvmd.log:

md manage:WARNING:2018-03-09 09h11.18 utc:21159: Failed to remove lock file /var/run/gvm-create-functions: No such file or directory

The lock file was introduced in #23 at line https://github.com/greenbone/gvm/pull/23/files#diff-730cf9817a3bae893bffce368b13049aR14019

Schedule: planned schedule doesnt' start - errors in gvmd.log

Expected behavior

After creating a schedule (I tried daily and weekly schedules), and configuring it in the desired Task, the Task is expected to run at the expected time configured in the Schedule.

Current behavior

I tried with various settings and tasks, but I've never been able to get the schedule triggered.
Running the task manually instead has no issues and the task runs regularly.

Steps to reproduce

create or edit a Schedule under "Configuration>Schedules".
in the Schedule settings, select a desired time and period (eg: Daily) then press the Save button.
Wait for the Scheduled time and then look if any task with the desired Schedule settings runs or not.

GVM versions

gsa: (gsad --version)
Greenbone Security Assistant 8.0+beta3
GIT revision 41af14bbe-master

gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0+beta2
GIT revision c4ea8a5-master

openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0+beta3
GIT revision 19a27e3-master

gvm-libs:
gvm-libs 1.0+beta2 (2018-12-04)

openvas-smb:
openvas-smb 1.0.4 (2018-08-29)
Environment

Operating system:
Ubuntu Server 18.04 x64

Installation method / source: (packages, source installation)
source installation from github repositories

Logfiles

this issue doesn't get reported in the logs (even after the desired time of the schedule, I didn't see anything coming in my "tail -f -n100 /usr/local/var/log/gvm/gvmd.log" - it looks like the Schedule gets totally ignored)

[7.0.3] Warning message when verify the CVE scanner

When the manger verify the CVE scanner, than it will log an SQL warning.

call openvasmd --get-scanners:
08b69003-5fc2-4037-a479-93b440211c73 OpenVAS Default
6acd0832-df90-11e4-b9d5-28d24461215b CVE
call openvasmd --verify-scanner 6acd0832-df90-11e4-b9d5-28d24461215b:
Scanner version: OTP/2.0.

And at the openvasmd.log file an warning is logged:
md manage:WARNING:2018-04-09 08h53.49 utc:6978: sql_close: attempt to close db with open statement(s)

OpenVAS Manager 7.0.3 | non null compare warning (build time)

Environment: Gentoo/GCC-8.2
gvm: OpenVAS Manager 7.0.3
Installation method: Source
Expected behavior: Build completes without error/warnings
Current behavior: Build completes with warning
Error Log:

In function ‘check_private_key.constprop’,
    inlined from ‘omp_xml_handle_end_element’ at /var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.c:22377:23:
/var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.c:563:15: warning: argument 1 null where non-null expected [-Wnonnull]
   data.size = strlen (key_str);
               ^~~~~~~~~~~~~~~~
In file included from /usr/include/glib-2.0/glib/gtestutils.h:30,
                 from /usr/include/glib-2.0/glib.h:85,
                 from /usr/include/openvas/misc/openvas_server.h:45,
                 from /var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.h:30,
                 from /var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.c:93:
/var/tmp/portage/net-analyzer/openvas-manager-7.0.3/work/gvmd-7.0.3/src/omp.c: In function ‘omp_xml_handle_end_element’:
/usr/include/string.h:384:15: note: in a call to function ‘strlen’ declared here
 extern size_t strlen (const char *__s)
               ^~~~~~

Reproduce: append -Wno-nonnull to cflags to remove warning.(I thought it is harmless warning)

Cannot start task on GSA with GVM 10. Error: sql_x_internal: sql_prepare failed

Expected behavior

Running a task on GSA, the task is completed

Current behavior

Task does not run.

Steps to reproduce

I've made an How-To which describes the steps to install GVM on Alpine:
https://wiki.alpinelinux.org/wiki/Setting_up_GVM10
Basically, install the packages, run GSA (with or without signature is the same), create a task.
Task does not run.

GVM versions

gsa: (gsad --version)
Greenbone Security Assistant 8.0.0

gvm: (gvmd --version)
Greenbone Vulnerability Manager 8.0.0
Manager DB revision 205

openvas-scanner: (openvassd --version)
OpenVAS Scanner 6.0.0

gvm-libs:
gvm-libs-10.0.0

openvas-smb:
Not used

Environment

Operating system:
Alpine Linux edge on x86_64 arch.

Installation method / source: (packages, source installation)
Packages

I get these errors when I start a task on gsa:

md manage:WARNING:2019-04-09 19h36.51 UTC:2469: sql_prepare_internal: sqlite3_prepare failed: not an error
md manage:WARNING:2019-04-09 19h36.51 UTC:2469: init_iterator: sql_prepare failed

This happens with the following packages installed:

sqlite-3.27.2
gvm-libs-10.0.0
gvmd-8.0.0
openvas-scanner-6.0.0
greenbone-security-assistant-8.0.0

What I've noticed (perhaps is linked to this problem), is that importing the nvt i got tons of these WARNING:

md manage:WARNING:2019-04-09 19h27.24 utc:1035: parse_ctime: Failed to parse time '2018-02-27T19:15:33.110Z'

Please note that Alpine doesn't use /etc/TZ to set local time, rather tzdata

According with gvmd logs, seems that somehow I'm hitting a limit:

md manage:WARNING:2019-04-09 19h59.02 UTC:4052: sql_prepare_internal: sqlite3_prepare failed: no more rows available
md manage:WARNING:2019-04-09 19h59.02 UTC:4052: sql_x_internal: sql_prepare failed
md manage:WARNING:2019-04-09 19h59.02 UTC:4052: sql_close: attempt to close db with open statement(s)

No more rows available.
But this is impossible, since the limit is 140Terabyte and SQLite documentation states:

Maximum Number Of Rows In A Table

The theoretical maximum number of rows in a table is 264 (18446744073709551616 or about 1.8e+19). This limit is unreachable since the maximum database size of 140 terabytes will be reached first. A 140 terabytes database can hold no more than approximately 1e+13 rows, and then only if there are no indices and if each row contains very little data.

SQlite on Alpine is built with the following options:

-DSQLITE_ENABLE_FTS4 \
	-DSQLITE_ENABLE_FTS3_PARENTHESIS \
	-DSQLITE_ENABLE_FTS3 \
	-DSQLITE_ENABLE_FTS5 \
	-DSQLITE_ENABLE_COLUMN_METADATA \
	-DSQLITE_SECURE_DELETE \
	-DSQLITE_ENABLE_UNLOCK_NOTIFY \
	-DSQLITE_ENABLE_RTREE \
	-DSQLITE_ENABLE_GEOPOLY \
	-DSQLITE_USE_URI \
	-DSQLITE_ENABLE_DBSTAT_VTAB \
	-DSQLITE_MAX_VARIABLE_NUMBER=250000 \
	-DSQLITE_ENABLE_JSON1"

I've not tested with PostgreSQL as yet.
Also appears to be impossible to build gvmd supporting both postgres and sqlite since -DBACKEND takes only SQLITE3 or POSTGRESQL.

.: Francesco

Feature Request: Slack Alert Method

It would be really helpful if we could get Slack / Mattermost supported as a method for alerting.
(This issue moved from here)

wrong endings for your releases

Hi,
Your release signatures have a wrong file ending. They are named with the following pattern: gvmd-$version.tar.gz.sig.asc. The ending sig.asc breaks our package build system on Arch Linux. Could you please rename this either to tar.gz.sig or tar.gz.asc? I think tar.gz.sig.asc is not necessary... thanks a lot.

How to connect OpenVAS manager to remote PgSQL server?

Now I can connect OpenVAS manager to local PgSQL server.
But now I want to connect remote PgSQL server.
Then I change the file src/sql_pg.c, In line 267 "dbname=%s user=xxx password=xxx hostaddr=x.x.x.x port=5432".
But it cannot be setup successfully, what can I do now?

Create nsis_found() function for NSIS/EXE LSC generation

#112 and #207 had removed the alien_found() call from the NSIS/EXE LSC generation as the usage of alien was dropped in master and alien wasn't used at all for NSIS.

As a replacement a new function nsis_found() similar to the dropped alien_found() could be implemented like suggested in #207 (review)

Wrong NVT category in database

openvasmd --rebuild does not correctly store the category of NVTs.
Steps to verify:

openvasmd --rebuild`
sqlite3 /var/lib/openvas/mgr/tasks.db
sqlite> select count(*) from nvts;
52764
sqlite> select count(*) from nvts where category=11;
52764

This means, all NVTs are stored with category "ACT_UNKOWN" (11).
This also has impact on queries via "omp", e.g.:

omp '<get_nvts nvt_oid="1.3.6.1.4.1.25623.1.0.11187" details="1"/>'
<get_nvts_response status_text="OK" status="200">
_<snip>_
<category>unknown</category>
_<snip>_

OpenVAS fails to rebuild database after a clean install

Expected behavior

openvasmd --rebuild --progress should work as expected.

Current behavior

Rebuilding the database is failing or hanging. See also: https://bugs.archlinux.org/task/57470

Steps to reproduce

Install openvas-manager from Arch Linux repositories
execute openvasamd --rebuild --progress
wait for it

GVM versions

gsa: 7.0.3

gvm: 7.0.3

openvas-scanner: 5.1.2

gvm-libs: 9.0.2

Environment

Operating system: Arch Linux

Installation method / source: package installation

Here is the way I build gvm:

sed -i '1c#!/usr/bin/python2' tools/extra/xml_split
cmake -DCMAKE_BUILD_TYPE=Release -DSBINDIR=/usr/bin \
    -DCMAKE_INSTALL_PREFIX=/usr -DSYSCONFDIR=/etc -DLOCALSTATEDIR=/var .
make
make install

Logfiles

Sorry no log files provided. But if you tell me what you need I try to start a container or VM and get it.

Include timezone in get_settings response

Expected behavior

The timezone should be returned as a setting from the <get_settings> command.

Current behavior

The timezone can only be queried via <authenticate>. It's possible to change the timezone via <modify_settings> but the <get_settings> doesn't contain it. This seems to be very inconsistent to me.

GVM versions

All versions

OpenVAS DB migration error - rev146->184: no such table: main.nvts_172

Error migrating a tasks.db from revision 146 to revision 184

First reported at: https://community.greenbone.net/t/openvas-db-migration-error-rev146-184-no-such-table-main-nvts-172/970

Expected behavior

openvasmd --migrate is running a successful migration

Current behavior

openvasmd --migrate fails to execute a migration step

Steps to reproduce

Happened at our site, might not be reproducible in general:

Have an OpenVAS Manager 6.0.9 installation, DB revision 146 (currently Debian Stretch)
Have an OpenVAS Manager 7.0.3 installation, DB revision 184 (currently Debian Unstable)
Copy tasks.db from 6.0.9 host to 7.0.3 host
Run openvasmd --migrate

GVM versions

gsa: (gsad --version)
Greenbone Security Assistant 7.0.3

openvasmd: (openvasmd --version)
OpenVAS Manager 7.0.3
Manager DB revision 184

openvas-scanner: (openvassd --version)
OpenVAS Scanner 5.1.3

gvm-libs:
libopenvas9 (9.0.3-1)

Environment

Operating system:
$ uname -a
Linux xxx 4.15.18-8-pve #1 SMP PVE 4.15.18-28 (Tue, 30 Oct 2018 14:27:50 +0100) x86_64 GNU/Linux

Logfiles

md main: INFO: Migrating to 181
md manage:WARNING: sql_exec_internal: sqlite3_step failed: error in view results_autofp: no such table: main.nvts_172
md manage:WARNING: sqlv: sql_exec_internal failed