fix: long version of go dependency unable to inserted into software table (CVE-2020-36569) #5229
Conversation
boring-cyborg
bot
added
core
| CREATE TABLE software (cveid INT, cpeEntryId INT, versionEndExcluding VARCHAR(60), versionEndIncluding VARCHAR(60), | ||
| versionStartExcluding VARCHAR(60), versionStartIncluding VARCHAR(60), vulnerable BOOLEAN | ||
| CREATE TABLE software (cveid INT, cpeEntryId INT, versionEndExcluding VARCHAR(100), versionEndIncluding VARCHAR(100), | ||
| versionStartExcluding VARCHAR(100), versionStartIncluding VARCHAR(100), vulnerable BOOLEAN |
There was a problem hiding this comment.
Why not CHARACTER LARGE OBJECT to avoid such failing in the futures if they decided to move with version longer that 100 characters?
There was a problem hiding this comment.
This PR is already merged, but it's worth noting that three people promoted VARCHAR(255) via comments in #5221, a dozen more voted with a 👍 (thumbs-up) on those comments. They reasoned, like you, that the 100 character limit will likely be surpassed by a CVE in the future, which will cause this situation again. However, since the NIST NVD CVE API schema does not define a maximum length for any property, even a length of 255 is arbitrary. I won't say that it's likely to be surpassed, but VARCHAR(255) certainly seems more likely to fail than a large character field like CLOB. If you want to refactor the database schema such such that large-text data types are used for CVE API properties, then I think you would bring longer term stability to the project. Please note that CLOB is not supported by all RDBMSs, including PostgreSQL.
I'll also note that @aikebah stated that they reported the "improper version-data" in CVE-2020-36569 to NIST NVD. As I said, I don't see a maximum length for any property in the CVE API schema, so I'm not sure why the version would be considered improper. Edit: See Hans' reply to this comment.
There was a problem hiding this comment.
The improper is that the version should be split in a start and an end version - see the JSON data published by Go.dev: https://vuln.go.dev/ID/GO-2020-0004.json
"events":[{"introduced":"0.0.0-20160722212129-ac0cc4484ad4"},{"fixed":"0.0.0-20200131131040-063a3fb69896"}]}]
So the configuration should read
from (including)
0.0.0-20160722212129-ac0cc4484ad4
to (excluding)
0.0.0-20200131131040-063a3fb69896
and both versions would properly fit in 60 chars
There was a problem hiding this comment.
@aikebah until someone doesn't use the full ISO 8601 time format (with zone and nanoseconds) with SHA256 aka git commit.
|
I'm still using the plugin version 5.1.2 in Jenkins and the issue seems to have been resolved as the pipeline is running again, i am not sure why however since it seems this fix is tied to version 7.4.4. can anyone help me with this? |
|
@abel-gama The Jenkins plugin is versioned seperately from this project as it is a wrapper around the CLI. It only needs change if either our CLI API or the Jenkins API changes. As long as the CLI-version that it runs the update on is 7.4.4 you would not have an issue (and even older versions would no longer experience problems as the versions in NVD have by now been updated to simple datestamps so they no longer exceed the old 60char limit anymore) |
|
Thank you very much for the reply sir, you helped me alot. |
supersedes #5221
Fixes Issue
Fix: long version of go dependency unable to inserted into software table (CVE-2020-36569)
Description of Change
Alter's column size to varchar 75
Please add a description of the proposed change
Alters to a minimum possible value of version columns to 75 characters. Could be more or less as well.
Have test cases been added to cover the new functionality?
no