An unchanged ureq and rustls client on a ring fork fetches byte-exact over TLS 1.3 in a guest, trusting the Mozilla roots every image carries with their licence's text

Cargo.toml

@@ -218,6 +218,10 @@ ureq = { version = "3", default-features = false, features = ["rustls"] }
 # The commit an image is built from, its time and whether the tree is that
 # commit's, where `git` is a host's C tool (`src/build.rs`'s `release`).
 gix = { version = "0.88", default-features = false, features = ["status", "sha1"] }
+# The authorities `build::trust_roots` writes to ROOT, as the rustls project
+# publishes the Mozilla root program, and the PEM it writes them in.
+webpki-root-certs = "1"
+pem = "4"
 
 [dev-dependencies]
 # `USER_TOP`, so the harness judges a held `rsp` against the bound the kernel
@@ -232,6 +236,10 @@ toyos-xhci = { path = "toyos-xhci" }
 # The ACPI server's count line, so the judge reads the words the server writes
 # and the job that waits for them matches.
 acpiserver-api = { path = "userland/acpiserver-api" }
+# `common::https`'s server, the peer a guest's HTTPS client is judged
+# against, and the authority and certificates it presents, made per run.
+rustls = { version = "0.23", default-features = false, features = ["ring", "std", "tls12"] }
+rcgen = "0.14"
 
 [patch.crates-io]
 loom = { git = "https://github.com/ToyOSOrg/loom", branch = "toyos" }
