| Filename | Latest commit message | Latest commit date |
|---|---|---|
Jorijn van der Graaf
2ef1e6b96a
All checks were successful
package / package (push) Successful in 1m17s
Crafter.Build's releases carry a Flatpak and nothing else since 2026-10-02 (imsd a625248): the rolling `latest` release's crafter-build-linux-x86_64-musl-v2.tar.gz that build-package.sh fetched is gone, so the push of 0.2.6 failed at `fetch crafter-build` (run 10, 2026-10-14, three 404s) and published nothing; the registry still serves 0.2.5. The move imsd made on 2026-10-04: install the Flatpak (net.catcrafts.CrafterBuild//stable from flatpak.catcrafts.net) in the job container and run it as crafter-build. bubblewrap inside the container needs a privileged runner, so the job runs on the `flatpak` label. The host keeps clang and llvm-ar for libqcomtee, which make-libqcomtee.sh compiles against the sysroot; the daemon's compiler, lld and libc++ are the Flatpak's, so the host packages that served the native test-suite run go. The sysroot gains llvm-runtimes, the package with the std module source of its own libc++ (libc++-dev ships none), added with --upgrade so a sysroot from before this change comes out with a matching libc++ and source. The README's Build section carries the install lines. Tested: build-package.sh run end to end on this commit in a privileged alpine:edge container (podman) on the workstation: crafter-build 2.1.0 (clang 23.1.2) from `stable`, the sysroot at libc++ and llvm-runtimes 23.1.3, daemon and agent cross-built, 8 suites passed natively, the three apks built, the daemon an aarch64 PIE against the sysroot's musl and libc++ (65 s). The rehearsed copy differs from this commit by the wrapping of one comment line. |
||
| .. | ||
| 20-focal64.manifest | ||
| 80-fingerprintd.preset | ||
| actions.conf.example | ||
| APKBUILD | ||
| build-package.sh | ||
| deploy-dev.sh | ||
| fingerprint-auth.pam | ||
| fingerprintd-agent.service | ||
| fingerprintd.json | ||
| fingerprintd.modules-load.conf | ||
| fingerprintd.post-install | ||
| fingerprintd.post-upgrade | ||
| fingerprintd.service | ||
| fingerprintd.tmpfiles.conf | ||
| fingers.conf.example | ||
| fpenrol.sh | ||
| fplearn.sh | ||
| fptrial.sh | ||
| make-bin-tarball.sh | ||
| make-libqcomtee.sh | ||
| make-sysroot.sh | ||
| mnt-persist.mount | ||
| net.reactivated.Fprint.conf | ||
| net.reactivated.fprint.device.policy | ||
| net.reactivated.Fprint.service | ||
| postlogin.pam | ||
| README.config.md | ||
fingerprintd.json — where it comes from, and why this exact file
The trustlet gates its config file on common.configuration_uuid and silently
falls back to built-in defaults on a mismatch, so the file is not decorative:
SYNC_CONFIG returning 0 is what makes the whole init chain run.
This copy is generated, not hand-written. Its source is fp6fpcfg.py in the
fp6 bring-up repo, which builds it from the captured stock configuration dump
(journal/fingerprint/captures/2026-08-25-focal64-effective-config-from-stock.txt):
utilities/fp6fpcfg.py --daemon --verbose > packaging/fingerprintd.json
sha256 begins b205c756914a66f1.
Why the --verbose variant
--verbose here is the trustlet's own log level, not the daemon's. It is
shipped because it is the file every accuracy number was measured on — 30/30
held presses, zero false accepts, 36-330 ms to a verdict — and the TA's log
level cannot be raised again by a runtime SYNC_CONFIG, so a session that
needs the matcher's own lines has to have started with it.
--daemon alone produces the same file with trustlet logging off (sha256
6c4503e628406424, four diagnosis.* keys differ and nothing else). It is
plausibly the better shipping default and it is untested: no rate in the
journal was measured on it. Switching is a measurement, not an edit.
The two policy keys
common.max_authentication_rescan_times: 0— at the stock budget a wrong finger never yields a terminal frame, so a PAM client waits forever for theverify-no-matchit needs.trustlet.enable_trusted_enrollment: false— skips the challenge compare and thehw_auth_tokenHMAC verify. pmOS has no Gatekeeper to issue a token and nothing on pmOS verifies one.