deps: relax cbor2 upper bound to permit >=5.9.0#832
Conversation
The <5.8 cap from bitcoin-core#817 traps downstreams at cbor2 versions vulnerable to GHSA-3c37-wwvx-h642 (high-severity DoS in cbor2.loads), first patched in 5.9.0. Empirical testing on real Jade hardware shows stock HWI 3.2.0 + cbor2 5.9.0 completes signing successfully. Whatever broke in 5.8.0 is fixed in 5.9.0 itself. Test matrix and logs at https://github.com/al-munazzim/hwi-jade-cbor-repro Excludes 5.8.0 explicitly (still freezes Jade on pyserial transports per the test matrix). poetry.lock not regenerated in this commit; maintainers may prefer to handle that separately or defer until next release.
From that commit:
So this would be hard to miss. |
• Dist builder ✅ https://github.com/bitcoin-core/HWI/actions/runs/25211462096/job/73922819687 Also, regarding the earlier timeout context: Jade jobs are not timing out in this run (they are green), e.g. • Jade library ✅ https://github.com/bitcoin-core/HWI/actions/runs/25211462096/job/73923444972
• Trezor sim builder fails on master with error[E0658]: custom test frameworks are an unstable feature So the lockfile issue is fixed in this PR, the remaining failures look like pre-existing CI/environment issues. |
|
Any feedback, @Sjors ?! |
Brings: Trezor Safe 5 support, Ledger Nano model IDs, tr() single-leaf
descriptor parsing fix, Debian Buster Linux build compat.
requires-python lifted from >=3.7,<4.0 to >=3.9,<3.13 — HWI 3.x drops
3.7/3.8 (and caps at <3.13). Drops support for those Python versions.
API impact on Specter (verified): all hwilib symbols Specter imports
(hwwclient, errors, key, psbt, _script, descriptor, common,
bitbox02_lib.util, trezorlib.{transport,messages,protobuf}) are
unchanged 2.4 -> 3.1. enumerate() gained allow_emulators=False kwarg
(default ignores emulators). Specter's own simulator paths in vendored
jade/keepkey/specter_diy clients are unaffected; the only behavioral
change is Trezor emulator no longer auto-discovered through Specter
(no callers observed in tests/).
cbor2 stays at 5.9.0 — HWI 3.1's cap is <6.0.0, no conflict. (HWI 3.2
introduces a <5.8 cap that conflicts with the GHSA-3c37-wwvx-h642 fix
floor; relax PR filed upstream as bitcoin-core/HWI#832, prerequisite
for a later 3.2/3.3 bump.)
Note: only mechanical add'n to requirements.txt is the new pip-tools 7
boilerplate text; cbor2 and all other transitive deps unchanged.
Refs:
- cryptoadvance#2597 (BitBox02
Nova; deferred to 3.2/3.3 bump after upstream cap relax merges)
- bitcoin-core/HWI#832
2 participants
Summary
Relax the
cbor2constraint from>=5.4.6,<5.8to>=5.4.6,!=5.8.0,<6.0.0, allowing downstreams to install HWI together withcbor2>=5.9.0.Motivation
The current
<5.8cap was introduced in 38fae57 ("Constrain cbor2 to <5.8") in response to #817 —cbor2==5.8.0changes the decoder's stream-read pattern fromread(n=1)toread(n=4096), which causes Jade signing to hang on pyserial-style transports.That fix made sense at the time, but it traps downstream users at a vulnerable version of cbor2:
cbor2.loads. Affects allcbor2 < 5.9.0.cbor2 >= 5.8.0.The high-severity advisory is unfixable under the current cap. Downstream projects that pin
cbor2>=5.9.0for security cannot install HWI 3.2.0 without overriding the resolver.Evidence
I built a hardware-in-the-loop matrix that exercises the full Jade signing path (
enumerate→getmasterxpub→signtx) under HWI 3.2.0 against cbor2 versions 5.7.1, 5.8.0, and 5.9.0, with and without a candidate read-loop patch.Test repo (with raw logs and reproduction instructions): https://github.com/al-munazzim/hwi-jade-cbor-repro
Tested on macOS 15.4.1, Python 3.9.23, HWI 3.2.0, against an unlocked Jade signer. The key cell: stock HWI 3.2.0 + cbor2 5.9.0 completes Jade signing successfully without any code change in HWI. Whatever changed in cbor2 5.8.0 to break the read pattern appears resolved in 5.9.0 itself.
Scope
This PR is intentionally minimal: cap relax only.
The
JadeInterface.read()loop is still fragile — a future cbor2 change could in principle re-trigger the freeze. Hardening that path is a separate concern and a candidate follow-up PR (the patch from the test repo above can be the basis).cbor2 == 5.8.0is excluded explicitly (!= 5.8.0) since the FROZEN result there is reproducible and confirmed on real hardware.Changes
pyproject.toml:cbor2 = ">=5.4.6,<5.8"→cbor2 = ">=5.4.6,!=5.8.0,<6.0.0"setup.py: same constraint (kept in sync with pyproject)poetry.locknot regenerated in this PR. Happy to add a follow-up commit regenerating it if that is the convention; otherwise it can be regenerated at next release.Refs
cbor2 >= 5.9.0