| Filename | Latest commit message | Latest commit date |
|---|---|---|
Jorijn van der Graaf
2a4427919e
Some checks failed
image / image (push) Failing after 57m23s
The daemon's own package CI publishes it to the registry the same way imsd's does, so the image takes it from there: the exact apk a user later gets via apk upgrade, sha256-pinned, re-signed for the chroot. Section 3b now fetches both sets, and every fetched file must have a pin -- the check used to be `grep . | sha256sum -c`, which an empty pin list would have sailed through with nothing checked. Three apks: the daemon, its systemd units, and the session agent, which does nothing until a user writes ~/.config/fingerprintd/fingers.conf. The daemon needs the kernel aport's CONFIG_QCOMTEE=m (pkgrel 101) and fp6-vendor-blobs 1-r2's mbn directive to reassemble the trustlet, both built in this run; 0.2.3 says >=1-r2 so a mismatched pair is refused rather than installed. The CI publish step skips fingerprintd-* like imsd-*: registry-sourced, not ours to republish. README: fingerprint in the list, and the two things a user will otherwise report as a dead sensor -- the lock screen listens for 60 seconds after it appears, and a held press is what the matcher was measured on -- plus the untested question of stock Android's own fingerprints after using this. Verified on the dev phone (fp6 repo journal/fingerprint/, 2026-09-05): the registry 0.2.2 package enrols through Plasma's Users page and unlocks the lock screen; 0.2.3 differs by the dependency and a post-upgrade restart. The image build itself, with the fprintd purge inside the chroot, runs first in CI. |
||
| .. | ||
| workflows | ||