This adds a cargo spdx build subcommand that wraps cargo build and creates SBOMs for the produced binaries. The SBOMs are stored alongside the binary, with the same name + SPDX extension.

It uses the cargo's json messages to detect produced binaries and the dependencies produced in the build

This approach also extends well to getting source file information outside of cargo: cargo's messages give info about rmeta files, which we can use to navigate to the dep-info files and get a list of the Rust source files. The messages also tell us about build script execution, which we may be able to leverage for linking to non-Rust built code.

Usage

cargo spdx --format json -H 'https://foo.bar' build -- --all-features --message-format=json

The structs in document.rs were initially generated from the SPDX schema and tweaked (to configure serde to skip serializing optional fields if None).

The binary is added as a File information to the SBOM. All packages detected are also added, and a relationship between each package and the binary is added to show that binary depends on the package.

Various caveats of this first iteration:

1. Only supports executables (i.e bin target kinds, not dylib/cdylib/staticlib)
2. Package/file information is only output for JSON/yaml formats, until kv output support for those is added
3. build subcommand doesn't respect --force by design, but need to make that clearer through the UI.

4.4 of the SPDX spec says :

Interoperability between all the supported file formats shall be preserved. SPDX defines how to validate a document in
each supported format, and how to translate a valid document without loss to each other supported format.

Does cargo-spdx need to be able to generate tag value format SBOMs? Can we initially just always output JSON SBOMs and assume that downstream tooling can handle JSON.

The tag value format doesn't have a deserializer in Rust, so continuing with this means cargo-spdx needs to write one, which will slow down development compared to if we just focus on one of the other formats. For these we can generate Rust structs from the schema and use serde for deserialization - that would narrow it down to json/yaml.

Follows on from https://github.com/alilleybrinker/cargo-spdx/pull/9. Not worth reviewing this in detail until that's resolved.

Read the relevant rustc/cargo dep-info files to determine the source files used in the build.

• For dependent libraries rustc produces an rmeta file and dep-info file. The rmeta file is included in the cargo build messages, and is used to navigate to the dep_info file
• For the binary, cargo outputs the dep-info file next to the binary: https://doc.rust-lang.org/cargo/guide/build-cache.html#dep-info-files

These are then included in the SBOM relative to the owning package root, to avoid leaking any host specific paths into the SBOMs. A relationship is added between each file and its owning package, which is already a dependency of the binary from changes in https://github.com/alilleybrinker/cargo-spdx/pull/9.

This PR adds support for JSON and YAML output support.

The specification for JSON/RDF/YAML differs from the tag:value format in a couple of ways that caused me to change some of the structs in document.rs.

1. different nesting. E.g creator information is nested beneath creationInfo for the former formats but not tag:value.
2. field names.

If cargo-spdx is going to support multiple formats then its internal structs should probably match the JSON/RDF/YAML representation to allow integration with serde, and since SPDX has a JSON schema the structs for the unimplemented parts of the specification can be generated automatically.

This gives a better responses when users don't specify -h or don't pass in a valid argument combinartion.

E.g before this change, I get an error when running cargo spdx -h:

$ cargo spdx -h
error: cargo-spdx 0.1.0
Generate an SPDX SBOM for a crate

USAGE:
    cargo spdx [OPTIONS]

OPTIONS:
    -f, --format <FORMAT>        The output format to use: 'kv' (default), 'json', 'yaml', 'rdf'
    -F, --force                  Force the output, replacing any existing file with the same name
    -h, --help                   Print help information
    -H, --host-url <HOST_URL>    The URL where the SBOM will be hosted. Must be unique for each SBOM
    -n, --no-interact            Do not run interactively
    -o, --output <OUTPUT>        The path of the desired output file
    -V, --version                Print version information

After:

$ cargo spdx -h
cargo-spdx 0.1.0
Generate an SPDX SBOM for a crate

USAGE:
    cargo spdx [OPTIONS]

