vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

hive-forge: pin forgejo-api to 0.11.1 so it shares the workspace reqwest

Browse source 
forgejo-api 0.11.0 links reqwest 0.12 while the workspace is on 0.13, and
cargo unifies features per (crate, VERSION) — not per crate. So forgejo-api's
internal client was a *second* reqwest, built with neither the workspace's TLS
features nor the system trust store, and every https call it made to a gateway
name failed `invalid peer certificate: UnknownIssuer` while a client built in
this workspace succeeded against the same host.

Pinning to 0.11.1 puts one reqwest in the tree, which is what makes the
existing "feature unification gives forgejo-api our TLS backend" comment true
rather than aspirational — the claim is a fact about the lockfile, so the pin
is load-bearing and says so.

The reqwest feature list moves with it: `rustls-native-certs` and
`webpki-roots` were 0.13.1-era names that no longer exist, and `rustls` now
carries the platform verifier (OS trust store, honours SSL_CERT_FILE). Naming
a feature that is gone is a hard resolution error rather than a silent no-op,
so the list had to change in the same commit as the pin.

Refs #3391
This commit is contained in:
atlas 2026-08-19 12:30:50 +02:00
commit 74dfd366b4
3 changed files with 45 additions and 83 deletions
Download patch file Download diff file Expand all files Collapse all files

30
hive-forge/Cargo.toml
View file

@ -11,28 +11,28 @@ path = "src/main.rs"
[dependencies]
anyhow = { workspace = true }
clap = { workspace = true }
# `sync` = blocking client (hive-forge is a blocking CLI). TLS backend
# comes from workspace feature unification on reqwest: the
# `rustls-tls-native-roots` feature below applies to forgejo-api's
# internal client too (same compiled reqwest), so the hive-CA trust
# note keeps holding.
# `sync` = blocking client (hive-forge is a blocking CLI). TLS backend comes
# from feature unification on reqwest — which only works because forgejo-api
# and this crate now resolve to the SAME reqwest version; cargo unifies
# features per (crate, version), so the claim is a fact about the lockfile,
# not about the workspace. See the pin note on `forgejo-api` in the root
# `Cargo.toml`.
forgejo-api = { workspace = true, features = ["sync"] }
url.workspace = true
time.workspace = true
reqwest = { workspace = true, features = [
"json",
# Trust the OS/system CA store (`rustls-native-certs`), plus the bundled
# Mozilla roots (`webpki-roots`), so hive-forge validates the hive
# `rustls` carries the platform verifier, which reads the OS trust store
# (and honours `SSL_CERT_FILE`), so hive-forge validates the hive
# gateway's self-signed leaf once the hive CA is in the agent's trust
# store (embedded into agent flakes via security.pki.certificateFiles)
# AND public CAs still validate. Cargo unifies features across the build,
# so both root sources are enabled for every reqwest client; harmless (a
# superset of roots, and on NixOS the system store already includes the
# Mozilla bundle). (reqwest 0.13 renamed the 0.12 `rustls-tls` /
# `rustls-tls-native-roots` features to `rustls` / `rustls-native-certs`.)
# store — embedded into agent flakes via `security.pki.certificateFiles`
# — while public CAs still validate.
#
# The separate `rustls-native-certs` / `webpki-roots` features this entry
# used to name were 0.13.1-era and no longer exist; naming a feature that
# is gone is a hard resolution error, not a silent no-op, so this list has
# to move with the pin.
"rustls",
"rustls-native-certs",
"webpki-roots",
"blocking",
"multipart",
] }