Skip to content

Planning and executing the v1.10.5 Security Hardening Release #407

Description

@schnuartz-ai

Context

This issue coordinates the Specter DIY Security Hardening Release v1.10.5.

The previous published GitHub release is v1.10.3. A v1.10.4 tag already exists
as a test/update version, so that number is skipped for the public release.

Status: release built, signed and hardware-tested by a second maintainer.
Publication pending (tag + sha256.signed.txt + release page).
See
Release build results below.

Release scope decisions

  • No release-signing key rotation. Production signer/key set and threshold
    unchanged (verified — see below).
  • No signing-key / bootloader-key changes. Bootloader submodule is identical
    to v1.10.3 (b97192322c32f3fc54a93c2049b800e9c21f27c0).
  • Ship the review-ready security-hardening / transaction-verification / entropy
    fixes; defer everything still in review to the next release. Fast release was
    prioritised over pulling in more surface.
  • Full-card SD-card secure erase/format feature and related SD-card management
    UI are not in this release.

PR merge / review tracker

Merged into the v1.10.5 release (commit b2d87e5)

Not in v1.10.5 — deferred to the next release (still open)

Explicitly out of scope (SD-card management / full-format — later release)

Companion-version note for the release changelog: none of the deferred PRs are
required for v1.10.5 to function; no minimum companion versions apply.

Review and merge gates

Version freeze and release build

  • Release commit frozen: b2d87e55338289a258ee985b26c7b064d5b49132
  • Firmware version bumped to v1.10.5 (<version:tag10>0101000599</version:tag10>)
  • Create the v1.10.5 tag from b2d87e5
  • Confirmed no signing-key changes vs the current production key set
  • Built from the frozen commit via the reproducible-build flow (pinned diy Docker image, linux/amd64, SPECTER_REPRODUCIBLE_BUILD=1, production pubkeys, bootloader READ_PROTECTION=1 WRITE_PROTECTION=1)
  • Two maintainers independently reproduce the build and compare message/hash — reference build reproduced bit-identical; Marco Kruse reproduced the build independently and the signature/message/hash match
  • Vendor signatures added with the existing production keys and threshold (k9ert + Mike)
  • Bootloader introspection run on the final specter_upgrade.bin (upgrade-generator.py dump); bootloader on-device also checked with STM32CubeProgrammer (Marco Kruse) — matches previous firmwares
  • Signature threshold and signer identities verified — 2 / 2, k9ert c8638d869d056ce1b18677e2b0bfaa60 + Mike cf0239e7708148c0fe2bc1ff485d950e, both cryptographically valid over the signing message
  • Embedded production keys verified: k9ert, Mike, Stepan, Backup m/99h; main_fw_sig_threshold = 2, bootloader_sig_threshold = 2
  • Versions verified: firmware 1.10.5; bootloader unchanged since v1.10.3. Upgrade is firmware-only (no boot section — message has no b… prefix, unlike v1.10.3)
  • SHA-256 generated for all binary artifacts (see below)

Final release verification

Release build results

Item Value
Release commit b2d87e55338289a258ee985b26c7b064d5b49132
bootloader submodule b97192322c32f3fc54a93c2049b800e9c21f27c0 (= v1.10.3)
f469-disco submodule 9dd8515aaa0de80cf5d2ae1499de14beb33f863a
Build env Docker diy (python:3.9.15, ARM GCC 9-2020-q2), linux/amd64
Upgrade type firmware only, no bootloader section
Signing message 1.10.5-1fychyfccs5a0l4xhgskqutqzmkpfga7fd49waatccalglpecxr5qkm92z0
Signatures k9ert c8638d86…aa60, Mike cf0239e7…d950e — 2 / 2 threshold met

SHA-256 of the release assets:

fcd23591cd990cc7973861916e5d398ddd8f3f4dea226035d236ffe0e30bb0ea  specter_upgrade_v1.10.5.bin
d207f6d3750e3aacbc98080581934b8d0ebe52eb833f341e0e249d96c0c711d6  specter_upgrade_unsigned_v1.10.5.bin
b46b6b3ea256bc9f9d4da4250c0d6ffdfc1800cbb44a8845810e045c5e8cae01  initial_firmware_v1.10.5.bin

Component hashes (cross-check): bin/specter-diy.hex
b40f676ffce5dde9d1d108164b2c6f669a233eb89a775375d7d89aea71a503b9 ·
bootloader.hex 0869e02baa58c6f8c63ad0e570fbf1283d8aaacec3956bf0fc94fea65ab9caeb ·
startup.hex 14dc7181e98999230c63b40b7613d08d671e783da98381870246141d25db8f49

Remaining before publish

  1. Final changelog review.
  2. gpg --digest-algo SHA512 --clearsign -o sha256.signed.txt sha256.txt with the release-signing GPG key.
  3. git tag v1.10.5 b2d87e55338289a258ee985b26c7b064d5b49132 && git push origin v1.10.5.
  4. Create the GitHub release on the tag, upload specter_upgrade_v1.10.5.bin, specter_upgrade_unsigned_v1.10.5.bin, initial_firmware_v1.10.5.bin, sha256.signed.txt, paste the changelog, publish.

Done: reference + independent (Marco Kruse) reproduction match; final signed
binary tested on device — SD-card upgrade from v1.10.3 and clean-board initial
flash, with #387 / #382 / #376 / #335 test vectors re-verified; bootloader
inspected with STM32CubeProgrammer.

Release-workflow note (PR #414)

PR #414's assemble step currently builds specter_upgrade.bin with the
bootloader section (b1.0.2), which produces a different signing message. The
v1.10.5 signatures target the main-firmware-only upgrade, which is what the
published specter_upgrade.bin contains. #414 must be reconciled with the
firmware-only upgrade flow before it is used to drive a release; the initial
firmware still bundles the production bootloader as before.

Notes

This release is deliberately security hardening, not feature expansion. The
wipe/PIN/constant-time PRs (#380, #388, #396) and the fee-warning / Taproot PRs
(#392, #399, #405) were not review-complete at freeze time and move to the next
release.

Activity

  1. Schnuartz commented on Sep 1, 2026

    @Schnuartz
    Contributor

    So we currently need approvals for this three PRs:
    #392 ✅
    #387 ✅
    #396 ✅

    This one would be good, so that the new update would be reproducable build:
    #412

    Maybe this three small ones as well, if there is time, but fast release is more important:
    #399
    #405
    #403

    This one is nice to have, but I would not put it into the release yet, as we should have Specter Desktop Release first. Will test there, currently did not do Hardware Wallet tests yet
    #381

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions