Skip to content

Ohttp msrv bump 1.85.0 - #9

Draft
benalleng wants to merge 5 commits into
payjoin:mainfrom
benalleng:ohttp-msrv-bump-1.85.0
Draft

Ohttp msrv bump 1.85.0#9
benalleng wants to merge 5 commits into
payjoin:mainfrom
benalleng:ohttp-msrv-bump-1.85.0

Conversation

@benalleng

Copy link
Copy Markdown
Collaborator

This updates the msrv to 1.85.0 and also uses more up-to-date cargo toml features to better handle msrv pinning within the repo.

Closes #6

Blocked by #8

DanGould and others added 5 commits September 7, 2026 19:59
Run the rust-hpke backend on stable Rust and nothing else, so a red board
means a real regression.

The nss legs could never pass: NSS has no secp256k1 DHKEM, and the backend
has not compiled since the Kem enum was pruned to K256Sha256 in bac8f2c.
Whether to delete the backend is a separate decision; until then it stays out
of the matrix. The 1.63.0 legs die during dependency resolution, before any
code in this repository is compiled, because that cargo cannot parse modern
dependency manifests; the MSRV leg returns once payjoin#6 settles what the MSRV is.

The NSS build prerequisites and clone steps go with the legs that used them,
as does the llvm-tools-preview component nothing here consumes.
`PrivateKey`'s Debug impl still bound `b` from `key_data()` after the body was
changed to print "[REDACTED]", leaving it unused. With `#![deny(warnings)]`
that is a hard error on current rustc, so the crate does not build on the CI
matrix's `stable` leg. `PublicKey`'s Debug still uses `b` and is unchanged.
The AES-GCM symmetric suites were advertised but could never be used.
bitcoin-hpke removed its AES-GCM schemes in 0.13.0, and `dispatch_hpkes_new!`
only ever mapped ChaCha20Poly1305, so a peer that honoured the advertisement
and selected AES-GCM got `Err(InvalidKeyType)`. `Config::supported()` returned
true for it anyway, and the test constants listed it first, which is why 11 of
this crate's own tests failed. Correcting `supported()` makes
`strip_unsupported` prune the advertised KeyConfig automatically. The `Aead`
enum keeps its GCM variants so other peers' configs still parse.

`decode` built its probe config with `Aes128Gcm` on the grounds that "the KDF
and AEAD doesn't matter here"; it does now, since the probe is checked against
`supported()`, so it uses ChaCha20Poly1305.

`decode` also rejects a config whose suite list is empty after pruning, with
`Error::Unsupported`. Without that, a client handed a GCM-only config reached
`ClientRequest::from_config`, which selects `symmetric[0]`, and panicked on the
empty list where `main` returned `InvalidKeyType`. `decode_list` already skips
`Unsupported` entries, so a list containing such a config decodes to the usable
remainder. A test covers both paths. The example server no longer requests
AES-128-GCM, which it would only have had stripped.

Two tests were stale from before the secp256k1 port and never passed:
`derive_key_pair`'s expected config encoded a 32-byte X25519 key under KEM
0x0020, regenerated here for KEM 0x0016 with a 65-byte key; and
`truncate_kdf_aead_list` hard-coded an offset that assumed the X25519 key size,
so it now derives the offset from the encoding.

Also fixes two lints current clippy rejects under this crate's
`deny(warnings, clippy::pedantic)`: a redundant `continue` and non-inlined
format args.
By updating the editions to 2024 it allows us to utilize the more
up-to-date cargo resolver features to keep msrv in check within the toml
configuration itself.

This change does mandate that we update the msrv to at least 1.84.0 but
with rust-payjoin and the main payjoin crate already being at 1.85.0 it
seems appropriate to do the same here.
@benalleng
benalleng force-pushed the ohttp-msrv-bump-1.85.0 branch from 7902c81 to 84a89d6 Compare September 10, 2026 15:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The MSRV 1.85 CI check cannot resolve: transitive icu_* now require rustc 1.88

3 participants