Repository navigation
SPDX 2.3 tagvalue parser cannot parse documents with erroneous SHA256 ExternalDocumentRef checksums #864
Description
I've been writing some python tooling that consumes SPDX documents from various sources.
Some of which use https://github.com/swinslow/cmake-spdx which unfortunately has the open issue swinslow/cmake-spdx#8 that it generates documents with SHA256 hashes for ExternalDocumentRef due to confusion in the spec and the regex at
only handles SHA1."That's invalid, WONTFIX" is a fair resolution, but searching ExternalDocumentRef and SHA256 didn't find an existing issue so I thought it worth raising.
It may be as simple as extending the regex to the full set supported, but I can't predict if I'll have time to attempt a fix myself and it'd be helpful to know whether the fix would be accepted.
Activity
Atishyy27 commentedon Jul 9, 2026
I'd like to work on this.
Root cause: the tag-value parser's
ExternalDocumentRefhandler builds its own inline regex (parser.py:288) that hardcodes SHA1 with a fixed 40-hex-char length:That path bypasses the lexer's
t_CHECKSUMtoken (lexer.py:140), which already accepts all 17 algorithms inChecksumAlgorithmand doesn't enforce a length — length is checked later byvalidation/checksum_validator.py. SoFileandPackagechecksums accept SHA256 fine, and onlyExternalDocumentRefrejects it.I'll extend the regex to match the lexer's algorithm set, leaving length validation where it already lives. Note this means
SHA1: afdedwill now parse and be rejected at validation time rather than at parse time — consistent with howFile/Packagechecksums already behave. I'll call that out in the PR.