Make bom-ref use relative paths for workspace items as well

[lfrancke]

Similar to PURLs

[Shnatsel]

Or just move away from using the filesystem paths in them for local dependencies. Technically the only requirement for them is to be unique; a hash will also work, although the human readability will suffer considerably.

[lfrancke]

Keeping them somewhat human-readable would be great, yes.

[ModestMannfred]

What if we replace "(path+file...)" on local dependencies with either a hash, a counting suffix or drop it all together based on a command line option? The name and version can remain leaving it mostly human-readable.

If the drop it altogether option is chosen, the user should be sure there aren't multiple dependencies with the same name and version on the system. Is this common?

[JamesTheAwesomeDude]

When the repository is tracked in (private) source control, it it possible to set bom-ref to the VCS URL?

Also, how should we handle the case of subordinate packages? Say I've got app foo built in Tauri, which creates a Node project at the root of the repository, and a Rust project in subfolder src-tauri; in that case, citing a raw git URL for the Tauri portion is going to be incorrect.

[ModestMannfred]

When the repository is tracked in (private) source control, it it possible to set bom-ref to the VCS URL?

I would also be interested in the response here. Also an extension of this for purls. As far as I can see Cargo Metadata exports crates.io or nothing. Perhaps the problem lies in not using cargo to maintain concurrent versioning, which doesn't work for our CI approach.

[Shnatsel]

PURLs do already include the VCS URL for dependencies from git; if you want to recover it, that's what you should be looking at, not bom-ref.

bom-ref is an opaque string according to the spec, so the only concerns for it are (1) being unique within the BOM and (2) being reproducible if we want reproducible SBOMs. There's an optional (3): being somewhat human-readable.