feat(fingerprint): password OR fingerprint in parallel at one prompt
Some checks failed
Check / eval (push) Failing after 2m45s
Some checks failed
Check / eval (push) Failing after 2m45s
Bernardo promoted the PROPOSED item live: with fingerprint PAM on, sudo/login should accept whichever factor comes first instead of pam_fprintd's wait-for-the-reader-then-password. Stock PAM cannot express parallel factors (linux-pam#301), so this packages pam-fprint-grosshack v0.3.0 (pkgs/, pinned from GitLab — the field-standard fprintd fork), source-reviewed before packaging: every failure path (no reader, no prints, fprintd absent/hung, timeout, password typed) returns PAM_AUTHINFO_UNAVAIL and falls through; a typed password is only ferried via PAM_AUTHTOK to the stock `auth sufficient pam_unix.so … try_first_pass` rule — the module never validates passwords itself, so it cannot lock out password login. New option nomarchy.hardware.fingerprint.parallel, default TRUE (the better UX is what opting into fingerprint PAM buys; false = stock sequential). Wiring swaps the modulePath of stock fprintd's rule slot (mkForce) so the sufficient-before-pam_unix ordering is inherited, not recomputed. README + downstream template rows added. Verified: V2 — checks.hardware-toggles extended to three nodes, green: parallel node asserts the grosshack auth line precedes pam_unix in /etc/pam.d/sudo and that with NO reader a correct password still passes sudo while a wrong one fails (the lockout-safety invariant); seqpam node gets stock pam_fprintd and no grosshack; nopam gets neither. flake check + option-docs + template-sot green. V3 pending (HARDWARE-QUEUE, AMD dev box): the real type-or-touch race, fprintd-stopped fallback, hyprlock/greeter after a fingerprint win. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -134,18 +134,11 @@ high-ROI, etc.) live in the journal + ROADMAP — not here.*
|
||||
fixture. Control-center / MOTD already mention these; the gap is the
|
||||
silent first *graphical* session for people who never open those.
|
||||
|
||||
- **Fingerprint *or* password, in parallel** (2026-07-11, Bernardo) —
|
||||
`fingerprint.pam` gives pam_fprintd's sequential UX: sudo waits on
|
||||
the reader, password only after failure/timeout. Bernardo wants
|
||||
either factor accepted at the same prompt (type the password *or*
|
||||
touch the sensor, whichever comes first). Stock PAM can't express
|
||||
this; needs a parallel-conversation module (e.g. `pam-any`, not in
|
||||
nixpkgs — would be a new package + `fingerprint.pam = "any"` mode).
|
||||
Cost: medium (package + PAM wiring + careful lockout testing on real
|
||||
hardware). Security note: keep sudo fallback sane if fprintd hangs.
|
||||
|
||||
_(#80–#83 + #85–#88 shipped 2026-07-11. Theme A day-2 + neon-glass finish
|
||||
shipped — VISION ✓. Dock/hibernate V3 → HARDWARE-QUEUE.)_
|
||||
shipped — VISION ✓. Dock/hibernate V3 → HARDWARE-QUEUE. Parallel
|
||||
fingerprint-or-password shipped 2026-07-12 (Bernardo promoted it live;
|
||||
`fingerprint.parallel`, pam-fprint-grosshack) — reader V3 →
|
||||
HARDWARE-QUEUE.)_
|
||||
|
||||
### v1.0 pointer
|
||||
|
||||
|
||||
@@ -59,6 +59,19 @@ the **T14s** (webcam case).
|
||||
the re-lit panel. If that happens on hardware, the "Laptop screen
|
||||
off" row needs a rework (mirror instead of disable, or drop until
|
||||
a Hyprland bump) — file it as a NOW bug with the coredump.
|
||||
- [ ] **Parallel fingerprint-or-password on the real reader** (AMD dev
|
||||
box, 2026-07-12) — with a finger enrolled and
|
||||
`fingerprint.pam = true` (parallel is the default): `sudo -k true`
|
||||
must show ONE prompt ("Enter Password or Place finger…"); typing
|
||||
the password immediately works, touching the sensor instead works,
|
||||
wrong-finger ×3 falls back to password, and password keeps working
|
||||
with fprintd stopped (`systemctl stop fprintd`). Also check
|
||||
hyprlock and the greeter accept both factors and don't wedge on a
|
||||
leftover prompt after a fingerprint win (known cosmetic quirk of
|
||||
the hack — pthread_cancel'd prompt). `fingerprint.parallel = false`
|
||||
must restore the old sequential behavior. VM already asserts the
|
||||
PAM stack shape + password-only lockout safety with no reader
|
||||
(checks.hardware-toggles).
|
||||
- [ ] **#55 fingerprint enroll on real reader** — with
|
||||
`nomarchy.hardware.fingerprint.enable` and a physical reader: System ›
|
||||
Fingerprint › Enroll a finger; List shows it; Verify succeeds; optional
|
||||
|
||||
@@ -19,6 +19,29 @@ Template:
|
||||
|
||||
---
|
||||
|
||||
## 2026-07-12 — parallel fingerprint-or-password (interactive, promoted)
|
||||
- **Task:** Bernardo promoted the PROPOSED "fingerprint or password in
|
||||
parallel" item live; wants it default-on for fingerprint-PAM users.
|
||||
- **Did:** Packaged pam-fprint-grosshack v0.3.0 (pkgs/, source-reviewed
|
||||
first: all failure paths → PAM_AUTHINFO_UNAVAIL, typed password only
|
||||
ferried via AUTHTOK to pam_unix try_first_pass — can't lock out
|
||||
password login). New `nomarchy.hardware.fingerprint.parallel`
|
||||
(default true; false = stock sequential). Wiring swaps stock fprintd's
|
||||
rule modulePath (mkForce) so ordering is inherited. README/template
|
||||
rows; BACKLOG PROPOSED entry closed into ROADMAP ✓.
|
||||
- **Verified:** V2 — checks.hardware-toggles extended to three nodes and
|
||||
green: parallel node asserts grosshack line before pam_unix in
|
||||
/etc/pam.d/sudo AND `sudo -S` with the right password succeeds /
|
||||
wrong password fails with NO reader present (the lockout invariant);
|
||||
seqpam node = stock pam_fprintd, no grosshack; nopam = neither.
|
||||
Package builds (meson needed libpam-wrapper + python3). flake check
|
||||
green.
|
||||
- **Pending:** V3 on the AMD dev box (HARDWARE-QUEUE): the actual
|
||||
type-or-touch race, fprintd-stopped fallback, hyprlock/greeter
|
||||
behavior after a fingerprint win (pthread_cancel'd prompt quirk).
|
||||
- **Next suggestion:** dock + fingerprint V3 batch on hardware, then
|
||||
#89 slice 3.
|
||||
|
||||
## 2026-07-12 — undock blackout rescue (interactive follow-up)
|
||||
- **Task:** Bernardo: "if I turn the laptop screen off and undock, does
|
||||
the panel come back?" Answer had to be tested, not recalled.
|
||||
|
||||
Reference in New Issue
Block a user