DatabaseException: Error updating 'CVE-2020-36569'

[fdspbsteam]

Describe the bug
classpath 'com.android.tools.build:gradle:4.1.1'
gradle version is: 7.0.2

after run ./gradlew dependencyCheckAnalyze
in logs falls down, this error:

org.owasp.dependencycheck.data.nvdcve.DatabaseException: Error updating 'CVE-2020-36569'
org.owasp.dependencycheck.data.update.exception.UpdateException: org.owasp.dependencycheck.data.nvdcve.DatabaseException: Error updating 'CVE-2020-36569'
	at org.owasp.dependencycheck.data.update.nvd.ProcessTask.processFiles(ProcessTask.java:157)
	at org.owasp.dependencycheck.data.update.nvd.ProcessTask.call(ProcessTask.java:114)
	at org.owasp.dependencycheck.data.update.nvd.ProcessTask.call(ProcessTask.java:41)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.owasp.dependencycheck.data.nvdcve.DatabaseException: Error updating 'CVE-2020-36569'
	at org.owasp.dependencycheck.data.nvdcve.CveDB.updateVulnerability(CveDB.java:823)
	at org.owasp.dependencycheck.data.update.nvd.NvdCveParser.parse(NvdCveParser.java:114)
Caused by: org.owasp.dependencycheck.data.nvdcve.DatabaseException: Error updating 'CVE-2020-36569'

	at org.owasp.dependencycheck.data.update.nvd.ProcessTask.importJSON(ProcessTask.java:141)
	at org.owasp.dependencycheck.data.update.nvd.ProcessTask.processFiles(ProcessTask.java:154)
	... 6 more
Caused by: org.h2.jdbc.JdbcBatchUpdateException: Value too long for column "VERSIONENDEXCLUDING CHARACTER VARYING(60)": "'0.0.0-20160722212129-ac0cc4484ad4_before_v0.0.0-20200131131040-063a3fb69896' (75)"; SQL statement:
INSERT INTO software (cveid, cpeEntryId, versionEndExcluding, versionEndIncluding, versionStartExcluding, versionStartIncluding, vulnerable) VALUES (?, ?, ?, ?, ?, ?, ?) [22001-214]
	at org.h2.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:1269)
	at org.apache.commons.dbcp2.DelegatingStatement.executeBatch(DelegatingStatement.java:241)
	at org.apache.commons.dbcp2.DelegatingStatement.executeBatch(DelegatingStatement.java:241)
	at org.owasp.dependencycheck.data.nvdcve.CveDB.executeBatch(CveDB.java:1248)
	at org.owasp.dependencycheck.data.nvdcve.CveDB.updateVulnerabilityInsertSoftware(CveDB.java:1098)
Caused by: org.h2.jdbc.JdbcBatchUpdateException: Value too long for column "VERSIONENDEXCLUDING CHARACTER VARYING(60)": "'0.0.0-20160722212129-ac0cc4484ad4_before_v0.0.0-20200131131040-063a3fb69896' (75)"; SQL statement:

	at org.owasp.dependencycheck.data.nvdcve.CveDB.updateVulnerability(CveDB.java:816)
	... 9 more

Version of dependency-check used
classpath 'org.owasp:dependency-check-gradle:7.2.1'
classpath 'org.owasp:dependency-check-gradle:7.4.3'

Log file
When reporting errors, 99% of the time log file output is required. Please post the log file as a gist and provide a link in the new issue.

To Reproduce
Steps to reproduce the behavior:

1. run ./gradlew dependencyCheckAnalyze
2. See error

Expected behavior
task started and scan completed

Additional context
Add any other context about the problem here.

[InverseIntegral]

Same issue here. The problem is that the maximum length of the column is 60 characters whereas the versionEndExcluding of CVE-2020-36569 is of length 75.

To fix this a schema change similar to this one is needed:

DependencyCheck/core/src/main/resources/data/upgrade_5.1.sql

Line 1 in 21b08b3