@@ -254,6 +262,7 @@ raw-window-handle = { git = "https://github.com/ToyOSOrg/raw-window-handle", bra
 cpal = { git = "https://github.com/ToyOSOrg/cpal", branch = "toyos-0.18.0" }
 softbuffer = { git = "https://github.com/ToyOSOrg/softbuffer", branch = "toyos-0.4.8" }
 winit = { git = "https://github.com/ToyOSOrg/winit", branch = "toyos-0.30.13" }
+ring = { git = "https://github.com/ToyOSOrg/ring", branch = "toyos-0.17.14" }
 
 # The one profile every guest binary is built with.
 # Optimised, because an unoptimised guest mismeasures everything under TCG;

NOTICE

@@ -244,6 +244,20 @@ rust-lang/llvm-project, Apache-2.0 WITH LLVM-exception like upstream's; the
 toolchain release carries the clang, `lld` and LLVM tools built from it.
 
 
+licenses/CDLA-Permissive-2.0-webpki-root-certs.txt — the Mozilla roots, CDLA-Permissive-2.0
+-------------------------------------------------------------------------------------------
+
+Every image carries the authorities of Mozilla's root program as the
+`webpki-root-certs` crate publishes them, a derived work of the CCADB's data,
+written by `src/build.rs`'s `trust_roots`. That crate is under
+CDLA-Permissive-2.0, which the owner allowed for these roots: it asks that the
+agreement's text travel with the data, and the image carries it beside them as
+/system/etc/ssl/CDLA-Permissive-2.0.txt.
+
+    Licence text: licenses/CDLA-Permissive-2.0-webpki-root-certs.txt (the
+    crate's `LICENSE`, sha256
+    e271993808fec50ab29350b39539cdec611a9103f827e0aa26d61da70e2d33f8)
+
 bcachefs/tests/fixtures/ — volumes upstream's tools wrote
 ---------------------------------------------------------
 

issues/a-guest-close-after-a-refused-handshake-can-leave-its-peer-waiting.md

@@ -0,0 +1,42 @@
+---
+status: open
+kind: defect
+opened: 2026-10-09
+---
+
+# A guest's close after a refused handshake can leave its peer waiting
+
+`https_fetch` (`tests/toyos.rs`) runs `https_get` three times on one boot of
+`tests/netcase`, each a new process and one TCP connection through
+`/system/bin/netstack` to a `rustls` server on the host. The second and third
+runs refuse the server's certificate during the handshake, print their
+refusal, drop the connection and exit 2. On smoltcp, the stack `netstack` ran
+before ToyOS's own replaced it, the server's read of the handshake's next
+record was answered by nothing: in one boot its peer's end of stream arrived
+and in the other it did not, 180 seconds after the process exited, no FIN and
+no reset. netstack logged nothing about either connection.
+
+The same client and server both on the host (macOS) see each refused
+connection end at once with an end of stream and no alert: the client sends
+no alert, so the close is all the peer is owed, and it is what was missing.
+
+Measured at `a944746d5` plus the branch that added `https_fetch`, under QEMU
+with slirp, once (logs on that branch's pull request): the
+second connection of the boot never ended at the peer; the third did, by the
+end of the 180 seconds. Two earlier boots of the same test reported the
+second connection silent after 30 seconds. Not reduced, and no capture was
+taken of the guest's side, so slirp losing the guest's FIN was not ruled out.
+
+On ToyOS's own stack, measured at that branch's merge of `main` after #801
+by a probe patch on `https_fetch` that waits up to 150 seconds for each
+refused connection's end (patch and logs on that branch's pull request): in
+two boots, all four refused connections had already ended at the peer when
+the harness looked, after the third run exited. Two boots are no rate, and
+`https_fetch` still asserts nothing of these ends.
+
+**Exit condition**: a guest test whose process closes a connection mid-
+handshake, with the peer's flight unread, and exits, sees the host's peer
+read the end of the stream within a stated bound, on each of several
+connections in one boot.
+
+**Owner**: whoever holds `issues/toyos-has-its-own-network-stack.md`.

issues/a-netcase-boot-under-host-load-said-nothing-past-the-firmwares-screen-clears.md

@@ -0,0 +1,37 @@
+---
+status: open
+kind: defect
+opened: 2026-10-09
+---
+
+# A netcase boot under host load said nothing past the firmware's screen clears
+
+One whole `cargo test` on the development Mac, at the head of the branch that
+added `https_fetch`, went red on `netstack_socket_churn` alone: `[qemu] Boot
+timed out waiting for ===READY===; the console carried: nothing at all`, after
+487 s. The boot's 16550 file holds 58 bytes, the firmware's
+screen-clearing escapes (`ESC[2J ESC[01;01H ESC[=3h`, three times) and
+nothing after them: no loader line. The same image booted green in the same
+run for `https_fetch` and `libc_sockets`, and `netstack_socket_churn` alone a
+minute later was green in 12 s.
+
+The host's load averages as the suite began were 82.78, 94.69 and 92.31 on
+14 cores, other worktrees' suites among them, and 36.29, 47.59 and 67.23 as
+it ended; 37.01, 45.47 and 64.77 for the green run alone. The harness had
+priced its liveness ceilings at 1.00x.
+
+A second, at `216f33b35` on the same branch: `cargo test --test toyos-build
+-- https_fetch` alone, beside this tree's own `cargo run -- --ci host` and
+other worktrees' work, went red the same way after 64 s, its 16550 file the
+same 58 bytes. Load averages 89.36, 87.83 and 82.56 as it began and 98.94,
+91.36 and 84.48 as it ended.
+
+Not reduced: whether the firmware is stuck or starved, which a QMP read of a
+silent guest's registers would say (`tests/CLAUDE.md`'s method for a death
+during boot), and at what rate.
+
+**Exit**: a rate over repeated boots of this image beside other guests, each
+silent one's registers read, that names where the firmware stopped; and the
+fix at that cause.
+
+**Owner**: the orchestrator.

issues/the-build-runs-host-tools-outside-rust-and-qemu.md

