deps: clear eight OpenSSL advisories and drop OpenSSL from the Linux build

[Paururo]

Cargo.lock pinned rust-openssl 0.10.76, which the GitHub Advisory Database lists as affected by eight advisories published in April and May 2026. This branch patches them and then removes the surface they come from.

What changed

Commit	Change
chore(deps)	cargo update moves openssl to 0.10.81 and openssl-sys to 0.9.117
feat(gui)	reqwest switches to rustls-tls-native-roots, dropping OpenSSL from the Linux build
ci	CI compiles pathotypr-gui on Linux and asserts OpenSSL stays out

The advisories

Fixed in	Advisories
0.10.78	CVE-2026-41676, 41678, 41681, 41898 (high), 41677 (low)
0.10.79	CVE-2026-42327 (high), CVE-2026-44662 (medium)
0.10.80	CVE-2026-45784 (medium)

Exposure was low and worth stating plainly. openssl was never a dependency of pathotypr-core, so the CLI and the Bioconda package never carried it. It reached pathotypr-gui only through reqwest, hyper-tls and native-tls, which selects OpenSSL on Linux alone: macOS uses Security.framework and Windows uses schannel. Every affected API is a direct crypto or X509 entry point (Deriver, PkeyCtx, MdCtx::digest_final, AES key wrap, ocsp_responders, PSK and cookie callbacks), none of which native-tls calls on the HTTPS path this project uses.

Why rustls rather than just the version bump

A version bump resets the clock; it does not stop it. The whole class of advisory arrives because a C TLS stack sits in the graph to do one job: fetch marker panels and the model over HTTPS.

Selecting rustls-tls-native-roots removes openssl, openssl-sys, openssl-macros and native-tls from the graph and from Cargo.lock. Only openssl-probe remains, pulled by rustls-native-certs; despite the name it has no dependencies and links nothing, it just returns candidate certificate paths.

No source changes were needed. Everything this project uses from reqwest is independent of the TLS backend: Client::builder, the SSRF-guarding DNS resolver in util.rs, the redirect policy in commands.rs, and the stream feature.

Roots come from the system store, not a bundled Mozilla set. Users on hospital or institute networks that terminate TLS with a private CA keep working. rustls-tls with webpki-roots would have broken their downloads, which is the reason for the -native-roots variant.

The Linux release build also stops needing the system OpenSSL headers. It had been finding them transitively through libwebkit2gtk-4.1-dev rather than from anything release.yml installs on purpose.

Verification

Not just a compile check. A client built with the same reqwest configuration as commands.rs performed real downloads over rustls:

OK 200     91,713 B  pathotypr_lineage_markers_v1.0.0.tsv
OK 200      8,949 B  pathotypr_rf_model_v1.0.0.pathotypr
OK 200  4,485,067 B  MTB_ancestor_reference.fasta

The reference genome was read in full through the TLS stream, so the record layer is exercised and not only the handshake and headers.

• cargo check -p pathotypr-gui passes with no source changes.
• cargo tree -i openssl --target x86_64-unknown-linux-gnu is empty.
• cargo test -p pathotypr-core: 74 passed, 0 failed.
• The new CI assertion was tested in both directions: against the previous commit it correctly reports native-tls v0.2.18 and openssl v0.10.81, and it passes on this branch.

Why the CI job is part of this

CI ran only against pathotypr-core, so a pull request never compiled the Tauri backend. The first two commits here would have merged with no coverage at all, since reqwest and the TLS stack live entirely in pathotypr-gui.

The assertion matters beyond this change: the rustls choice is a feature selection on one line of src-tauri/Cargo.toml, and a future dependency bump could re-enable default features and pull the C TLS stack back in silently.

The core job keeps its name so any branch protection rule referring to it still matches. The new job installs GTK and WebKit, so it is slower than the core job; restricting it to src-tauri/** and Cargo.lock changes is a two-line follow-up if that becomes annoying.

Note

An unsolicited automated pull request proposed the same lockfile bump. The cargo update here produces a byte-identical Cargo.lock, so that change is reproduced independently and this branch goes further by removing the dependency.