OPTIONS:
    -f, --format <FORMAT>        The output format to use: 'kv' (default), 'json', 'yaml', 'rdf'
    -F, --force                  Force the output, replacing any existing file with the same name
    -h, --help                   Print help information
    -H, --host-url <HOST_URL>    The URL where the SBOM will be hosted. Must be unique for each SBOM
    -n, --no-interact            Do not run interactively
    -o, --output <OUTPUT>        The path of the desired output file
    -V, --version                Print version information

Second one has color terminal support too.

spdx-rs claims support for serialization/deserialization of SPDX documents in formats corresponding to the json schema (JSON/yaml), and tag/value.

@alilleybrinker should we use that in cargo-spdx?

Rust binaries can statically link to native libraries generated by build scripts. These libraries should be included in the SBOM.

cargo build JSON messages can show what libraries are linked (via the linked_libs field) , and the linker search paths configured by the build script. cargo-spdx could use this to look for the linked libraries.

Examples (from cargo build --message-format json | grep build-script of cargo-spdx itself):

{"reason":"build-script-executed","package_id":"openssl-sys 0.9.74 (registry+https://github.com/rust-lang/crates.io-index)","linked_libs":["static=ssl","static=crypto"],"linked_paths":["native=/home/tom/.target/debug/build/openssl-sys-15856e134bacc665/out/openssl-build/install/lib"],"cfgs":["const_fn","osslconf=\"OPENSSL_NO_COMP\"","osslconf=\"OPENSSL_NO_SSL3_METHOD\"","osslconf=\"OPENSSL_NO_SEED\"","ossl101","ossl102","ossl102f","ossl102h","ossl110","ossl110f","ossl110g","ossl110h","ossl111","ossl111b","ossl111c"],"env":[],"out_dir":"/home/tom/.target/debug/build/openssl-sys-15856e134bacc665/out"}
{"reason":"build-script-executed","package_id":"libssh2-sys 0.2.23 (registry+https://github.com/rust-lang/crates.io-index)","linked_libs":["static=ssh2"],"linked_paths":["native=/home/tom/.target/debug/build/libssh2-sys-eb5dddeb5944716b/out/build"],"cfgs":[],"env":[],"out_dir":"/home/tom/.target/debug/build/libssh2-sys-eb5dddeb5944716b/out"}
{"reason":"build-script-executed","package_id":"libgit2-sys 0.13.4+1.4.2 (registry+https://github.com/rust-lang/crates.io-index)","linked_libs":["static=git2"],"linked_paths":["native=/home/tom/.target/debug/build/libgit2-sys-ebe9f6f73e42c271/out/build"],"cfgs":["libgit2_vendored"],"env":[],"out_dir":"/home/tom/.target/debug/build/libgit2-sys-ebe9f6f73e42c271/out"}

The out_dir typically contains the sources used to build the linked library - suspect we should include SBOM entries for all files in the out_dir.

SPDX permits specification of the relationship between elements. There's a pretty substantial list of relationship types that can be represented, and of entities that can be related. The documentation gives come examples:

Relationship: SPDXRef-grep CONTAINS SPDXRef-make
RelationshipComment: Package grep contains file make

Relationship: SPDXRef-DOCUMENT AMENDS DocumentRef-SPDXA:SPDXRef-DOCUMENT
RelationshipComment: This current document is an amendment of the SPDXA document.

Relationship: SPDXRef-CarolCompression DEPENDS_ON NONE
RelationshipComment: The package CarolCompression can be considered as a root with no dependencies.

Relationship: SPDXRef-BobBrowser CONTAINS NOASSERTION
RelationshipComment: The package BobBrowser may have other packages embedded in it, but the author has insufficient information to treat this as other than unknown at this point in time.

We need to generate this information for files in a crate, as well as for dependencies used.

The SPDX standard includes a lengthy list of known licenses. In many cases, projects just use those licenses, and no further license specification is necessary. However, sometimes projects don't use those licenses, or claim to use them but include their own modifications. In these cases, SPDX defines a mechanism for specifying non-standard licenses.

cargo-spdx needs to support the following:

• [ ] Detecting when non-standard licenses are in use.
• [ ] Producing the proper outputs in the SPDX document to represent those licenses.