Fimeg/SouveraineOS
Watch
1
0
Fork
You've already forked SouveraineOS
 0
Code Releases Activity

task 44: the factor is a daemon, and the listener is not its job

Browse source 
Prior art checked: sailfish-fpd-community needs hybris, wrobelda's
libfprint branch is the only match-on-chip-over-QSEE example, and
nobody has done FPC over QSEE natively. One listener receiver per
device means the supplicant is a separate owner from the fp daemon.
This commit is contained in:
Fimeg 2026-08-09 09:54:49 -04:00
commit d09978df14
1 changed files with 37 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

42
docs/tasks/44-fingerprint-fpc1020.md
View file

@ -277,13 +277,43 @@ If the answer stays no, the honest outcome is Piece 1 plus a note, and face auth
(TASK-12) is the cheaper capability factor. Say so rather than leaving this
open forever.
## Where it plugs in if Piece 2 ever lands
## Where it plugs in — and it is a daemon, not a script
The capability tier model already has the shape — `PamContext`, `StepUpAuth`,
`LockContext`, `LockContentPolicy`. TASK-12 scopes face auth against exactly
those primitives; a fingerprint factor is symmetric with it and should reuse
that scoping rather than invent a parallel one. Anything touching the
permission/capability gating is in-tree, not vendored.
The capability tier model already has the shape — `StepUpAuth.qml`,
`LockContext.qml`, and the `souveraine-stepup` PAM service named in
`sessiond/protocol.rs:36`. TASK-12 scopes face auth against exactly those
primitives and explicitly refuses to wrap `gazed`: *"we own the source —
anything touching the permission/capability gating is in-tree, not vendored."*
A fingerprint factor is symmetric with it and inherits that decision.
So the deliverable is **`souveraine-fpd`**: a system daemon owning
`/dev/qseecom` and `input4`, driving the TA through the protocol in
`Pixel3Arch/docs/fpc-ta-protocol.md`, exposing enrol/verify over D-Bus the way
`gazed` does, and minting through `souveraine-stepup`. The `fp-*.py` tools are
instruments, not the factor.
### Prior art, checked 2026-08-09
| | |
|---|---|
| `sailfishos-open/sailfish-fpd-community` | Live (Nov 2025). Implements Jolla's `org.sailfishos.fingerprint1`, but reaches hardware through an **Android** library (`libbiometry_fp_api`, built in HADK, descended from Ubuntu Touch's `biometryd`). Unusable here — Souveraine has no hybris. Its **D-Bus surface and state machine are worth copying**, and its README doubles as a reverse-engineering method note. |
| `wrobelda/libfprint` branch `goodix-qsee` | The only working example of a libfprint driver doing **match-on-chip over QSEE**. Different TA, same architecture. The template if we ever want `fprintd`. |
| libfprint match-on-chip | Supported upstream — device features cover on-device storage and identify, so match-on-chip is not fighting the framework. |
| FPC over QSEE, natively on Linux | **Nobody has done it.** No prior art found. |
### The listener is a separate owner, and that is a constraint
Templates only persist through target 2, which goes out to a QSEE listener. The
kernel allows **one receiver per device, not per application**, so whoever
registers the file-service listener locks out every other QSEE client. That
argues the listener does *not* belong inside `souveraine-fpd` — it belongs in
one machine-wide supplicant, with the fingerprint daemon as a client of it.
`wrobelda/qsee-supplicant` is that component, is TA-agnostic, and made this
argument first.
Order that falls out: sensor attribution (`fp-finger.py`) → RAM-only enrol and
identify → supplicant + target 2 for persistence → daemon → PAM factor. Only
the last two are the "app".
## Do not