Re: [RFC] spdx30: name, version and purl for dependency downloads

[Stefano Tondo <stondo@gmail.com>]

On Tue, 10 Nov 2026 at 23:53, Joshua Watt <JPEWhacker@gmail.com> wrote:
> Perhaps, the better option would be to propagate the SRC_URI purls to
> the output packages, but apply some sort of (optional) filter that can
> remove a SRC_URI if it is not actually present in the output. That way,
> if we have positive confirmation that some input is not present in the
> output, we can remove its PURL from the output package (but, barring
> that, we include it).

Hi Joshua,

Thanks, that model makes sense to me. A purl stays unless there is
proof that the dependency is not in the output. For vulnerability
checks, that is the safer side.

The cargo prototype already works as that kind of filter.
cargo metadata --filter-platform resolves the dependencies for the
target. For python3-bcrypt, it gives the proof for 17 of the 42
crates: 5 are not used on the target, and 12 only run at build time
(build scripts and proc-macros). None of them end up in the binary,
so they lose their purl, and the 25 runtime crates keep it. For Go,
go version -m on each binary lists the modules compiled into it, so
it can give the same proof.

One question about the output side: how do you want the purls on the
output package? I see two options:

1. Add them to the externalIdentifier list of the output package, the
   way set_purls() handles SPDX_PACKAGE_URLS today.
2. Link the output package to the source download elements, which
   carry the purls, with a relationship such as contains.

Option 1 is simpler. But an external identifier says what the package
itself is, so a scanner can take python3-bcrypt for one of its crates.
Option 2 keeps each dependency as its own element. I prefer option 2,
unless you see a reason against it.

Thanks,
Stefano