@@ -19,8 +19,8 @@ arrives and is not one. M4 and M5 are stages of `issues/toyos-builds-itself.md`.
 | `sh` running LLVM's `config.guess`, and the POSIX tools and `cc` it runs | LLVM's CMake, whenever this host builds an LLVM, and the C++ runtime's, in every sysroot build, ask it the host's triple, unconditionally (`get_host_triple` in `rust/src/llvm-project/llvm/cmake/modules/GetHostTriple.cmake`, which runs `sh` by name) | refused: a Rust tool does the shell's part, brush 0.4.0: on the development host (macOS, arm64) `config.guess` printed `/bin/sh`'s triple under it, `arm64-apple-darwin27.0.0`, exit 0 each. The script runs `sed`, `uname`, `mktemp`, `grep`, `rm`, `rmdir` and `cc` there under either shell, and that `cc` is the `cc` rows'. Five of the other six are refused, uutils' doing each: under brush with sed 0.2.0, grep 0.2.0 and coreutils 0.12.0's `mktemp`, `rm` and `rmdir`, and nothing else on `PATH` but the host's `uname` and `cc`, it printed that triple, exit 0. `uname` is admitted: coreutils 0.12.0's answers `-p` with `unknown` where macOS's answers `arm`, and `config.guess` reads that as PowerPC, `powerpc-apple-darwin27.0.0`, exit 0 | CMake finds brush as its `sh`, uutils' `sed`, `grep`, `mktemp`, `rm` and `rmdir`, and a Rust `uname` that answers `-p` as the host's does; or M5 runs it in the guest |
 | `git` for worktrees, submodules, checkouts, fixtures and rustc's bootstrap | adds worktrees (`src/sysroot.rs`); updates submodules (`src/lib.rs`, `src/sysroot.rs`); fetches the fork from the primary's and checks it out (`src/sysroot.rs`); makes the tests' fixture repositories; runs inside rustc's bootstrap | admitted: no Rust tool does the job, gitoxide 0.85 adds, removes and prunes no worktree, updates no submodule, stages, resets and pushes nothing, checks out only a fresh clone and fetches a local path by spawning `git`; a fixture must be what `git` makes, and bootstrap runs `git` itself | M4 runs it in the guest |
 | `git` for reads, a config write, a commit's paths written out, and clones and fetches over HTTPS | `rev-parse`, `merge-base`, `ls-tree`, `ls-files`, `cat-file`, `config --get-regexp`, `config --blob`, `status`, `diff`, `ls-remote` and `grep`, in the build system and its tests; `config --global --add safe.directory` in CI's containers; `checkout <commit> -- <paths>` through an index of its own, which writes the C++ runtime's sources out of the LLVM commit into the stored LLVM (`src/llvm.rs`); every workflow's checkout | refused: a Rust tool does it, gitoxide 0.85, which reads refs, objects, the index, config, worktrees and status, adds a value to a config file and writes it (gix-config 0.58's `File::section_mut_or_create_new`, `SectionMut::push`, `File::write_to`), walks history, diffs, and lists, fetches and clones a remote over HTTPS; `grep` is a search of the files its index names; and gitoxide's CLI 0.59 (gix 0.88) wrote the runtimes' sources of LLVM `849da7d6` into an empty directory, each path's tree through `gix rev parse`, `gix index from-tree` and `gix free index checkout-exclusive`, exit 0 each: the 18759 files `git` writes there, byte for byte and mode for mode | those are gitoxide's |
-| `cc`, `c++` and `ar` on a Linux host, `build-essential` in CI's containers | rustc links every host binary through `cc`; `cc` and `c++` compile LLVM, clang, LLD and `rustc_llvm` (`src/llvm.rs` names both to bootstrap); `cc` compiles ring's C and assembly in every build of the build system itself, whose HTTP agent is rustls on ring (`src/release.rs`); `ar` archives what `cc::Build` compiles, ring's included | admitted: no Rust tool compiles C or C++, or takes rustc's host link; ring is the one TLS provider the tree takes (owner, 2026-10-02), over a provider in Rust alone | M5: no host in the loop |
-| the toolchain's own `clang`, `llvm-ar`, `rust-lld` and `llvm-config`, built from `ToyOSOrg/llvm-project` | rustc links every guest binary with `rust-lld`; `clang` compiles the C corpus (`tests/common/compile.rs`) and, with `llvm-ar`, doomgeneric through `cc::Build` (`src/clang.rs`); rustc's bootstrap asks `llvm-config` how to link LLVM | admitted: our fork's C++, which ToyOS can one day build and run; no Rust tool compiles C, `cc::Build` archives with an `ar`, bootstrap reads LLVM through `llvm-config`, and `CLAUDE.md` links everything with `rust-lld` | M5: no host in the loop |
+| `cc`, `c++` and `ar` on a Linux host, `build-essential` in CI's containers | rustc links every host binary through `cc`; `cc` and `c++` compile LLVM, clang, LLD and `rustc_llvm` (`src/llvm.rs` names both to bootstrap); `cc` compiles ring's C and assembly in every build of the build system itself, whose HTTP agent is rustls on ring (`src/release.rs`), and in every build of doom's build script, whose download of doomgeneric is `ureq` on rustls on ring (`userland/doom/build.rs`); `ar` archives what `cc::Build` compiles, ring's included | admitted: no Rust tool compiles C or C++, or takes rustc's host link; ring is the one TLS provider the tree takes (owner, 2026-10-02), over a provider in Rust alone | M5: no host in the loop |
+| the toolchain's own `clang`, `llvm-ar`, `rust-lld` and `llvm-config`, built from `ToyOSOrg/llvm-project` | rustc links every guest binary with `rust-lld`; `clang` compiles the C corpus (`tests/common/compile.rs`) and, with `llvm-ar`, through `cc::Build` the C of every guest crate that has any (`src/clang.rs`, `src/build.rs`'s `GuestEnv`): doomgeneric, and ring's C and assembly in a test crate's `https_get` and `ring_kat`; rustc's bootstrap asks `llvm-config` how to link LLVM | admitted: our fork's C++, which ToyOS can one day build and run; no Rust tool compiles C, `cc::Build` archives with an `ar`, bootstrap reads LLVM through `llvm-config`, and `CLAUDE.md` links everything with `rust-lld` | M5: no host in the loop |
 | `ovmf-generic`, `qemu-efi-aarch64` | the x86-64 and AArch64 UEFI firmware of CI's guest containers (`src/firmware.rs`), packaged by Debian apart from QEMU | admitted: QEMU's own firmware, and no Rust firmware does its job | the instrument's QEMU carries its own firmware |
 | `ca-certificates` | the trust store `git` and `curl` verify against in CI's containers | admitted: data both of them need | goes when neither runs there |
 | the T14's Ubuntu and every tool `src/metal.rs` runs on it over `ssh` | the metal loop, on the T14 and never on a development host | outside the rule: recovery equipment on a test machine, not the build's host | they leave with Ubuntu (`issues/the-machine-updates-itself-without-ubuntu.md`) |

