SPDX 2.3 tagvalue parser cannot parse documents with erroneous SHA256 ExternalDocumentRef checksums

[richardmaw-codethink]

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

tools-python/src/spdx_tools/spdx/parser/tagvalue/parser.py

Line 288 in b7f9a3d

external_doc_ref_regex = re.compile(r"(.*)(\s*SHA1:\s*[a-f0-9]{40})")

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.

[Atishyy27]

I'd like to work on this.

Root cause: the tag-value parser's ExternalDocumentRef handler builds its own inline regex (parser.py:288) that hardcodes SHA1 with a fixed 40-hex-char length:

external_doc_ref_regex = re.compile(r"(.*)(\s*SHA1:\s*[a-f0-9]{40})")

That path bypasses the lexer's t_CHECKSUM token (lexer.py:140), which already accepts all 17 algorithms in ChecksumAlgorithm and doesn't enforce a length — length is checked later by validation/checksum_validator.py. So File and Package checksums accept SHA256 fine, and only ExternalDocumentRef rejects it.

I'll extend the regex to match the lexer's algorithm set, leaving length validation where it already lives. Note this means SHA1: afded will now parse and be rejected at validation time rather than at parse time — consistent with how File/Package checksums already behave. I'll call that out in the PR.