Build audit

Build matrix

Releases are produced by a 5-target GitHub Actions matrix on native runners:

aarch64-windows is deferred — MSYS2 MINGW64 doesn't ship a mingw-w64-aarch64-gcc package. Restoring would require either LLVM clang with -target aarch64-w64-windows-msvc, or building mingw-w64-aarch64 from source.

Two-stage CI

1. build-and-test.yml — runs on every push to main and every pull request. Build the full matrix, run smoke, upload dist/ as workflow artifacts (7-day retention) so a human reviewer can grab any per-target binary. The matrix is the gate for merging a PR.
2. release.yml — runs on tag push (v*) and workflow_dispatch. The build matrix is intentionally identical; only after the per-target artifact uploads, a final job publishes to GitHub Releases via softprops/action-gh-release with bundled per-archive .sha256 and a top-level SHA256SUMS.

Two stages avoids the trigger / dispatch pain of gh workflow run; a tag push produces a release in one flow, and build-and-test.yml stays cheap because it runs on every PR but doesn't publish.

Smoke test policy

The smoke script (scripts/smoke.sh) does two things:

1. Version check — confirm the freshly-built lha reports the expected version banner.
2. CLI decode round-trip — run lha l and lha xq against the first .lzh / .lzs / .pma under upstream/lhasa/test/archives/ — the regression corpus upstream uses for make check. Confirms the binary we shipped actually drives liblhasa end-to-end on real archive content.

We don't run upstream's make check directly: its test driver sources test_extract.sh via relative path, which breaks under the parallel-build out-of-tree pattern this CI uses for musl+glibc isolation. Driving lha against the same archive corpus covers the same ground from the CLI side.

Checksums

Every release ships:

• One .sha256 per archive (next to it, same name with .sha256 appended).
• One top-level SHA256SUMS listing all archives (one line each, basename-keyed so sha256sum -c SHA256SUMS works from any directory).

x eget ljh-sh/lhasa verifies each archive's per-tarball .sha256 against the SHA256SUMS it pulls from the release. Verification is end-to-end TLS + SHA256, no further signature layer.

Dependency footprint

The vendored lhasa tree has zero external library dependencies — no zlib, no libiconv, no libcurl, no libarchive. The autotools configure.ac only probes for the C compiler and Libtool; nothing optional.

What this means for each platform:

• Linux musl — fully static, no glibc dependency. The same binary runs on Alpine, Debian, Ubuntu, RHEL, Fedora, Arch, and every other Linux distro. Verified via ldd in CI.
• macOS — system libc++ / libSystem only — those are part of macOS and don't ship as dyld-private install paths. Verified by otool -L — the CI fails if the output links to a Homebrew path.
• Windows — MinGW-built static archive; no VC redistributables needed.

OpenSSF Scorecard

OpenSSF Scorecard badges are not currently enabled for this repository. Two prerequisites that would need to happen before they’re meaningful:

• Upstream commit signing — Scorecard's Signed-Commits check requires upstream fragglet/lhasa maintainer (Simon Howard) to GPG-sign release commits. Currently the subtree pull records the upstream SHA in the merge commit body, but it’s not cryptographically bound to an identity.
• Reproducible builds — Scorecard would promote us if independent rebuilds of the release tarballs (from source) produce matching SHA256SUMS. We don’t have that infrastructure yet; CI matrix builds per-target binaries, but no second channel re-derives the hashes from a clean source checkout.

The repo currently passes most non-cryptographic Scorecard checks (License, Token-Permissions, Pinned-Dependencies). To make the OpenSSF story honest we need to ship the two items above before flipping the badge on. The full per-check scorecard inspection is left as a future task; for now this section documents what’s missing rather than claiming a passing posture.