| Filename | Latest commit message | Latest commit date |
|---|---|---|
Jorijn van der Graaf
928fe1482e
The trustlet has always reported WHICH finger matched and the daemon only ever used it to answer yes. A table in /etc/fingerprintd/actions.conf now gives each finger a meaning: run a command as root, tell the user's session, or report no-match while doing one of those anyway -- which is duress, where the phone should look like it simply did not recognise the finger. Two rules shaped the design. Root does not launch applications. The daemon has no session bus, no display and no user environment, so a `session` rule carries no command at all: the daemon emits net.catcrafts.Fingerprintd1.FingerMatched(finger, uid) and an agent in the user's own session decides what that means from the user's own configuration. The only commands in the file are ones root is meant to run. Which makes the file a root shell, and the parser treats it as one. It is refused outright unless root owns it and nobody else can write it, group included. A malformed line rejects the WHOLE file rather than being skipped: applying the prefix would leave a policy nobody wrote, and the missing half could be the one that mattered. That property is tested, and the test caught it being false the first time -- rules accumulated before the bad line survived the rejection. A system command must be an absolute path, because resolving a bare name through PATH makes what root runs depend on an environment this daemon does not control. It is double-forked with a scrubbed environment so an action may outlive the daemon (a reboot) without ever stalling the worker thread that is the only thread allowed to touch the trustlet. Ordering is deliberate: the verdict override happens before the client is told, because that is the point of duress; the session signal and the root command happen after, on the same principle that keeps the harvest and the save off the unlock path. No actions.conf ships. An example goes to /usr/share/doc, because shipping a root shell nobody asked for is not a default. Not yet exercised on hardware. |
||
| .. | ||
| 20-focal64.manifest | ||
| 80-fingerprintd.preset | ||
| actions.conf.example | ||
| APKBUILD | ||
| build-package.sh | ||
| deploy-dev.sh | ||
| fingerprint-auth.pam | ||
| fingerprintd.json | ||
| fingerprintd.modules-load.conf | ||
| fingerprintd.service | ||
| fingerprintd.tmpfiles.conf | ||
| 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 | ||
| 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.