Catcrafts/fingerprintd
Watch
2
0
Fork
You've already forked fingerprintd
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
fingerprintd/packaging/APKBUILD

149 lines
7.3 KiB
Text
Raw Permalink Normal View History

Package the daemon, so a fingerprint survives a reflash An aport, the units, and everything a phone needs to come up with a working sensor without a single command being run by hand. Verified on the dev phone across two reboots: modules-load.d loads qcomtee, tmpfiles builds the SFS root, the mount unit brings up persist, and the daemon is ready 51 seconds into the boot, owning net.reactivated.Fprint with the enrolled finger visible. The packaging shape is the one imsd uses for 81voltd. A versioned provides="fprintd=..." satisfies plasma-workspace -- its Users KCM is the enrolment UI and speaks exactly this bus name -- and excludes the real fprintd, which is not tidiness: fprintd is D-Bus-activatable, so a client call would otherwise start it and fight us for the name. The cost is the fprintd-* CLIs, which go with the package. fprintd-pam is an install_if subpackage pinned to the exact fprintd version, so the provides breaks its condition and apk purges it -- taking pam_fprintd, which is the entire point of the daemon, with it. Depending on it explicitly is what keeps it, and it has no dependency on fprintd itself. Two things the packaging exposed in the daemon: The transcript is for experiments, not for a shipped daemon. A file per start in an unrotated directory, recording the time of every unlock, to say what the journal already has. It is now opt-in behind --log-dir, which is what deploy-dev.sh passes since fplearn.sh reads it. Taking it off the daemon path also took away the setvbuf it was doing as a side effect of dup2'ing fd 1, and under systemd stdout is a pipe, which means full buffering: the daemon started, worked, answered D-Bus calls, and printed nothing. A working daemon that looks hung. stdout is now line-buffered from the first line of main. The config ships as generated by fp6fpcfg.py --daemon --verbose, sha256 b205c756914a66f1, because that is the file every accuracy number was measured on. The quieter variant is untested and switching is a measurement. The trustlet is not here and never will be: focal64.mbn is a proprietary OEM-signed blob, and the unit's ConditionPathExists is what keeps the package inert without it -- as it does on a kernel with no CONFIG_QCOMTEE.
2026-09-05 02:52:01 +02:00
# SPDX-License-Identifier: GPL-3.0-only
# SPDX-FileCopyrightText: Copyright (C) 2026 Catcrafts®
# Maintainer: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
# Binary packaging: wraps a crafter-build binary cross-compiled per the
# README's "Cross-compiling" section into a proper apk — used by this repo's
# package CI (packaging/build-package.sh, which seds pkgver from
# implementations/main.cpp) and runnable by hand. The source tarball is
# produced by packaging/make-bin-tarball.sh. There is deliberately no
# source-building aport: the build driver is crafter-build, which is not in
# Alpine, so an APKBUILD that compiled from source could not be built by
# anyone but us either.
pkgname=fingerprintd
Depend on the extractor that understands our manifest, and restart on upgrade 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.
2026-09-05 20:22:17 +02:00
pkgver=0.2.3
Package the daemon, so a fingerprint survives a reflash An aport, the units, and everything a phone needs to come up with a working sensor without a single command being run by hand. Verified on the dev phone across two reboots: modules-load.d loads qcomtee, tmpfiles builds the SFS root, the mount unit brings up persist, and the daemon is ready 51 seconds into the boot, owning net.reactivated.Fprint with the enrolled finger visible. The packaging shape is the one imsd uses for 81voltd. A versioned provides="fprintd=..." satisfies plasma-workspace -- its Users KCM is the enrolment UI and speaks exactly this bus name -- and excludes the real fprintd, which is not tidiness: fprintd is D-Bus-activatable, so a client call would otherwise start it and fight us for the name. The cost is the fprintd-* CLIs, which go with the package. fprintd-pam is an install_if subpackage pinned to the exact fprintd version, so the provides breaks its condition and apk purges it -- taking pam_fprintd, which is the entire point of the daemon, with it. Depending on it explicitly is what keeps it, and it has no dependency on fprintd itself. Two things the packaging exposed in the daemon: The transcript is for experiments, not for a shipped daemon. A file per start in an unrotated directory, recording the time of every unlock, to say what the journal already has. It is now opt-in behind --log-dir, which is what deploy-dev.sh passes since fplearn.sh reads it. Taking it off the daemon path also took away the setvbuf it was doing as a side effect of dup2'ing fd 1, and under systemd stdout is a pipe, which means full buffering: the daemon started, worked, answered D-Bus calls, and printed nothing. A working daemon that looks hung. stdout is now line-buffered from the first line of main. The config ships as generated by fp6fpcfg.py --daemon --verbose, sha256 b205c756914a66f1, because that is the file every accuracy number was measured on. The quieter variant is untested and switching is a measurement. The trustlet is not here and never will be: focal64.mbn is a proprietary OEM-signed blob, and the unit's ConditionPathExists is what keeps the package inert without it -- as it does on a kernel with no CONFIG_QCOMTEE.
2026-09-05 02:52:01 +02:00
pkgrel=0
pkgdesc="Fingerprint daemon for the Fairphone 6 (FocalTech FT9391 behind QTEE)"
url="https://forgejo.catcrafts.net/Catcrafts/fingerprintd"
arch="aarch64"
license="GPL-3.0-only"
# GLib for the D-Bus interface; libc++ because the binary is a clang/libc++
# C++26 modules build linked dynamically against the phone's own runtime.
#
# fprintd-pam is pam_fprintd, which is the point of the whole daemon: it is
# what turns a matched finger into a login. It is an install_if subpackage
# conditioned on the EXACT version fprintd-pam was built against
# (i:fprintd=1.94.5-r1), so the provides below breaks that condition and apk
# would purge it as no-longer-needed. Depending on it explicitly is what keeps
# it. It has no dependency on fprintd itself, so nothing is being forced.
A verify nobody answered is not a failure, and the trustlet is not ours to ship Two things the packaging left behind. A verify that ran its 600-frame budget without the sensor being touched was reported to the client as verify-unknown-error. Nothing had gone wrong: nobody had pressed. It cost three verifications during packaging, each reading as a broken daemon. fprintd's contract is that a verify runs until the client stops it, so the frame cap bounds one trustlet scan session rather than the user's patience, and a window with no press simply runs again. Verified across the rollover: 600 frames untouched, "still waiting", then a press matching on its first contact frame in 44 ms. Presses that happen and never reach a verdict now report verify-retry-scan -- a bad scan, which fprintd has a word for, and not the matcher saying no. The cost is that an unanswered verify polls every ~200 ms for as long as the client holds it. The cure is measured and available -- gpio75 is silent at idle and bursts on contact -- but it would make the IRQ the only way a press is ever noticed, deleting the poll under every rate this daemon has been measured at. Noted where the loop waits, not done. And the trustlet: focal64.mbn is a proprietary OEM-signed blob, so the package ships a fp6-vendor-blobs manifest fragment instead, the same mechanism soc-fairphone-fp6-audio uses for the amp config. It needed a new directive there -- a QTEE image is an ELF header file plus one payload per program header, not one file -- and reassembly on the phone reproduces the image QTEE has accepted since August, byte for byte.
2026-09-05 04:01:06 +02:00
#
# fp6-vendor-blobs runs the manifest fragment below, which reassembles the
# trustlet out of the stock modem partition on first boot. Without it there is
# no matcher and the unit stays inert on its ConditionPathExists -- so this is
# a real dependency, not a nicety. It is an FP6 device package; so is this.
Depend on the extractor that understands our manifest, and restart on upgrade 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.
2026-09-05 20:22:17 +02:00
# The mbn directive the fragment uses arrived in 1-r2; the extractor before it
# exits on an unknown directive, which on a first boot would fail the blobs
# unit after the audio fragment had run and before this one could.
depends="dbus glib libc++ fprintd-pam fp6-vendor-blobs>=1-r2"
Package the daemon, so a fingerprint survives a reflash An aport, the units, and everything a phone needs to come up with a working sensor without a single command being run by hand. Verified on the dev phone across two reboots: modules-load.d loads qcomtee, tmpfiles builds the SFS root, the mount unit brings up persist, and the daemon is ready 51 seconds into the boot, owning net.reactivated.Fprint with the enrolled finger visible. The packaging shape is the one imsd uses for 81voltd. A versioned provides="fprintd=..." satisfies plasma-workspace -- its Users KCM is the enrolment UI and speaks exactly this bus name -- and excludes the real fprintd, which is not tidiness: fprintd is D-Bus-activatable, so a client call would otherwise start it and fight us for the name. The cost is the fprintd-* CLIs, which go with the package. fprintd-pam is an install_if subpackage pinned to the exact fprintd version, so the provides breaks its condition and apk purges it -- taking pam_fprintd, which is the entire point of the daemon, with it. Depending on it explicitly is what keeps it, and it has no dependency on fprintd itself. Two things the packaging exposed in the daemon: The transcript is for experiments, not for a shipped daemon. A file per start in an unrotated directory, recording the time of every unlock, to say what the journal already has. It is now opt-in behind --log-dir, which is what deploy-dev.sh passes since fplearn.sh reads it. Taking it off the daemon path also took away the setvbuf it was doing as a side effect of dup2'ing fd 1, and under systemd stdout is a pipe, which means full buffering: the daemon started, worked, answered D-Bus calls, and printed nothing. A working daemon that looks hung. stdout is now line-buffered from the first line of main. The config ships as generated by fp6fpcfg.py --daemon --verbose, sha256 b205c756914a66f1, because that is the file every accuracy number was measured on. The quieter variant is untested and switching is a measurement. The trustlet is not here and never will be: focal64.mbn is a proprietary OEM-signed blob, and the unit's ConditionPathExists is what keeps the package inert without it -- as it does on a kernel with no CONFIG_QCOMTEE.
2026-09-05 02:52:01 +02:00
# The versioned provides both satisfies plasma-workspace's fprintd dependency
# — its Users KCM is the fingerprint enrolment UI and speaks exactly this bus
# name — and EXCLUDES the real package, which is required rather than tidy:
# fprintd is D-Bus-activatable, so a client call would otherwise start the
# real daemon and fight for net.reactivated.Fprint. fprintd-pam is a separate
# package that does not depend on fprintd, so PAM keeps working.
#
# The cost, which is real: the fprintd-enroll/-list/-verify/-delete CLIs go
# away with the package. Enrolment then goes through Plasma's Users KCM.
provides="fprintd=$pkgver-r$pkgrel"
# The unit is the deliverable — a daemon holding QTEE's listener table open for
# the life of the boot is not something to start by hand — but abuild wants
# systemd files in their own package, and install_if puts them back on any
# system that has systemd. No OpenRC service: nothing here has ever been run
# under one, and the unit's conditions (the vendor blob, /dev/tee0) are what
# keep the package inert on a phone that cannot use it.
An agent, so a finger can mean something in your session The daemon announces every matched finger on the system bus and stops there, because root has no session bus, no display and no business starting your applications. fingerprintd-agent is the other half: it runs as you, subscribes properly rather than parsing gdbus monitor output, filters by uid because the signal is visible to every local user, and maps fingers to commands from a file you own and can edit without restarting anything. It is a separate binary and a separate subpackage because it is a separate trust domain. /etc/fingerprintd/actions.conf is a root shell and is guarded like one; ~/.config/fingerprintd/fingers.conf runs your commands as you, so it is an ordinary dotfile. Demonstrated on the phone: one press of the unlock finger both unlocks it and opens plasma-camera.
2026-09-05 06:21:53 +02:00
subpackages="$pkgname-agent $pkgname-systemd"
Package the daemon, so a fingerprint survives a reflash An aport, the units, and everything a phone needs to come up with a working sensor without a single command being run by hand. Verified on the dev phone across two reboots: modules-load.d loads qcomtee, tmpfiles builds the SFS root, the mount unit brings up persist, and the daemon is ready 51 seconds into the boot, owning net.reactivated.Fprint with the enrolled finger visible. The packaging shape is the one imsd uses for 81voltd. A versioned provides="fprintd=..." satisfies plasma-workspace -- its Users KCM is the enrolment UI and speaks exactly this bus name -- and excludes the real fprintd, which is not tidiness: fprintd is D-Bus-activatable, so a client call would otherwise start it and fight us for the name. The cost is the fprintd-* CLIs, which go with the package. fprintd-pam is an install_if subpackage pinned to the exact fprintd version, so the provides breaks its condition and apk purges it -- taking pam_fprintd, which is the entire point of the daemon, with it. Depending on it explicitly is what keeps it, and it has no dependency on fprintd itself. Two things the packaging exposed in the daemon: The transcript is for experiments, not for a shipped daemon. A file per start in an unrotated directory, recording the time of every unlock, to say what the journal already has. It is now opt-in behind --log-dir, which is what deploy-dev.sh passes since fplearn.sh reads it. Taking it off the daemon path also took away the setvbuf it was doing as a side effect of dup2'ing fd 1, and under systemd stdout is a pipe, which means full buffering: the daemon started, worked, answered D-Bus calls, and printed nothing. A working daemon that looks hung. stdout is now line-buffered from the first line of main. The config ships as generated by fp6fpcfg.py --daemon --verbose, sha256 b205c756914a66f1, because that is the file every accuracy number was measured on. The quieter variant is untested and switching is a measurement. The trustlet is not here and never will be: focal64.mbn is a proprietary OEM-signed blob, and the unit's ConditionPathExists is what keeps the package inert without it -- as it does on a kernel with no CONFIG_QCOMTEE.
2026-09-05 02:52:01 +02:00
# nothing is compiled here, and the aarch64 ELF's NEEDED entries must not be
# traced against an x86_64 build host
options="!check !tracedeps"
source="fingerprintd-$pkgver.tar.gz"
Depend on the extractor that understands our manifest, and restart on upgrade 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.
2026-09-05 20:22:17 +02:00
# apk swaps the binary on disk and leaves the running daemon alone; the
# script restarts it so an upgrade does not leave the old code answering.
install="$pkgname.post-upgrade"
Package the daemon, so a fingerprint survives a reflash An aport, the units, and everything a phone needs to come up with a working sensor without a single command being run by hand. Verified on the dev phone across two reboots: modules-load.d loads qcomtee, tmpfiles builds the SFS root, the mount unit brings up persist, and the daemon is ready 51 seconds into the boot, owning net.reactivated.Fprint with the enrolled finger visible. The packaging shape is the one imsd uses for 81voltd. A versioned provides="fprintd=..." satisfies plasma-workspace -- its Users KCM is the enrolment UI and speaks exactly this bus name -- and excludes the real fprintd, which is not tidiness: fprintd is D-Bus-activatable, so a client call would otherwise start it and fight us for the name. The cost is the fprintd-* CLIs, which go with the package. fprintd-pam is an install_if subpackage pinned to the exact fprintd version, so the provides breaks its condition and apk purges it -- taking pam_fprintd, which is the entire point of the daemon, with it. Depending on it explicitly is what keeps it, and it has no dependency on fprintd itself. Two things the packaging exposed in the daemon: The transcript is for experiments, not for a shipped daemon. A file per start in an unrotated directory, recording the time of every unlock, to say what the journal already has. It is now opt-in behind --log-dir, which is what deploy-dev.sh passes since fplearn.sh reads it. Taking it off the daemon path also took away the setvbuf it was doing as a side effect of dup2'ing fd 1, and under systemd stdout is a pipe, which means full buffering: the daemon started, worked, answered D-Bus calls, and printed nothing. A working daemon that looks hung. stdout is now line-buffered from the first line of main. The config ships as generated by fp6fpcfg.py --daemon --verbose, sha256 b205c756914a66f1, because that is the file every accuracy number was measured on. The quieter variant is untested and switching is a measurement. The trustlet is not here and never will be: focal64.mbn is a proprietary OEM-signed blob, and the unit's ConditionPathExists is what keeps the package inert without it -- as it does on a kernel with no CONFIG_QCOMTEE.
2026-09-05 02:52:01 +02:00
package() {
cd "$srcdir/fingerprintd-$pkgver"
install -Dm755 fingerprintd "$pkgdir"/usr/bin/fingerprintd
install -Dm644 fingerprintd.service \
"$pkgdir"/usr/lib/systemd/system/fingerprintd.service
install -Dm644 mnt-persist.mount \
"$pkgdir"/usr/lib/systemd/system/mnt-persist.mount
# enabled by preset, and by an explicit .wants link so a fingerprint
# surviving a reboot never depends on a manual systemctl enable. The
# mount needs neither: fingerprintd.service pulls it in with
# RequiresMountsFor.
install -Dm644 80-fingerprintd.preset \
"$pkgdir"/usr/lib/systemd/system-preset/80-fingerprintd.preset
mkdir -p "$pkgdir"/etc/systemd/system/multi-user.target.wants
ln -s /usr/lib/systemd/system/fingerprintd.service \
"$pkgdir"/etc/systemd/system/multi-user.target.wants/fingerprintd.service
# who may own and call the bus name
install -Dm644 net.reactivated.Fprint.conf \
"$pkgdir"/usr/share/dbus-1/system.d/net.reactivated.Fprint.conf
# replaces fprintd's activation file, which points at /usr/libexec/fprintd
install -Dm644 net.reactivated.Fprint.service \
"$pkgdir"/usr/share/dbus-1/system-services/net.reactivated.Fprint.service
# the action ids fprintd defined; see the file for what enforces them
install -Dm644 net.reactivated.fprint.device.policy \
"$pkgdir"/usr/share/polkit-1/actions/net.reactivated.fprint.device.policy
# the SFS root's directories and its two symlinks into the persist mount
install -Dm644 fingerprintd.tmpfiles.conf \
"$pkgdir"/usr/lib/tmpfiles.d/fingerprintd.conf
# qcomtee -> /dev/tee0
install -Dm644 fingerprintd.modules-load.conf \
"$pkgdir"/usr/lib/modules-load.d/fingerprintd.conf
# the trustlet's configuration, generated by fp6fpcfg.py from the captured
# stock dump — see packaging/README.config.md. Not a user config file:
# the TA discards a file whose configuration_uuid does not match, and the
# two policy keys in it were each forced by a measurement.
install -Dm644 fingerprintd.json \
"$pkgdir"/usr/lib/firmware/fingerprintd.json
A verify nobody answered is not a failure, and the trustlet is not ours to ship Two things the packaging left behind. A verify that ran its 600-frame budget without the sensor being touched was reported to the client as verify-unknown-error. Nothing had gone wrong: nobody had pressed. It cost three verifications during packaging, each reading as a broken daemon. fprintd's contract is that a verify runs until the client stops it, so the frame cap bounds one trustlet scan session rather than the user's patience, and a window with no press simply runs again. Verified across the rollover: 600 frames untouched, "still waiting", then a press matching on its first contact frame in 44 ms. Presses that happen and never reach a verdict now report verify-retry-scan -- a bad scan, which fprintd has a word for, and not the matcher saying no. The cost is that an unanswered verify polls every ~200 ms for as long as the client holds it. The cure is measured and available -- gpio75 is silent at idle and bursts on contact -- but it would make the IRQ the only way a press is ever noticed, deleting the poll under every rate this daemon has been measured at. Noted where the loop waits, not done. And the trustlet: focal64.mbn is a proprietary OEM-signed blob, so the package ships a fp6-vendor-blobs manifest fragment instead, the same mechanism soc-fairphone-fp6-audio uses for the amp config. It needed a new directive there -- a QTEE image is an ELF header file plus one payload per program header, not one file -- and reassembly on the phone reproduces the image QTEE has accepted since August, byte for byte.
2026-09-05 04:01:06 +02:00
# the trustlet is NOT in this package and never will be: it is a
# proprietary OEM-signed blob. This tells fp6-vendor-blobs how to
# reassemble it from the phone's own stock partitions, which is the
# same mechanism soc-fairphone-fp6-audio uses for the amp config.
install -Dm644 20-focal64.manifest \
"$pkgdir"/usr/share/fp6-vendor-blobs/manifest.d/20-focal64.manifest
Give a finger a meaning beyond "it was you" 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.
2026-09-05 05:12:41 +02:00
# The PAM service kscreenlocker substacks and Alpine does not provide.
# Vendor directory, so /etc/pam.d still overrides it.
install -Dm644 fingerprint-auth.pam \
"$pkgdir"/usr/lib/pam.d/fingerprint-auth
Ship postlogin too, the other half of the seam kscreenlocker expects fingerprint-auth alone was not enough. /etc/pam.d/kde-fingerprint is written for a Fedora/authselect layout and its auth stack is two lines: a substack of fingerprint-auth followed by an include of postlogin. Alpine ships neither. With only the first supplied, the fingerprint MATCHED and PAM still answered Permission denied -- the include of a missing service failing after the match had already succeeded, which is a confusing way to be told a file is absent. The daemon's own log said MATCH while pamtester said no. On Fedora postlogin does lastlog and umask bookkeeping. Nothing here needs that; what is needed is that the seam exists and contributes nothing, so the stack's result stays the one the fingerprint substack produced. Hence four optional pam_permit lines and a comment explaining why it is deliberately empty rather than merely unfinished. Also observed while testing, and worth knowing before anyone calls this broken: the lock screen arms fingerprint ONCE when it appears, waits 30 seconds -- pam_fprintd's own timeout -- and then cancels and falls back to a password. Pressing outside that window reaches nothing at all, and the daemon records it as `verify: cancelled over 0 press(es)`.
2026-09-05 05:56:47 +02:00
install -Dm644 postlogin.pam \
"$pkgdir"/usr/lib/pam.d/postlogin
Give a finger a meaning beyond "it was you" 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.
2026-09-05 05:12:41 +02:00
# Documentation, not configuration: shipping an /etc/fingerprintd/
# actions.conf would be shipping a root shell nobody asked for. The
# feature is off until an administrator installs one.
install -Dm644 actions.conf.example \
"$pkgdir"/usr/share/doc/$pkgname/actions.conf.example
An agent, so a finger can mean something in your session The daemon announces every matched finger on the system bus and stops there, because root has no session bus, no display and no business starting your applications. fingerprintd-agent is the other half: it runs as you, subscribes properly rather than parsing gdbus monitor output, filters by uid because the signal is visible to every local user, and maps fingers to commands from a file you own and can edit without restarting anything. It is a separate binary and a separate subpackage because it is a separate trust domain. /etc/fingerprintd/actions.conf is a root shell and is guarded like one; ~/.config/fingerprintd/fingers.conf runs your commands as you, so it is an ordinary dotfile. Demonstrated on the phone: one press of the unlock finger both unlocks it and opens plasma-camera.
2026-09-05 06:21:53 +02:00
# The session half; split out below.
install -Dm755 fingerprintd-agent "$pkgdir"/usr/bin/fingerprintd-agent
install -Dm644 fingerprintd-agent.service \
"$pkgdir"/usr/lib/systemd/user/fingerprintd-agent.service
install -Dm644 fingers.conf.example \
"$pkgdir"/usr/share/doc/$pkgname/fingers.conf.example
}
agent() {
pkgdesc="Run things in your session when a fingerprint matches"
# Useful only against a daemon that emits the signal, but it is a
# SEPARATE package because it is a separate trust domain: it runs as the
# user, reads a config the user owns, and starts the user's software.
depends="$pkgname=$pkgver-r$pkgrel"
amove usr/bin/fingerprintd-agent
amove usr/lib/systemd/user/fingerprintd-agent.service
amove usr/share/doc/$pkgname/fingers.conf.example
Package the daemon, so a fingerprint survives a reflash An aport, the units, and everything a phone needs to come up with a working sensor without a single command being run by hand. Verified on the dev phone across two reboots: modules-load.d loads qcomtee, tmpfiles builds the SFS root, the mount unit brings up persist, and the daemon is ready 51 seconds into the boot, owning net.reactivated.Fprint with the enrolled finger visible. The packaging shape is the one imsd uses for 81voltd. A versioned provides="fprintd=..." satisfies plasma-workspace -- its Users KCM is the enrolment UI and speaks exactly this bus name -- and excludes the real fprintd, which is not tidiness: fprintd is D-Bus-activatable, so a client call would otherwise start it and fight us for the name. The cost is the fprintd-* CLIs, which go with the package. fprintd-pam is an install_if subpackage pinned to the exact fprintd version, so the provides breaks its condition and apk purges it -- taking pam_fprintd, which is the entire point of the daemon, with it. Depending on it explicitly is what keeps it, and it has no dependency on fprintd itself. Two things the packaging exposed in the daemon: The transcript is for experiments, not for a shipped daemon. A file per start in an unrotated directory, recording the time of every unlock, to say what the journal already has. It is now opt-in behind --log-dir, which is what deploy-dev.sh passes since fplearn.sh reads it. Taking it off the daemon path also took away the setvbuf it was doing as a side effect of dup2'ing fd 1, and under systemd stdout is a pipe, which means full buffering: the daemon started, worked, answered D-Bus calls, and printed nothing. A working daemon that looks hung. stdout is now line-buffered from the first line of main. The config ships as generated by fp6fpcfg.py --daemon --verbose, sha256 b205c756914a66f1, because that is the file every accuracy number was measured on. The quieter variant is untested and switching is a measurement. The trustlet is not here and never will be: focal64.mbn is a proprietary OEM-signed blob, and the unit's ConditionPathExists is what keeps the package inert without it -- as it does on a kernel with no CONFIG_QCOMTEE.
2026-09-05 02:52:01 +02:00
}
systemd() {
install_if="$pkgname=$pkgver-r$pkgrel systemd"
amove usr/lib/systemd
amove etc/systemd
}
Reference in a new issue Copy permalink