[Japabu]

Problem

The owner asked (2026-10-22) for the tree's own crypto wherever possible. The build's HTTPS client and doom's build script ran rustls on ring:

• the build's client, release::agent, makes every GitHub and crates.io request;
• doom's build script fetches doomgeneric's archive.

Change

• Both clients take toyos-crypto's rustls provider through ureq's rustls-no-provider, keeping webpki's roots.
• The provider takes its entropy from its caller. Each client gives it the host's, through getrandom.
• ring leaves both normal graphs. cargo tree -i ring over the normal and build edges finds nothing under toyos-build or under doom's build-dependencies, where main shows ring → rustls → ureq for each. It stays a dev-dependency oracle, and ToyOSOrg/ring stays for guest programs that choose it.
• Records. the-build-runs-host-tools-outside-rust-and-qemu.md's cc row now names ring only as the dev oracle. The crypto issue's stage 5 now says the host's two clients have moved.
• Key exchange is X25519 and X25519MLKEM768 only. Each client drops the provider's P-256 and P-384 groups, so no P-256 or P-384 secret meets a server's input while the T14 measures those curves leaking. A server offering only NIST groups would be refused. That is recorded as a weakness, with its exit: the finding resolved.

Checks

• cargo run -- --ci host at c195cf5, the stack's head: exit 0, 93 steps green.
• ring-trees.txt (review r1): https://github.com/ToyOSOrg/evidence/tree/804f1b7daa3d27851658b5ae3f09552220cd64db/pr-1020/r1
• A live run with this provider and group policy, from a scratch program at ureq 3.4.2 (the lock's version), returned 200 with a whole body from each of:
  • api.github.com;
  • index.crates.io;
  • a GitHub archive, followed through its redirect;
  • static.crates.io.
• cargo run -- --build-only with apps/doom/doomgeneric removed: exit 0. doom's build script printed Downloading doomgeneric fc6016394… and unpacked the archive, all through the new provider.

Evidence: https://github.com/ToyOSOrg/evidence/tree/59fd5708eee49b17c7abf1e231b5471e55bbc5d0/pr-1020

Risks

• The provider's server interoperability rests on the crate's own rustls tests and on the four hosts above. A host the build later adds that offers no X25519 group would fail its handshake, with an error naming it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PXEk8BBMDT8tXu4AnENB9Q

[Japabu]

Review, round 1: #1020 at 94b58ef (code 0ff4b28), stacked on #1019

Architecture

The host's two HTTPS clients take the crate's existing provider through ureq's rustls-no-provider and keep webpki's roots. Certificate parsing, chain building and name checking stay in rustls-webpki. The crate supplies the signature algorithms (verify.rs: ECDSA P-256/P-384, Ed25519, RSA PKCS#1/PSS), which are public-key operations only. Key exchange is filtered to X25519 and X25519MLKEM768 before the provider reaches rustls, so no P-256 or P-384 secret meets server input. That meets the constraint until #1013's constant-time acceptance. No signing key is loaded (VerifyOnly). No automated test performs a live fetch: the live checks are a scratch program in evidence, and doom's download runs only when doomgeneric is absent, as before. Doom remains buildable on every host, because the provider supports hosted x86-64 and AArch64 on Linux, macOS and Windows.

Net change: +72/−12, of which about 20 lines (SystemRandom, the static Backend, the group filter) are duplicated between build/release.rs and apps/doom/build.rs.

Required

1. issues/the-build-runs-host-tools-outside-rust-and-qemu.md:23 is now false. The cc row still says cc compiles ring "in every build of the build system itself, whose HTTP agent is rustls on ring (build/release.rs), and in every build of doom's build script, whose download of doomgeneric is ureq on rustls on ring". Its justification cites "ring is the one TLS provider the tree takes". Stage 5 of the crypto issue names exactly this edit as part of the switch: "The cc row … stops naming ring for the build system's HTTP agent." Also update the crypto issue's stage-5 bullet (issues/toyos-crypto-is-in-the-tree-on-par-with-ring-and-secure.md:475-479, "Until then ring stays the provider"), which is stale for the host clients.

2. Evidence gap: "ring leaves both normal graphs (cargo tree -e normal and -e build find none)" has no output in pr-1020/. The lockfile cannot show it: rustls and rustls-webpki still list ring because other members enable it. This is the claim that justifies the host-tools change above. The cheapest sufficient check is to record:

   • cargo tree -p toyos-build -e normal,build -i ring;
   • doom's build-dependency tree, -e build -i ring for the guest target.

Suggestions

• Where the NIST-group policy lives. The X25519-only filter is the crate's own constant-time constraint, but each consumer re-implements it (build/release.rs:145, apps/doom/build.rs:174), and the issue makes every client "keep the two groups itself". The crate could own it: Backend::provider() would omit secp256r1/secp384r1 until the finding resolves. The two clients would then lose their copies, the guest clients of stage 5 would inherit the policy, and the exit would be a one-place change. The crate's interop tests for the NIST groups would need their groups from the kx module directly, so weigh that against the duplication. The orchestrator's call.
• The weakness's exit (issues/toyos-crypto-is-in-the-tree-on-par-with-ring-and-secure.md:530-534, "the T14 finding is resolved"): name the finding's location in the issue (the stage-4 constant-time verdict) or crypto: P-256 base-point comb, odd representatives off the identity, faster P-256 field (parity item 8b) #1013, so the exit is unambiguous.

Evidence

• ci-host.rev = 0ff4b28. Exit 0. 94b58ef only edits the issue.
• The tlscheck scratch program reproduces release::agent's provider, filter and ureq version, and fetches 200s from all four hosts. Doom's build-script output shows the download ran under --build-only at this head.
• The provider's handshake and RSA interop against ring, its hybrid exchange and its entropy-failure tests were established in earlier stages and are unchanged here.

SEND BACK: items 1 and 2.

[Japabu]

Response to review r1. The head is c195cf5, rebased onto #1019.

1. Stale records: fixed.
   • the-build-runs-host-tools-outside-rust-and-qemu.md's cc row names ring only as the dev-dependency oracle of toyos-crypto and toyos-update.
   • The crypto issue's stage-5 bullet says the host's two clients have moved (build, doom: the host's HTTPS on toyos-crypto's rustls provider #1020), on X25519 groups while the T14 finding stands. The cc-row item is marked done.
2. Evidence: ring-trees.txt, via cargo tree -i ring over the normal and build edges.
   • At build, doom: the host's HTTPS on toyos-crypto's rustls provider #1020: nothing under toyos-build, and nothing under doom's build-dependencies. The doom query uses --target all, because the host's rustc has no x86_64-unknown-toyos specification for cargo.
   • At main 18a3873: ring → rustls → ureq for each.
   • Positive control: the same query finds ring under toyos-crypto's dev edge.

Suggestions:

• The weakness's exit now names stage 4's T14 finding.
• I didn't take moving the group policy into the crate. That's the orchestrator's call, and it would also change the provider's NIST-group interop tests.

Evidence: https://github.com/ToyOSOrg/evidence/tree/804f1b7daa3d27851658b5ae3f09552220cd64db/pr-1020/r1

cargo run -- --ci host at c195cf5: exit 0, 93 steps.

[Japabu]

Review, round 2: #1020 at c195cf5 (rebased onto #1019's 9825b99)

Both of round 1's required items are resolved.

1. Records:
   • The cc row of issues/the-build-runs-host-tools-outside-rust-and-qemu.md:23 now names ring only as the dev-dependency oracle of toyos-crypto and toyos-update. That matches update: the image signature on toyos-crypto's Ed25519; ed25519-dalek is an oracle #1019's dev-dependency on ring. Its justification no longer cites ring as the tree's TLS provider.
   • The crypto issue's stage-5 bullet (…-secure.md:477-488) records that the two host clients moved, on X25519 groups, and marks the cc-row item done.
2. Evidence: pr-1020/r1/ring-trees.txt shows cargo tree -i ring over the normal and build edges:
   • At this head it finds nothing for toyos-build or for doom.
   • At main 18a3873 it finds ring → rustls → ureq for each, the before case.
   • Its positive control finds ring under toyos-crypto's dev edge, so the query does find a real path.
   • Doom's --target all stands in for the guest target, which the host's cargo cannot name. It is a superset, so "nothing" holds.

The weakness's exit now names stage 4's T14 finding precisely. Moving the group policy into the crate was declined and left to the orchestrator, which is fine for an optional suggestion.

ci-host.rev is c195cf5, exit 0.

LAND