Motivation
Releases currently ship linux-amd64 tarballs only. arm64 Linux fleets are
increasingly common (AWS Graviton, Ampere, Raspberry Pi, Apple-Silicon VMs),
and downstream tooling that deploys cbom-generator from your release assets
(in our case: CertInventory, which wraps it as an endpoint scanner) has to
special-case arm64 with self-compiled builds.
Evidence it's low-effort: v1.9.4 builds cleanly on aarch64
Built natively on Ubuntu 24.04 (aarch64), GCC 13.3, both against distro
OpenSSL 3.0 and a static OpenSSL 3.5.4 — the scanner runs and produces valid
CycloneDX output. The only obstacle was -Werror turning a GCC 13
-Wformat-truncation diagnostic into a build failure:
src/main.c:4968: error: '%d' directive output may be truncated writing
between 1 and 10 bytes into a region of size 8 [-Werror=format-truncation=]
snprintf(break_str, sizeof(break_str), "%d", break_year);
Workaround: -DCMAKE_C_FLAGS="-Wno-error=format-truncation". A one-line fix
(e.g. char break_str[8] → char break_str[16]) would let arm64 (and any
GCC ≥ 13 host) build with the default flags. Happy to send that as a separate
tiny PR if useful.
Suggested implementation
- GitHub Actions now offers free hosted arm64 runners for public repos
(ubuntu-24.04-arm), so the existing release job can build both
architectures natively — no cross-compilation or QEMU needed.
- Asset naming consistent with the current convention:
cbom-generator-<version>-linux-arm64.tar.gz, listed in checksums.txt
alongside the amd64 entry.
Thanks for the tool — the CBOM output has been working great for us on both
architectures.
Motivation
Releases currently ship
linux-amd64tarballs only. arm64 Linux fleets areincreasingly common (AWS Graviton, Ampere, Raspberry Pi, Apple-Silicon VMs),
and downstream tooling that deploys cbom-generator from your release assets
(in our case: CertInventory, which wraps it as an endpoint scanner) has to
special-case arm64 with self-compiled builds.
Evidence it's low-effort: v1.9.4 builds cleanly on aarch64
Built natively on Ubuntu 24.04 (aarch64), GCC 13.3, both against distro
OpenSSL 3.0 and a static OpenSSL 3.5.4 — the scanner runs and produces valid
CycloneDX output. The only obstacle was
-Werrorturning a GCC 13-Wformat-truncationdiagnostic into a build failure:Workaround:
-DCMAKE_C_FLAGS="-Wno-error=format-truncation". A one-line fix(e.g.
char break_str[8]→char break_str[16]) would let arm64 (and anyGCC ≥ 13 host) build with the default flags. Happy to send that as a separate
tiny PR if useful.
Suggested implementation
(
ubuntu-24.04-arm), so the existing release job can build botharchitectures natively — no cross-compilation or QEMU needed.
cbom-generator-<version>-linux-arm64.tar.gz, listed inchecksums.txtalongside the amd64 entry.
Thanks for the tool — the CBOM output has been working great for us on both
architectures.