anchore
Debian - Static-Built-Using for Go/Rust packages
What would you like to be added: Static-Built-Using (formerly 'X-Cargo-Built-Using'/'Built-Using') should be parsed/retained in 'parseDpkgStatusEntry'.
Why is this needed: Go/Rust packages make use of static linking in Debian. The 'Static-Built-Using' field in the binary package is used as a record of the exact version of source code that was used during the build. This information is an important constituent part of SBOM that should be preserved.
Additional context: A few heavily abridged examples from Debian Trixie:
Package: docker.io
Source: docker.io (26.1.5+dfsg1-9)
Version: 26.1.5+dfsg1-9+b9
Built-Using: golang-go.crypto (= 1:0.25.0-1)
Package: debiman
Version: 0.0~git20220907.a582536-1.1
Static-Built-Using: golang-go.crypto (= 1:0.23.0-1)
Package: ripgrep
Source: rust-ripgrep (14.1.1-1)
Version: 14.1.1-1+b4
X-Cargo-Built-Using: rust-serde (= 1.0.217-1)
Thanks for the issue @roliver-rpi! When one of the team has time we will try to investigate to make sure this carries through to the SBOM output.
For implementers coming through later here is a way to view the example for ripgrep.
After installing with apt install ripgrep see below.
I've spaced out the requested field to parse. Normally there is no blank line with the output with no extra /n character:
root@c10e4fe935eb:/# apt show ripgrep
Package: ripgrep
Version: 0.10.0-2
Priority: optional
Section: utils
Source: rust-ripgrep
Maintainer: Debian Rust Maintainers <[email protected]>
Installed-Size: 3646 kB
Depends: libc6 (>= 2.18), libgcc1 (>= 1:4.2)
Homepage: https://github.com/BurntSushi/ripgrep
X-Cargo-Built-Using: rust-aho-corasick (= 0.6.9-1), rust-atty (= 0.2.11-1), rust-base64 (= 0.10.0-1), rust-bitflags (= 1.0.4-1), rust-bytecount (= 0.5.1-1), rust-byteorder (= 1.3.1-1), rust-cfg-if (= 0.1.6-1), rust-clap (= 2.32.0-4), rust-crossbeam-channel (= 0.3.8-1), rust-crossbeam-utils (= 0.6.5-1), rust-encoding-rs (= 0.8.15-1), rust-encoding-rs-io (= 0.1.4-1), rust-fnv (= 1.0.6-1), rust-globset (= 0.4.2-1), rust-grep-cli (= 0.1.1-1), rust-grep (= 0.2.3-1), rust-grep-matcher (= 0.1.1-1), rust-grep-printer (= 0.1.1-2), rust-grep-regex (= 0.1.1-1), rust-grep-searcher (= 0.1.3-1), rust-ignore (= 0.4.6-1), rust-itoa (= 0.4.3-1), rust-lazy-static (= 1.2.0-1), rust-libc (= 0.2.48-1), rust-log (= 0.4.6-1), rust-memchr (= 2.1.3-1), rust-memmap (= 0.7.0-1), rust-num-cpus (= 1.8.0-1), rust-regex (= 1.0.5-1), rust-regex-syntax (= 0.6.5-1), rust-ryu (= 0.2.7-1), rust-same-file (= 1.0.4-1), rust-serde (= 1.0.87-1), rust-serde-json (= 1.0.38-1), rust-smallvec (= 0.6.8-1), rust-strsim (= 0.7.0-1), rust-termcolor (= 1.0.4-1), rust-textwrap (= 0.11.0-1), rust-thread-local (= 0.3.6-1), rust-ucd-util (= 0.1.1-1), rust-unicode-width (= 0.1.5-1), rust-unreachable (= 1.0.0-1), rust-utf8-ranges (= 1.0.2-1), rust-void (= 1.0.2-1), rust-walkdir (= 2.2.7-1)
Download-Size: 1006 kB
APT-Manual-Installed: yes
APT-Sources: http://archive.debian.org/debian buster/main arm64 Packages
Description: Recursively searches directories for a regex pattern
I've also added needs discussion to this one for this week. We probably want to cover as a team if we're just passing the metadata through or if we want to update our relationships or create other packages based on this information.
We'll have to account for al instances of the field since the issue mentions Static-Built-Using . In the investigation output we see X-Cargo-Built-Using and we can also see Built-Using field in other examples.
I believe that Static-Built-Using is the consensus that has been reached by Debain Rust/Go teams and is what is currently documented in the deb-control(5) man page.
There's some additional context on this (and discussion of previous/current use of X-Cargo-Built-Using and Built-Using) on the following Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069256
Just to make sure the last bit of our livestream conversation doesn't get lost: @spiffcs mentioned we could have discrepancies with binary analysis of Go and Rust (and other) binaries, so there are a number of things to look into with this request. I believe we all agreed that we want to surface these as packages, which it seems like we may have type, name, and version for... or at least name and version. But we need to think carefully about the deduplication behavior here to try to get the most accurate / best results.
