Dependencycheck: Initial update of empty postgres database does not work with 6.1.3

[sll552]

Describe the bug
Central postgres DB initialization does not work with 6.1.3

Version of dependency-check used
The problem occurs using version 6.1.3 of the cli

Log file
Errors are Caused by: org.owasp.dependencycheck.data.nvdcve.DatabaseException: Database schema is out of date and org.owasp.dependencycheck.data.nvdcve.DatabaseException: Database schema does not match this version of dependency-check

To Reproduce
For our central DB we are using a deployment of two instances of a postgres database in kubernetes. A init container downloads the core/src/main/resources/data/initialize_postgres.sql from the tag corresponding to the dependency-check version of the container. After that the postgres DB is initialized with the downloaded file (there is no persistence, the DB is always empty at start). The initial update is done using a sidecar that uses the dependency-check docker container with the version corresponding to the tag.

The initialization works but the update fails with the given error messages.

Expected behavior
Initialization and update of an empty postgres DB should work with 6.1.3

Additional context
I suspect that there are changes missing in the initialize_postgres.sql file that are present in initialize.sql.

[aikebah]

@sll552 You might be able to run the update-script after the initialize-script in your sidecar
https://github.com/jeremylong/DependencyCheck/blob/v6.1.3/core/src/main/resources/data/upgrade_5.0.sql

Only the h2 initialisation SQL was updated indeed. For the other databases only an upgrade script was provided in the release.

[sll552]

As you might have already noticed my use case is heavily automated. Is there a way to "know" from scripting point of view which upgrade script to apply after the initialization? The naming of the upgrade scripts seems a little bit random to me because 5.0 has not much to do with 6.1.3.

Also the documentation should be updated to reflect that only running the initialization script does not produce a usable DB if what you described is the intended way to setup a non-H2 DB.

[aikebah]

The initialization script for postgresql should've resulted directly in a usable database, but the update of the external database scripts was overlooked in this release.

Your bug report is therefor completely valid for the 6.1.3 release, it should not have happened (and should be fixed for the next release), but in the meantime you might put the workaround in place to be able to use your automated spin-up for a version 6.1.3 container (or revert back to using 6.1.2)

[aikebah]

If @jeremylong doesn't beat me to it I will create and merge the fix for the 'external' database initialisation scripts tonight in order to ensure that the next release will function as expected.

[sll552]

Thanks, that would be much appreciated. Currently I am back at 6.1.1 and happy to wait for the next release.

[jeremylong]

Sorry about that - I forgot to update the external database scripts... They have been updated.