Track rustls-pemfile (RUSTSEC-2025-0134) — unmaintained via axum-server

[WaylandYang]

Background

`cargo audit` flags one informational warning on `main` Cargo.lock as of `63bca01`:

```
Crate: rustls-pemfile
Version: 2.2.0
Warning: unmaintained
Title: rustls-pemfile is unmaintained
Date: 2025-11-28
ID: RUSTSEC-2025-0134
URL: https://rustsec.org/advisories/RUSTSEC-2025-0134
Dependency tree:
rustls-pemfile 2.2.0
└── axum-server 0.7.3
└── forkd-controller 0.3.4
```

Not a security vulnerability. The rustls maintainers folded PEM-parsing helpers back into the main `rustls` crate and stopped publishing `rustls-pemfile` standalone. The 2.2.0 release still works; it just won't get further updates.

Why we can't fix it directly

`rustls-pemfile` lives under the rustls org. We depend on `axum-server` (programatik29/axum-server), which still pins `rustls-pemfile` in its 0.7.x. To clear the warning we need:

• `axum-server` to cut a release that switches off `rustls-pemfile`, OR
• we replace `axum-server` with something else (axum's built-in TLS via `axum::serve`, `hyper-rustls` directly, etc.) — larger refactor.

When to revisit

• When `axum-server` releases something newer than 0.7.3 — re-run `cargo audit`, expect this to clear.
• If a real RUSTSEC vulnerability lands on `rustls-pemfile` 2.2.0 before then, escalate to the second bullet.

Acceptance

`cargo audit` returns 0 warnings on a fresh clone of main.

(Filed during a full-workspace `cargo audit / clippy / doc / test` sweep on 2026-05-29; everything else came back clean. See #191 for the concurrent rustdoc cleanup.)

[WaylandYang]

Note: we already use rustls directly — `axum-server` is just glue

Confirmed the actual dependency posture:

```toml

crates/forkd-controller/Cargo.toml

axum.workspace = true
axum-server.workspace = true # TLS glue
rustls.workspace = true # we already depend on this directly
```

```rust
// crates/forkd-controller/src/lib.rs:157-182
let tls = match (&cfg.tls_cert, &cfg.tls_key) { ... };
match tls {
Some(tls_cfg) => axum_server::bind_rustls(...).serve(...).await?,
None => axum_server::bind(cfg.bind).serve(...).await?,
}
```

So "why not use rustls instead" isn't quite the question — we already do. `axum-server` is a thin (~30 LOC of public API) wrapper that plugs the axum `Router` into the `tokio-rustls` accept loop and adds a graceful-shutdown `Handle`. `rustls-pemfile` is pulled in only for cert/key loading; rustls 0.23 folded equivalents back into the main crate, but `axum-server` hasn't bumped yet.

What dropping `axum-server` would actually look like

~60-100 LOC inline using `tokio-rustls` + `hyper-util` directly:

```rust
let listener = TcpListener::bind(cfg.bind).await?;
let acceptor = TlsAcceptor::from(Arc::new(rustls_config));
loop {
let (sock, _) = listener.accept().await?;
let acceptor = acceptor.clone();
let app = app.clone();
tokio::spawn(async move {
let tls = acceptor.accept(sock).await?;
let svc = hyper_util::service::TowerToHyperService::new(app);
hyper::server::conn::http1::Builder::new()
.serve_connection(TokioIo::new(tls), svc).await
});
}
```

Plus graceful-shutdown plumbing (`spawn_shutdown_signal` currently uses `axum_server::Handle` — we'd reimplement against a `Notify` or `CancellationToken`) and probably ALPN/h2 negotiation if any client asks for it.

Why not do it now

1. Not a vulnerability — RUSTSEC-2025-0134 is an unmaintained advisory, not a CVE. The 2.2.0 release still works correctly; the rustls team simply stopped publishing new releases of that helper crate.
2. `axum-server` will likely update on its own within a release cycle or two — there's plenty of axum users in the same situation, so upstream pressure is real.
3. Owning a TLS accept loop = owning its bug surface — cert hot-reload, ALPN, connection limits, TLS-error mapping, h2 upgrade. `axum-server` has been carrying that load for us.
4. TLS isn't on the forkd hot path today — default bind is `127.0.0.1`, snapshot-Hub-style deployments mostly talk to the daemon over loopback or a unix socket. The `--tls-cert` / `--tls-key` path is reserved for multi-host setups that nobody runs in production yet.

Trigger conditions for revisiting

• A real RUSTSEC vulnerability (not just unmaintained) lands against `rustls-pemfile` 2.2.0 → escalate to the drop-axum-server replacement immediately.
• `axum-server` still hasn't dropped `rustls-pemfile` six months out (≈ 2026-11) → consider the swap purely to clear `cargo audit` noise.
• Forkd starts shipping a multi-host TLS deployment story (Phase 8+? v0.5?) → re-evaluate whether the extra TLS control is worth owning the accept loop.