Generate BOM "metadata" section

[TedDriggs]

This section contains data that's available from Cargo.toml:

• timestamp
• tools
• authors
• component

Adding authors and component are the more difficult of the two, due to cargo workspaces and multiple binaries.

In the simple case, cargo cyclonedx is invoked on a single crate, which is either a library or a binary. In that case, we can generate exactly 1 BOM with all four of the above fields populated.

If cargo cyclonedx is invoked on a crate which is both a library and a binary, or declares multiple targets (I think these are the binaries, but need to test that), then should cargo cyclonedx generate 1 BOM per binary target? That seems reasonable as long as it doesn't produce one for every example and integration test. Another thing to check here would be that the cargo crate surfaces auto-discovered targets properly.

If cargo cyclonedx is invoked on a workspace, what's the desired behavior? Some options would include:

• Prefix each output file name with the workspace member name, e.g. /crate1.bom.xml
• Write the BOMs into the workspace member folders, e.g. /crate1/bom.xml
• Write the BOMs into their own directory, e.g. boms/crate1.xml

[TedDriggs]

@stevespringett I've got most of this working and will submit a PR soon. For the component section the code needs to decide whether it's dealing with a library or application. This is a bit tricky, since a crate can contain both. For now, I've gone down the path of "if it has a binary target, it's an application", since I'd expect that to be the default that someone would want. Please let me know if there's a better way.

[stevespringett]

@TedDriggs I think that's a reasonable approach.

[khuey]

Was a plan for cargo workspaces ever designed/implemented?

At my company all of our code lives in a single giant workspace. We want to produce a SBOM for certain crates that are distributed to our customers, but there are other crates that are not redistributed and pull in their own dependencies that we would prefer not to include (both to ensure that we're providing our customers with only relevant information and to avoid leaking implementation details of nonredistributed binaries).

[lfrancke]

As far as I read this what's missing is better handling of packages with multiple targets (e.g. library and binary) for which a draft PR is up. It will almost certainly not be merged in its current form but it's something we'll work on.

@khuey If you're still interested in this issue please ping here. I'm not 100% sure I understand what you're looking for. This will work with workspaces and it will create a BOM for all of them by default. There is no way to skip a workspace member right now but that shouldn't hurt as you don't have to distribute that bom?