how is cargo-auditable supposed to
replace dh-cargo-built-using, since metadata in Debian is tracked via
archive metadata (e.g. Sources/Packages/UDD entries) and not metadata
stored in the linker section of the executable? Wouldn't this be a
regression in comparison to the current status-quo, since it would
require the package to actually be installed (or at least downloaded and
unpacked) on the system?
Indeed it would.
As for complementing dh-cargo-built-using, this seems a nice added touch
which we maybe don't exactly need (again, we already track metadata in a
more efficient way for the purposes of Debian -- just run `apt info` on
any rust package, installed or not),
Yes, the motivation Alexander shared
in his reply is primarily for external scanners and supply chain transparency.
but which I would fully support if
the ecosystem converges towards using cargo-auditable.
As the maintainer of cargo-auditable, I am obviously biased, but it sure does look like the ecosystem is actively converging on cargo-auditable.
At least 6 Linux distributions build all their Rust packages with cargo-auditable already, and the data format is
widely understood, including by Docker.
I am not aware of any alternatives that would embed the dependency list into binaries. If Debian wanted to provide more transparency into the Rust builds without doing that, then generating a SBOM such as CycloneDX or SPDX and shipping it in the binary package would also accomplish that, but I am not aware of any precedent for that. (Full disclosure: I also maintain
cargo-cyclonedx).
Shipping the Cargo.lock file might also work in the context of Debian: normally the Cargo.lock file includes dev-dependencies and dependencies from other platforms (e.g. Windows) which are not relevant to the build, but due to the way Debian performs Rust builds with plenty of nightly-only flags, much if not all of that should be absent. (I think. I haven't investigated this in depth). I don't think there is currently a way to communicate the fact that this Cargo.lock is special and more accurate than normal to external tools right now. I am not aware of any prior art for bundling the Cargo.lock file either.
Or, if nobody cares enough about these use cases, you could simply do nothing.
So if there's any interest in integrating cargo-auditable, I'm happy to answer any questions, and otherwise I'll let you be.
Cheers!