issues/the-internet-clients-work-unchanged.md

@@ -33,27 +33,21 @@ netd, `toyos::net` and std's ToyOS networking in the `rust/` fork.
    program on `rustls`; the program and its judge's server installed
    `rustls-rustcrypto` 0.0.2-alpha, and #660 cut both. The row comes back on
    `ring` and waits for it; `rustls-rustcrypto` does not come back (owner,
-   2026-10-02). Published `ring` 0.17.14 does not link for
-   `x86_64-unknown-toyos`: its `build.rs` picks its assembly by an OS list
-   that lacks `toyos`, and `src/rand.rs` has an OS list of its own. With
-   `"toyos"` added to `build.rs`'s `LINUX_ABI` and `target_os = "toyos"` to
-   `src/rand.rs` it builds for both ToyOS targets. In an x86-64 QEMU guest
-   it passes known answers (SHA-256,
-   SHA-512, HMAC, X25519, ChaCha20-Poly1305, AES-GCM, Ed25519, P-256,
-   `SystemRandom`), and `ureq` 3.4.2 on `rustls` 0.23.45 fetches 320000
-   bytes over TLS 1.3 from a server on the host and refuses a wrong name and
-   an untrusted root (#682, comment 5968053596). What stands before it
-   lands: a git fork's
-   `build.rs` runs `perl`, an arrival
-   `issues/the-build-runs-host-tools-outside-rust-and-qemu.md` does not
-   declare, and leaves C asserts on, so `__assert_fail` is undefined unless
-   ring builds with `debug = false` or `toyos_c` is linked; `src/build.rs`
-   gives the C compiler's environment (`cc_env`) to userland builds alone, so
-   a test crate's C is compiled by the host's `cc`; and not run: AArch64, the
-   T14, a `git =` dependency, the licence gate over ring in an image.
-   `rustls-rustcrypto` is
-   still named by doom's build script, which installs it on the host.
-   Open: what doom's build script installs instead.
+   2026-10-02). `ring` is `ToyOSOrg/ring`'s `toyos-0.17.14`: the published
+   0.17.14 package byte for byte, its build script telling a packaged tree
+   from a source tree by `pregenerated/` rather than `.git` (so a `git`
+   dependency runs no `perl`, and its C asserts and warnings-as-errors stay
+   off, leaving nothing to call `__assert_fail`), and `toyos` in `LINUX_ABI`
+   and in `src/rand.rs`'s `getrandom` list. The build writes the Mozilla
+   roots of `webpki-root-certs` to ROOT as `/system/etc/ssl/cert.pem`
+   (`build::TRUST_ROOTS`), with the text of their licence,
+   CDLA-Permissive-2.0, beside them, which the owner allowed for these roots
+   and the licence gate holds them to; `https_fetch` stages a file of its own
+   holding them and its harness's authority. In an x86-64 QEMU guest
+   `ring_kat` passes known answers, RSA and P-384 among them, and `https_fetch` has an unchanged `ureq` 3 on
+   `rustls` 0.23 fetch a body over TLS 1.3 byte-exact, send the project's
+   `User-Agent`, and refuse a wrong name and an untrusted root. Not run:
+   AArch64, the T14.
    **Exit**: `https_tls13` is a `METAL` row: on the T14's I219 an unmodified
    `ureq` and `rustls` client on the `ring` provider fetches over TLS 1.3
    from a server the harness runs, and refuses a wrong name and an untrusted