ALTER TABLE software ALTER COLUMN versionEndExcluding SET DATA TYPE VARCHAR(60);

[VSrinivasaRaghavan]

Raised a PR which could be a potential fix for the issue : #5221
Please review the PR.

[vignesh-gupta-xom]

Hello @srini00088, I reviewed you PR I believe that should solve the issue. But I have a question if I'm using 6.0.2 version. Will the merging of these PR will solve the same problem in 6.0.2 version as well?

[pellepelster]

will this be released after merging? this currently breaks all our builds an we are wondering if we need to disable CVE scanning in general or if it is feasible to wait?

(and btw kudos @srini00088 for the speed of the fix, when I discovered the bug this morning the PR was already underway)

[gareji]

same here, all the pipelines are failing because of it, its trying to insert long value into varchar(60).
we need a fix asap please

[karstenspang]

Looking at CVE-2020-36569, it seems that when they modified it on 2023-01-05, they bungled adding the end version. The value is apparently the concatenation of the start and end versions, which makes it so long.

[mlemmens]

I think NVD is in error with the version string.

CVE-2020-36569:

Authentication is globally bypassed in github.com/nanobox-io/golang-nanoauth between v0.0.0-20160722212129-ac0cc4484ad4 and v0.0.0-20200131131040-063a3fb69896 if ListenAndServe is called with an empty token.

Action	Type	Old Value	New Value
Added	CPE Configuration		OR cpe:2.3:a:digitalocean:golang-nanoauth::::::go:: versions up to (excluding) 0.0.0-20160722212129-ac0cc4484ad4_before_v0.0.0-20200131131040-063a3fb69896

0.0.0-20160722212129-ac0cc4484ad4_before_v0.0.0-20200131131040-063a3fb69896 is a incorrect version.

[VSrinivasaRaghavan]

@karstenspang @mlemmens I think you folks are right, the issue could be with CVE database, I have also reported an issue with https://cveform.mitre.org/

[ahoehma]

Short question: I'm using "dependency-check-maven" ... is there a way to say "ignore failed/crashed" plugin?

[simonh-wincomplm]

Short question: I'm using "dependency-check-maven" ... is there a way to say "ignore failed/crashed" plugin?

We use this ${cve.check.skip} which allows us to turn off the plugin by using this Maven parameter -Dcve.check.skip=false. Add this as a skip tag in the configuration

[ahoehma]

Good idea. But I'm searching for something like "in case of errors (any), just show it but continue the build".

[fdspbsteam]

the same question, I'm using "dependency-check-gradle" ... is there a way to say "ignore failed/crashed" plugin? or how to avoid in further this issue?

[simonh-wincomplm]

I got nothing on this, we have had to temporarily turn off the plugin on all our pipelines until there is a fix

[davejbur]

Short question: I'm using "dependency-check-maven" ... is there a way to say "ignore failed/crashed" plugin?

We use this ${cve.check.skip} which allows us to turn off the plugin by using this Maven parameter -Dcve.check.skip=false. Add this as a skip tag in the configuration

Sorry, doesn't work for me - I've got:

      <plugin>
        <groupId>org.owasp</groupId>
        <artifactId>dependency-check-maven</artifactId>
        <version>7.4.3</version>
        <executions>
          <execution>
            <configuration>
              <skip>true</skip>
...

but it still tries to update the database. (I've also tried <skip>false</skip> in case there's some reversed logic somewhere.)

Only thing I can think of is to comment out the whole plugin.

[dmitry-weirdo]

Isn't it good to have some automatic test before changing the CVE database and breaking thousands of projects all over the world?

I know it's a question more to the direction of CVE, but anyway, this behaviour is to be avoided.

[simonh-wincomplm]

Short question: I'm using "dependency-check-maven" ... is there a way to say "ignore failed/crashed" plugin?

We use this ${cve.check.skip} which allows us to turn off the plugin by using this Maven parameter -Dcve.check.skip=false. Add this as a skip tag in the configuration

