1 Commits
Author SHA1 Message Date
KomhandClaude Opus 4.8 b1ea2acb30 ci: exercise apply_extra as an uncapable root for newly added apps
Nothing in CI reached the code path that broke six apps for every user
who installed system-wide. build-app.sh only builds, and extra-data is
fetched at install time, so a green build says nothing about whether an
app installs. A --user install misses it too: there apply_extra runs as
the invoking user, and the ownership restore that fails under root never
happens.

scripts/check-apply-extra.sh closes that gap. It downloads the pinned
artifact, verifies its sha256, and runs the app's real apply_extra.sh in
a sandbox mirroring what flatpak-system-helper imposes: uid 0, all
capabilities dropped, no network, no /proc, runtime at /usr, extra-data
bound at /app/extra. bwrap --unshare-user gives us that without needing
root: a chown to an unmapped uid fails there just as a dropped CAP_CHOWN
does on the real thing.

pr-checks runs it for apps a PR *adds* -- the moment an unpack script and
an upstream builder's uid first meet review. Scoping it there keeps the
artifact download (hundreds of MB for some apps) off every pin bump and
off refactors like the one that prompted this. The playbook asks
contributors to run it by hand whenever they touch an unpack script or
re-pin to an artifact from a new builder, which is the gap that remains.

tests/test_check_apply_extra.sh is hermetic: it builds a zip carrying an
Info-ZIP 0x7875 field with uid/gid 1001 -- what a release archive built
on CI without fakeroot looks like -- serves it over file://, and asserts
the checker rejects an unpack without --no-same-owner and accepts one
with it. Verified it fails against a mutant checker that ignores the
exit code, so it is testing what it claims to.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
2026-07-10 10:31:32 +08:00