Closed tgurr closed 2 years ago
nichtsfrei
commented
2 years ago The exception is thrown when the cache could not be initialized due to a verification error; the line:
OSPD[14136] 2022-09-06 16:52:44,243: WARNING: (gnupg) gpg returned a non-zero error code: 2
indicates that gpg verification failed.
However rather than printing a stacktrace and quitting ospd-openvas I think it should print a warning and ignore the notus advisories.
nichtsfrei
commented
2 years ago For your actual issue: I think you need to set a proper GNUPGHOME environment variable otherwise it is using: /etc/openvas/gnupg which on most machines isn't accurate.
So to start ospd-openvas as your user you could use:
GNUPGHOME=$HOME/.gnupg/ ospd-openvas --config ~/ospd.conf -fIn the meantime I am going to find a way to handle this default more gracefully for future versions.
tgurr
commented
2 years ago In the meantime I am going to find a way to handle this default more gracefully for future versions.
Thanks for implementing the steps to handle this gracefully for future versions.
For your actual issue: I think you need to set a proper
GNUPGHOMEenvironment variable otherwise it is using:/etc/openvas/gnupgwhich on most machines isn't accurate.
Thanks for the explanation, the documentation at https://greenbone.github.io/docs/latest/22.4/source-build/index.html#feed-validation is a little bit scattered since some required inital steps are found at the step before at https://greenbone.github.io/docs/latest/22.4/source-build/index.html#importing-the-greenbone-signing-key and it's a hassle to implement this packaging wise as running gnupg import will start gpg-agent and requires a socket which fails without workarounds for us as our package manager runs in a sandbox, see https://git.exherbo.org/net.git/commit/?id=2c1b948ed22f937215d65944863ff88a64e6de14 on the required steps to workaround this problem for us. It would be great if we could e.g. just dump the GBCommunitySigningKey.asc and a ownertrust.txt in /etc/openvas or
/etc/openvas/gnupg and ospd-openvas would handle the import automatically on startup/runtime. After implementing the key import steps (as seen in the linked commit above) 22.4.2 runs fine here as well.
nichtsfrei
commented
2 years ago I will forward your suggestions regarding the documentation to the corresponding teams.
Although I understand that within a sandbox that it would be great to automatically import public keys and ownertrust on an initial start of ospd-openvas it would may interfere with our current packaging.
Since this is a feature request it would help me when you create an own ticket for that so that I can discuss it more easily.
Running into an error with the latest version 22.4.2 (downgrading back to 22.4.0 resolves the problem).
Expected behavior
Starting up and running without any issues (like 22.4.0 did and still does for me).
Actual behavior
Running into the following error since upgrading from 22.4.0 to 22.4.2.
Steps to reproduce
GVM versions
gsa: Greenbone Security Assistant 22.04.0
gvm: Greenbone Vulnerability Manager 22.4.0~dev1 (<- note: ~dev1 was somehow introduced between tag 22.4 and the actual release tag 22.4.0 with the change to PROJECT_DEV_VERSION 1 in CMakeLists.txt: https://github.com/greenbone/gvmd/compare/v22.4...v22.4.0) Manager DB revision 250
openvas-scanner: OpenVAS 22.4.0
gvm-libs: gvm-libs 22.4.0
Environment
Operating system: Exherbo Linux
Installation method / source: source-based packages
Logfiles
/var/log/gvm/ospd-openvas.log
Note for the MQTT broker WARNING: I've not yet setup MQTT & packaged notus-scanner, so I already had that warning with 22.4.0 previously as well of course.
Additional information:
I also tried adding
notus-feed-dir = /var/lib/notus/advisoriesto theospd-openvas.confas I've seen it's also passed in your systemd file suggestion at https://greenbone.github.io/docs/latest/22.4/source-build/index.html#setting-up-services-for-systemd but it didn't make any difference.