VTs deleted from DB lead to complete rebuild

Hi there,
I wonder if anyone can help me to understand why if one deletes a custom-made VT from the plugin database this can lead to a complete rebuild of the database, instead of a simple update.
Is this because of some lack of sync between the gvmd and scanner?

In the past I deleted single custom VTs without issues, but this time I deleted 11 custom files at once that I had previously added to the Community feed. When updating to a new community feed date, there was a complete rebuild (hash mismatch) instead of an update.
Has anyone an idea why this happened.
I use GVM 21.4.

I also wonder what is the reason behind moving VTs to the /attic instead of deleting them?
I would really like to understand the logic behind this, please.

Thanks,
Niko

Hi,

gvmd and ospd-openvas need to sync their VT meta data. In the past only the last modification date of a VT has been considered for an required update. Nowadays both also calculate a hash over all VT data and compare this hash. If it mismatches, some data must have been changed and a complete rebuild is necessary. I am currently not sure how deleting a VT is handled for the hash calculation but as we didn’t do this in the past I guess it just invalidates the hash. Therefore moving a VT into some “attic” directory and updating its last modification date should be a better solution.

2 Likes

If removing VTs completely the manager and scanner would lose all metadata (e.g. assigned CVEs, summary, the name of the VT and other fields, …) which means this would break any report having a result of such a removed VT. Basically you would only see the OID and nothing else in such an affected report.

4 Likes