All checks were successful
package / package (push) Successful in 1m22s
0.2.3's manifest pinned the sha256 of one Android build's focal64 (16.82.0, the build the dev phone runs). Fairphone re-signs the trustlet every release, so that pin matched exactly one of the six builds seen, and two of two field reports had no sensor: one user on 16.100.0 edited the manifest by hand, another ended up with a file QTEE refuses. The manifest now carries '-' instead of a hash and depends on fp6-vendor-blobs 1-r3, which tries the active slot first and verifies the image's structure; QTEE's signature check is the gate it always was (one flipped byte -> ERROR_ELF_SIGNATURE_ERROR, measured 2026-09-03 and again today). post-install reassembles the trustlet right away, so 'apk add' no longer needs a boot for it. post-upgrade re-derives it from the active slot, which replaces a hand-placed or wrongly pinned file, and then restarts the daemon -- a plain restart, so a daemon that exited on a refused trustlet comes back up on the re-derived one. loadFromBuffer failures name the loader's verdict. The field's first report was a bare result=12; it now reads ERROR_ELF_SIGNATURE_ERROR with what to do about it. Probed on the phone with this build: a one-byte tampered image and 100000 random bytes both print it, the pristine image loads, and the suites pass 8/8.
21 lines
1.1 KiB
Shell
Executable file
21 lines
1.1 KiB
Shell
Executable file
#!/bin/sh
|
|
# SPDX-License-Identifier: GPL-3.0-only
|
|
# SPDX-FileCopyrightText: Copyright (C) 2026 Catcrafts®
|
|
#
|
|
# Two things an upgrade must do on a running phone. First re-derive the
|
|
# trustlet from the active slot: 0.2.3 pinned one Android build's hash, so a
|
|
# phone on any other build has no trustlet, or a hand-placed one, and
|
|
# --refresh replaces it with the phone's own (fp6 journal, fingerprint lane,
|
|
# 2026-09-11). --if-device keeps this a no-op inside build/CI chroots.
|
|
/usr/lib/fp6-vendor-blobs/extract --if-device --refresh || :
|
|
#
|
|
# Then restart the daemon: apk replaces /usr/bin/fingerprintd on disk and
|
|
# leaves the running one alone, so the phone would keep matching with the OLD
|
|
# code until a reboot (how 0.2.2's FingerMatched signal first presented,
|
|
# 2026-09-05). A plain restart rather than try-restart: a daemon that exited
|
|
# on a refused trustlet is not running and must come up on the re-derived
|
|
# file, and the unit's ConditionPathExists lines keep this inert on a phone
|
|
# with no trustlet or no /dev/tee0. No systemd inside a chroot.
|
|
[ -d /run/systemd/system ] || exit 0
|
|
systemctl restart fingerprintd.service 2>/dev/null || :
|
|
exit 0
|