Sign in

Search issue titles and bodies, change requests and comments. Private repositories you cannot read are not included.
vole
Clone

Read only, no credentials:

https://rodent.software/vole.git

Write over SSH with a registered key:

git clone ssh://git@rodent.software:2222/vole.git

A free and open-source forge that lives in your Git repo.

#107

Publish a bill of materials with each release

merged · by keenan 10d ago · merged into main at 122a697b by keenan 10d ago

keenan opened this 10d ago

Closes #93.

Why

A release attached binaries, packages and SHA256SUMS, but not the component list they were built from. Someone matching an advisory against a downloaded binary had to check out the tag and rebuild the module graph by hand.

What changed

  • .vole/workflows/release.yaml gains an sbom step between the package build and the checksums. It runs cyclonedx-gomod pinned at v1.9.0, the way nfpm and govulncheck are pinned, so a local run and a release run name the same components. It reads the module graph, so it needs neither a compiled binary nor either cross compiler.
  • The build clock is removed from the file. cyclonedx-gomod stamps metadata.timestamp from the wall clock, which would make every build of one tag differ. The step rewrites it from SOURCE_DATE_EPOCH, the tag’s commit time, and then greps for the result: a substitution that matched nothing fails the job instead of shipping the clock.
  • Checksums are now their own step, after the SBOM, so SHA256SUMS covers it: dist/vole-<version>.sbom.cdx.json.
  • The SBOM is a release artifact (release: true), so it appears on the release page beside the packages.
  • docs/releases.md gains A bill of materials for each release: what it covers, how to regenerate it, and the two limits below.

Verification

  • vole workflow run release in the pinned image, against a throwaway local tag: all steps pass, the SBOM lands at 22 components, the checksum file names it, and the run ends ok: 1 job(s). The tag was deleted afterwards.
  • Same tag, SBOM step run twice: byte-identical, timestamp pinned to the commit time, no serial number.
  • go list -deps for ./cmd/vole under goarch=amd64 and goarch=arm64 hashes to the same module set, which is what justifies one file for both architectures.
  • vole workflow run verify: all steps green, 0 reachable vulnerabilities.

What it does not cover

Two limits are written into the docs rather than papered over:

  • The system SQLite library is not a Go module. The SBOM names github.com/mattn/go-sqlite3, the binding, not the libsqlite3-0 version underneath. dpkg -s vole and rpm -q --requires vole answer that for the installed system. Putting the library in the BOM needs a second component merged in — python3 in the release image plus a post-processor, or cyclonedx-cli merge as another pinned tool. Left out deliberately; see the comment on #93.
  • Licences are CycloneDX evidence, not assertions. The detector reports what it finds (10 MIT, 5 BSD-3-Clause, 2 Apache-2.0, 4 BSD-Source-Code) without claiming it is correct. #95 can build its allowlist on that output instead of adding another scanner.

Discussion (0)

No discussion yet.