The latest articles on DEV Community by Mohamed Alkiswani (@oya-browser). https://dev.to/oya-browser https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4211751%2F9bef722c-a1ed-4eb1-baa2-3158666e7477.jpg https://dev.to/oya-browser en Mohamed Alkiswani Wed, 28 Oct 2026 18:59:07 +0000 https://dev.to/oya-browser/what-a-from-scratch-browser-actually-trusts-webpki-roots-exact-pins-and-the-emudhra-week-2plk https://dev.to/oya-browser/what-a-from-scratch-browser-actually-trusts-webpki-roots-exact-pins-and-the-emudhra-week-2plk <p>We're writing a browser from scratch in Rust. It's called Mars: own HTML parser and layout engine, own JS engine, own HTTP framing on top of rustls, native macOS shell. When you own the network stack you also own the question Apple is getting shouted at about this week: which certificate authorities does the thing trust, and who updates that list?</p> <h2> How Mars gets its roots </h2> <p>Our network crate, Relay, builds a rustls <code>RootCertStore</code> from <code>webpki_roots::TLS_SERVER_ROOTS</code> once at startup and keeps it in a <code>OnceLock</code>. That's it. No OS keychain, no <code>/etc/ssl/cert.pem</code>, no runtime download. The trust anchors are whatever the <code>webpki-roots</code> crate contained the day the lockfile was written. That's a normal choice for rustls users, and it has one property worth saying out loud: the trust store ships inside the binary, so it only changes when you rebuild.</p> <h2> What I found today </h2> <p>The eMudhra / emSign compromise is around ten days old. Mozilla, Google, Microsoft and most Linux distros dropped the roots within days. Apple blocked the certificates in Safari and Mail but left the macOS command line tools reading a cert.pem that still trusts them, which is why Hacker News is on fire.</p> <p>In that thread someone asked whether there's a Rust crate that compiles root certs into binaries. There is, and we use it. So I checked. Both crates that do TLS in Mars pinned <code>webpki-roots = "=1.0.9"</code>, released July 18. Grepping <code>src/lib.rs</code> in each release:</p> <ul> <li>1.0.9 (Jul 18): emSign Root CA - G1, emSign Root CA - C1, emSign ECC Root CA - G3, emSign ECC Root CA - C3</li> <li>1.0.10 (Oct 19): removed emSign ECC Root CA - G3</li> <li>1.0.11 (Oct 23): removed emSign Root CA - C1 and emSign ECC Root CA - C3, tracking the CCADB removals</li> </ul> <p>So Mars, as of this morning, had the same hole as <code>/usr/bin/curl</code> on a Mac. Nothing at runtime would have told us. rustls does no revocation checking unless you hand it CRLs, and we don't. There is no blocklist. The bundle is the whole story.</p> <h2> The fix and the lesson </h2> <p>The fix took four minutes: bump both pins to <code>=1.0.11</code>, <code>cargo update -p webpki-roots</code>, <code>cargo check</code>. It compiles and it's in the tree.</p> <p>The lesson is the uncomfortable one. Mars pins dependencies to exact versions, and an exact pin on a root bundle is a decision to stop receiving CA removals. It means someone has to watch that crate's releases the way an OS vendor watches the CCADB. For a browser that isn't optional, so it goes on the release checklist. I'd like to know how other rustls users handle it: Dependabot on that one crate, a CI job that diffs root names between versions, or just reading the release notes.</p> <p>Repo: <a href="https://github.com/OyadotAI/oya-browser" rel="noopener noreferrer">https://github.com/OyadotAI/oya-browser</a>, folder <code>mars/</code>. Source-available under a Sustainable Use License, SDK and CLI MIT.</p> rust security browsers