| Filename | Latest commit message | Latest commit date |
|---|---|---|
Jorijn van der Graaf
5727116c68
All checks were successful
package / package (push) Successful in 1m39s
fp6-vendor-blobs learned the mbn directive in 1-r2. The extractor before it exits on an unknown directive, so a fresh flash with 1-r1 and our 20-focal64.manifest processes the audio fragment and then fails the blobs unit on ours: a red unit, no trustlet, and nothing in the daemon's own logs to say why. Saying >=1-r2 makes apk refuse a combination that cannot work instead of installing one that fails at first boot. Existing installs never saw this -- the old fast path only checks file lines and exits before the dispatcher. apk also swaps the binary on disk and leaves the running daemon alone, which is how 0.2.2's FingerMatched signal first presented: a clean MATCH in the journal and nothing downstream, because the boot's 0.1.3 was still answering. A post-upgrade try-restart closes that. A daemon that is not running stays not running, and a build chroot without systemd is left alone. 0.2.3, so the package CI publishes it. |
||
| .. | ||
| 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-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.