licenses/CDLA-Permissive-2.0-webpki-root-certs.txt

@@ -0,0 +1,61 @@
+# Community Data License Agreement - Permissive - Version 2.0
+
+This is the Community Data License Agreement - Permissive, Version
+2.0 (the "agreement"). Data Provider(s) and Data Recipient(s) agree
+as follows:
+
+## 1. Provision of the Data
+
+1.1. A Data Recipient may use, modify, and share the Data made
+available by Data Provider(s) under this agreement if that Data
+Recipient follows the terms of this agreement.
+
+1.2. This agreement does not impose any restriction on a Data
+Recipient's use, modification, or sharing of any portions of the
+Data that are in the public domain or that may be used, modified,
+or shared under any other legal exception or limitation.
+
+## 2. Conditions for Sharing Data
+
+2.1. A Data Recipient may share Data, with or without modifications, so
+long as the Data Recipient makes available the text of this agreement
+with the shared Data.
+
+## 3. No Restrictions on Results
+
+3.1. This agreement does not impose any restriction or obligations
+with respect to the use, modification, or sharing of Results.
+
+## 4. No Warranty; Limitation of Liability
+
+4.1. All Data Recipients receive the Data subject to the following
+terms:
+
+THE DATA IS PROVIDED ON AN "AS IS" BASIS, WITHOUT REPRESENTATIONS,
+WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED
+INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE,
+NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+NO DATA PROVIDER SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING
+WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF
+LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE DATA OR RESULTS,
+EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+## 5. Definitions
+
+5.1. "Data" means the material received by a Data Recipient under
+this agreement.
+
+5.2. "Data Provider" means any person who is the source of Data
+provided under this agreement and in reliance on a Data Recipient's
+agreement to its terms.
+
+5.3. "Data Recipient" means any person who receives Data directly
+or indirectly from a Data Provider and agrees to the terms of this
+agreement.
+
+5.4. "Results" means any outcome obtained by computational analysis
+of Data, including for example machine learning models and models'
+insights.