{ "version": "https://jsonfeed.org/version/1", "title": "Ian's Digital Garden", "home_page_url": "https://ianwwagner.com/", "feed_url": "https://ianwwagner.com//tag-cryptography.json", "description": "", "items": [ { "id": "https://ianwwagner.com//reqwest-0-13-upgrade-and-webpki.html", "url": "https://ianwwagner.com//reqwest-0-13-upgrade-and-webpki.html", "title": "reqwest 0.13 Upgrade and WebPKI", "content_html": "

In case you missed the announcement,\nthe reqwest crate has a new and very important release out!\nreqwest is an opinionated, high-level HTTP client for Rust,\nand the main feature of this release is that rustls\nis now the default TLS backend.\nRead the excellent blog posts from Sean and others on why rustls\nsafer and often faster than native TLS.\nIt's also a lot more convenient most of the time!

\n

Changes to certificate verification

\n

This post is about one of the more mundane parts of the release.\nPreviously there were a lot of somewhat confusing features related to certificate verification.\nThese have been condensed down to a smaller number of feature flags.\nThe summary of these changes took a bit to "click" for me so here's a rephrasing in my own words.

\n\n

The documentation and release notes also mention that tls_certs_merge is not always supported.\nI frankly have no idea what conditions cause this to be supported or not.\nBut tls_certs_only apparently can't fail. ¯\\_(ツ)_/¯

\n

What this means for containerized applications

\n

The reason I'm interested in this in mostly because at $DAYJOB, just about everything is deployed in containers.\nFor reasons that I don't fully understand (something about image size maybe??),\nthe popular container images like debian:trixie-slim do not include any root CAs.\nYou have to apt-get install them yourself.\nThis is to say that most TLS applications will straight up break in the out-of-the-box config.

\n

Previously I had seen this solved in two ways.\nThe first is to install the certs from your distribution's package manager like so:

\n
RUN apt-get update \\\n && apt-get install -y --no-install-recommends ca-certificates \\\n && rm -rf /var/lib/apt/lists/*\n
\n

The second is to add the WebPKI roots to your cargo dependencies.\nThis actually requires some manual work; adding the crate isn't enough.\nYou then have to add all of the roots (e.g. via tls_certs_merge or tls_certs_only).

\n

Which approach is better?

\n

The net result is approximately the same, but not entirely.\nThe system-level approach is more flexible.\nPresumably you would get updates in some cases without having to rebuild your application\n(though you do not get these automatically; the certs are only loaded once on app startup\nby rustls_platform_verifier!).\nPresumably you would also get any, say, enterprise-level trust, distrust, CRLs, etc.\nthat are dictated by your corporate IT department.

\n

The WebPKI approach on the other hand is baked at build time.\nThe crate\nhas a pretty strong, if slightly obtuse warning about this:

\n
\n

This library is suitable for use in applications that can always be recompiled and instantly deployed. For applications that are deployed to end-users and cannot be recompiled, or which need certification before deployment, consider a library that uses the platform native certificate verifier such as rustls-platform-verifier. This has the additional benefit of supporting OS provided CA constraints and revocation data.

\n
\n

Attempting to read between the lines, past that "instantly deployed" jargon,\nI think they are really just saying "if you use this, certs are baked at compile time and you never get automatic updates. Be careful with that."

\n

So it's clear to me you shouldn't ship, say, a static binary to users with certs baked like this.\nBut I'm building server-side software.\nAnd as of February 2026, people look at you funny if you don't deploy using containers.\nI can deploy sufficiently instantly,\nthough to be honest I would have no idea when I should.\nMost apps get deployed frequently enough that I would assume this just doesn't matter,\nand so I'm not sure the warning as-written does much to help a lot of the Rust devs I know.

\n

Conclusion

\n

My conclusion is that if you're deploying containerized apps, there is approximately no functional difference.\nYour container is a static image anyways.\nThey don't typically run background tasks of any sort.\nAnd even if they did, the library won't reload the trusted store during application.\nSo it's functionally the same (delta any minor differences between WebPKI and Debian, which should be minimal).\nSimilarly, unless you work for a large enterprises / government,\nyou probably don't have mandated, hand-picked set of CAs and CRLs.\nSo again here there really is no difference as far as I can tell.

\n

In spite of that, I decided to switch away from using WebPKI in one of our containers that I upgraded.\nThe reason is that structuring this way\n(provided that the sources are copied from a previous layer!)\nensures that every image build always has the latest certs from Debian.\ncargo build is a lot more deterministic,\nand will use whatever you have in the lockfile unless you explicitly run cargo update.

\n

And even though I'm fortunate to not have an IT apparatus dictating cert policy today,\nyou never know... this approach seems to be both more flexible and creates a "pit of success"\nrather than a landmine where the trust store may not see an update for a year\ndespite regular rebuilds.

\n

In other words, I think Sean made the right choice, and you should probably delegate to the system,\nunless you have a particular reason to do otherwise.

\n

Hope this helps; I wrote this because I didn't understand the tradeoffs initially,\nand had some trouble parsing the existing writing on the subject.

\n", "summary": "", "date_published": "2026-02-13T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "rust", "cryptography" ], "language": "en" } ] }