deps: relax cbor2 upper bound to permit >=5.9.0#832
deps: relax cbor2 upper bound to permit >=5.9.0#832k9ert wants to merge 2 commits intobitcoin-core:masterfrom
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. |
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