Sorry, doesn't work for me - I've got:

      <plugin>
        <groupId>org.owasp</groupId>
        <artifactId>dependency-check-maven</artifactId>
        <version>7.4.3</version>
        <executions>
          <execution>
            <configuration>
              <skip>true</skip>
...

but it still tries to update the database. (I've also tried <skip>false</skip> in case there's some reversed logic somewhere.)

Only thing I can think of is to comment out the whole plugin.

Sorry seems you have it good, but it does work for us

[ddjain]

We are also getting same error while running mvn site to generate vulnerability report.

[viollinn]

Hello !

same here !

[ostijo]

Same problem here, this bug breaks our build pipelines. So a fix asap is highly appreciated.

[mjlalani]

Same problem here

[ERROR] Unable to continue dependency-check analysis. [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 03:55 min [INFO] Finished at: 2023-01-06T10:36:47Z [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.owasp:dependency-check-maven:7.4.3:check (default) on project config-service: Fatal exception(s) analyzing config-service: One or more exceptions occurred during analysis: [ERROR] UpdateException: org.owasp.dependencycheck.data.nvdcve.DatabaseException: Error updating 'CVE-2020-36569' [ERROR] caused by DatabaseException: Error updating 'CVE-2020-36569' [ERROR] caused by JdbcBatchUpdateException: Value too long for column "VERSIONENDEXCLUDING CHARACTER VARYING(60)": "'0.0.0-20160722212129-ac0cc4484ad4_before_v0.0.0-20200131131040-063a3fb69896' (75)"; SQL statement: [ERROR] INSERT INTO software (cveid, cpeEntryId, versionEndExcluding, versionEndIncluding, versionStartExcluding, versionStartIncluding, vulnerable) VALUES (?, ?, ?, ?, ?, ?, ?) [22001-214] [ERROR] NoDataException: No documents exist

[markmasl]

Maybe it is worth to add a protection for such kind of problems in the future?
Meaning, - skipping erroneous CVEs or at least not failing further db inserts?

[llech]

The protection is not to make false assumptions about the names/ids one doesnt' control.

[sladg]

Same here, pipelines currently unusable, fails when updating CVE database with above mentioned error.

[croo]

I hit the same problem today.

Most of the information is here so I won't repeat it I just want to add that I met this issue on 7.1.3 version then upgraded to latest 7.4.3 and the problem persists.

[aikebah]

Looks like a corrupted H2 database to me at first sight. You could try a one-off build that uses
org.owasp:dependency-check-maven:7.4.4:purge org.owasp:dependency-check-maven:7.4.4:aggregate to clear out the data and recreate it (and then revert back to just the aggregate goal)
(I know maven-plugin of 7.4.4 can complete successfully as I've done successful updates of the CVEDB with maven in our CI infra)

[davidholiday]

FWIW 7.4.4 fixed the CLI issue for me - tytyty and have a rad weekend! 🍻

[Keymaster65]

Thanx for fixing that fast!

[vvalencia-cl]

Looks like a corrupted H2 database to me at first sight. You could try a one-off build that uses org.owasp:dependency-check-maven:7.4.4:purge org.owasp:dependency-check-maven:7.4.4:aggregate to clear out the data and recreate it (and then revert back to just the aggregate goal) (I know maven-plugin of 7.4.4 can complete successfully as I've done successful updates of the CVEDB with maven in our CI infra)

That worked.
Thank you!

[Dhanxy]

I think the problem with Gradle was solved, I'm doing analysis of different versions and it gives me successful results.

[aikebah]

I think the problem with Gradle was solved, I'm doing analysis of different versions and it gives me successful results.

@Dhanxy Likely multiple versions work (as the database version is sufficiently compatible), but you will need 7.4.4 to run the upgrade-script and your safest bet would be to be in-sync on the version used).
Not sure whether that's easy to arrange within a Gradle environment. I'm more familiar with the maven environment where I advise (and practice) to use a property for the version in the pom.xml (set to a default value and updated to latest release during regular maintenance) which then gets a system- or user-wide override by that same property configured in the maven settings.xml, so that scans can use an updated version of the plugin without a need to first change the pom.xml (maven's counterpart of the build.gradle)

[bohdantverdyi]

Hello, jenkins plugin still has 7.4.3 version as latest available.

Workaround for jenkins how to install latest 7.4.4 version is manuall instalation.

[melloware]

i think this ticket can be closed

[avula-sudheer]

Hi @srini00088,

I looked at your #5221. With my limited knowledge of this, I have a comment about the fix.

Do you think of a reason why this column size should be limited to a value that fixes the current scenario? What if another CVE with a longer string comes in the future?

[Dnu12]

I increased column length to 90 in initialize.sql and upgrade_5.1.sql for columns "versionEndExcluding VARCHAR(90), versionEndIncluding VARCHAR(90),versionStartExcluding VARCHAR(90), versionStartIncluding VARCHAR(90)" and updated it in jars .But on running again getting same error .Running it via terminal .Any help on how to increase the length and run it via command line ? @aikebah

If you patched your local jars you should be able to purge the database and get it to work (but it will need purging as it will not upgrade your database, which is already upgraded to the expected version, so you need to force it to be recreated)

But how do I purge the database? Do we internally purge the old db and create new one on running 'sh dependency-check.sh'.I also couldn't find where h2 db is created .( I don't have anything(such as data) inside .m2 repo )

For the CLI using your invocation that would be the command sequence sh dependencycheck.sh --purge to purge it followed by sh dependencycheck.sh --updateonly or a regular scan to trigger the recreation

After purging,I don't face above issue.But it got stuck for long time ( there's no issue with internet connection ).I checked this issue #4163 . But there was no response .Any help on that.( Just running the tool shouldn't be this hard I guess ? ).Thanks so much for all the help so far . @aikebah

[Dnu12]

I increased column length to 90 in initialize.sql and upgrade_5.1.sql for columns "versionEndExcluding VARCHAR(90), versionEndIncluding VARCHAR(90),versionStartExcluding VARCHAR(90), versionStartIncluding VARCHAR(90)" and updated it in jars .But on running again getting same error .Running it via terminal .Any help on how to increase the length and run it via command line ? @aikebah

If you patched your local jars you should be able to purge the database and get it to work (but it will need purging as it will not upgrade your database, which is already upgraded to the expected version, so you need to force it to be recreated)

But how do I purge the database? Do we internally purge the old db and create new one on running 'sh dependency-check.sh'.I also couldn't find where h2 db is created .( I don't have anything(such as data) inside .m2 repo )

For the CLI using your invocation that would be the command sequence sh dependencycheck.sh --purge to purge it followed by sh dependencycheck.sh --updateonly or a regular scan to trigger the recreation

After purging,I don't face above issue.But it got stuck for long time ( there's no issue with internet connection ).I checked this issue #4163 . But there was no response .Any help on that.( Just running the tool shouldn't be this hard I guess ? ).Thanks so much for all the help so far . @aikebah

