syft should error if not specifying sha1 for SPDX

[mlieberman85]

What happened:
Syft generates SPDX SBOM with only md5, sha256, etc. if specified in config. SPDX requires one of the checksums included be sha1.

What you expected to happen:
Either Syft should error stating that sha1 must be included as well, or it should use any non-sha1 digest in addition to the required sha1.

How to reproduce it (as minimally and precisely as possible):
Include a syft.yaml config with:

  digests: ["sha256"]

and run syft while generating SPDX.

Environment:

• Output of syft version: syft 0.58.0
• OS (e.g: cat /etc/os-release or similar):

BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="22.11pre400549.af9e00071d0"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 22.11 (Raccoon)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="22.11 (Raccoon)"
VERSION_CODENAME=raccoon
VERSION_ID="22.11"

[kzantow]

Thanks for this issue @mlieberman85 -- are you referring to the Package verification code field? It looks like all other fields that use digest algorithms allow a number of different types of algorithms.

I wonder if there is no sha1, we could just emit a warning about this, set FilesAnalyzed to false and omit this field, what do you think?

[mlieberman85]

So, it might be ambiguous but in 8.4 under File Checksum field it also states:

SHA1 is to be used on the file. Other algorithms that can be provided optionally include SHA224, SHA256, SHA384, SHA512, SHA3-256, SHA3-384, SHA3-512, BLAKE2b-256, BLAKE2b-384, BLAKE2b-512, BLAKE3, MD2, MD4, MD5, MD6, ADLER32

In the json schema it's worded a bit differently:

"description" : "Identifies the algorithm used to produce the subject Checksum. Currently, SHA-1 is the only supported algorithm. It is anticipated that other algorithms will be supported at a later time.",

I have seen some SPDX parsers to require sha1 and optionally include other algos. Other parsers are a bit more flexible.

As far as solution, that makes sense. Just something to either always include sha1 or warn when it's not happening.

[kzantow]

Ah, yes I misread that. This does look more like an error -- it's a required field, but we don't have the information to provide it. If we jut warned for this, then we'd have to start omitting larger sections of the SPDX so it would be valid, like the entire File entry. I think in this case actually erroring out would be better, do you agree?

There's another potential option that we detect SPDX output and always add the sha1 algorithm before running a scan, since we know we will need it.

[mlieberman85]

For this particular issue it might make sense to error out. Perhaps warn on files/dirs that are being dropped. I have noticed for example in this SBOM: http://oopsallsboms.storage.googleapis.com/addon-resizer-1.2.sha256-f4a217b52cc55bd6f47a33d79e56e7e6c0b28415afdcd8f2294ed31c9117b765.syft.0.58.0.spdx.json -- some things have hashes, other things don't. It looks like most of the things that don't have hashes are directories?

I don't want to detract from this particular issue, but there are inconsistencies within the documentation for the spec, and the JSON schema for the spec:

• For example: SPDX JSON has external reference category of PACKAGE_MANAGER instead of PACKAGE-MANAGER #1236 - The SPDX JSON contradicts the actual specification documentation.

There are a few other things that are "required" even if the data is just "NOASSERTION" like:

• Files need to also have license info even if the license info is NOASSERTION - https://spdx.github.io/spdx-spec/file-information/#86-license-information-in-file-field
• Copyright info on files even if NOASSERTION or NONE - https://spdx.github.io/spdx-spec/file-information/#88-copyright-text-field
• Copyright info on packages as well.

[mlieberman85]

Actually it appears the license and copyright info being blank might be inconsistencies between the JSON schema and the spec documentation.