Attaching image @aikebah

[Dnu12]

I increased column length to 90 in initialize.sql and upgrade_5.1.sql for columns "versionEndExcluding VARCHAR(90), versionEndIncluding VARCHAR(90),versionStartExcluding VARCHAR(90), versionStartIncluding VARCHAR(90)" and updated it in jars .But on running again getting same error .Running it via terminal .Any help on how to increase the length and run it via command line ? @aikebah

If you patched your local jars you should be able to purge the database and get it to work (but it will need purging as it will not upgrade your database, which is already upgraded to the expected version, so you need to force it to be recreated)

But how do I purge the database? Do we internally purge the old db and create new one on running 'sh dependency-check.sh'.I also couldn't find where h2 db is created .( I don't have anything(such as data) inside .m2 repo )

For the CLI using your invocation that would be the command sequence sh dependencycheck.sh --purge to purge it followed by sh dependencycheck.sh --updateonly or a regular scan to trigger the recreation

After purging,I don't face above issue.But it got stuck for long time ( there's no issue with internet connection ).I checked this issue #4163 . But there was no response .Any help on that.( Just running the tool shouldn't be this hard I guess ? ).Thanks so much for all the help so far . @aikebah

Report is generated now . But atleast we could show that report is being generated to avoid confusion.

[kvisendorfs]

I just wanted to thank from me and my team for the quick fix and all the work, that has been put in this project!
New version for Gradle plugin works and all is well! :)

[marcochristoforou]

Hi All. Thanks for all the work you're all putting in.
I'm working for NHS (UK National Health Service) and unfortunately all our pipelines are still broken. We use Maven and we're still seeing the following...

[ERROR] Failed to execute goal org.owasp:dependency-check-maven:7.1.0:aggregate (default-cli) on project bcss-regression: Fatal exception(s) analyzing bcss-regression: One or more exceptions occurred during analysis: [ERROR] UpdateException: org.owasp.dependencycheck.data.nvdcve.DatabaseException: Error updating 'CVE-2020-36569' [ERROR] caused by DatabaseException: Error updating 'CVE-2020-36569' [ERROR] caused by JdbcBatchUpdateException: Value too long for column "VERSIONENDEXCLUDING CHARACTER VARYING(60)": "'0.0.0-20160722212129-ac0cc4484ad4_before_v0.0.0-20200131131040-063a3fb69896' (75)"; SQL statement: [ERROR] INSERT INTO software (cveid, cpeEntryId, versionEndExcluding, versionEndIncluding, versionStartExcluding, versionStartIncluding, vulnerable) VALUES (?, ?, ?, ?, ?, ?, ?) [22001-210]

I'm about to back out all dependency scanning, but before I do, has anyone any suggestions? We use docker containers so I thought it may be docker caching, but I've clearer the cache.
Thanks

[YihongGao]

Hi All. Thanks for all the work you're all putting in. I'm working for NHS (UK National Health Service) and unfortunately all our pipelines are still broken. We use Maven and we're still seeing the following...

[ERROR] Failed to execute goal org.owasp:dependency-check-maven:7.1.0:aggregate (default-cli) on project bcss-regression: Fatal exception(s) analyzing bcss-regression: One or more exceptions occurred during analysis: [ERROR] UpdateException: org.owasp.dependencycheck.data.nvdcve.DatabaseException: Error updating 'CVE-2020-36569' [ERROR] caused by DatabaseException: Error updating 'CVE-2020-36569' [ERROR] caused by JdbcBatchUpdateException: Value too long for column "VERSIONENDEXCLUDING CHARACTER VARYING(60)": "'0.0.0-20160722212129-ac0cc4484ad4_before_v0.0.0-20200131131040-063a3fb69896' (75)"; SQL statement: [ERROR] INSERT INTO software (cveid, cpeEntryId, versionEndExcluding, versionEndIncluding, versionStartExcluding, versionStartIncluding, vulnerable) VALUES (?, ?, ?, ?, ?, ?, ?) [22001-210]

I'm about to back out all dependency scanning, but before I do, has anyone any suggestions? We use docker containers so I thought it may be docker caching, but I've clearer the cache. Thanks

@marcochristoforou you must be upgrade to 7.4.4 version. it will fix the problem.
thanks the all contributor of this project.

[aikebah]

@marcochristoforou

org.owasp:dependency-check-maven:7.1.0:aggregate

indicates that your project is configured to run version 7.1.0 of ODC maven plugin.

It's likely configured in the pom.xml of that project (or one of its parents) to take version 7.1.0

Only using version 7.4.4 you will succeed to run the update.

Depending on how your CI infra is organized you might be able to get it rolling by running a one-off job that just runs mvn org.owasp:dependency-check-maven:7.4.4:update-only which would update the database in the maven local repository. (assumes you have build-infra that uses a single maven local repository for all builds)

[marcochristoforou]

Sorry all (@aikebah), yes, just sorted that. Be too keen to post, feeing left out I guess :D

[cchantep]

On Java9 it raises the DataTimeException: gradle/gradle#13763