It has been 15 months since I left my job at a startup and decided to work on improving open source Rust software going forward. I started out trying to write monthly updates, but that proved too time-consuming. Instead, here’s a summary of what I worked on in 2025, and what I want to do in 2026.
While substantial parts of this work have been paid for (particularly for rustls and Hickory DNS), a lot of what I do ends up being fairly invisible maintenance work; fixing bugs, keeping dependencies up to date to avoid duplicate dependencies, and so forth. I’m grateful for everyone who has supported my work through GitHub Sponsors or thanks.dev, and hope t…
It has been 15 months since I left my job at a startup and decided to work on improving open source Rust software going forward. I started out trying to write monthly updates, but that proved too time-consuming. Instead, here’s a summary of what I worked on in 2025, and what I want to do in 2026.
While substantial parts of this work have been paid for (particularly for rustls and Hickory DNS), a lot of what I do ends up being fairly invisible maintenance work; fixing bugs, keeping dependencies up to date to avoid duplicate dependencies, and so forth. I’m grateful for everyone who has supported my work through GitHub Sponsors or thanks.dev, and hope that organizations that benefit from my work will consider sponsoring me in 2026.
Rust Project
rustup is gearing up for a 1.29 release soon, which contains some nice UX improvements started by Francisco Gouveia which I contributed to. After changing the default backend to reqwest with rustls in 1.28, I worked on making it even more robust. I continued simplifying the codebase; after about 15 months and 460 commits, I have so far removed more code than I’ve added.
Early in the year I became a RustSec maintainer after noticing that the RustSec project seemed to be slowing down due to a lack of active maintainers. Since then I’ve reviewed 125 advisories (many of which have been merged), as well as submitting 30 PRs to improve rustsec crates like cargo-audit and the underlying rustsec library crate which is also used by cargo-deny.
Via my work on RustSec, I started contracting with the Rust Foundation to work on a security tab for crates.io. I wrote the RFC and started the implementation work, an early version of which has been deployed. I will continue by adding some more advisory metadata on the crates.io pages.
rustls
The ISRG (through its Prossimo project) has been funding much of my rustls work in 2025. I worked on improving error handling to make it easier to troubleshoot errors as well as (experimental) support for post-quantum secure ML-DSA signature algorithms.
In July we branched off 0.23.x to start work on 0.24, which is focused on stabilizing the API. In particular, I spent a bunch of time on the identity verification and resolution API as well as moving the first-party crypto providers out of the main crate. We also have plans to introduce a lower-level API, which will hopefully allow more efficient integrations for downstream users. rustls is currently the 56th most downloaded crate (in the last 90 days) – after many years of contributing to rustls, I’m still excited by the prospect of making networking on the public internet safer and faster at the same time.
Outside of funded work, I worked on improving the rcgen crate that can be used to generate X.509 certificates (which are what TLS uses for authentication). In July, we released 0.14.0 with a new API that is easier to use while being more resistant to misuse, and several smaller releases have followed.
upki
After discussing the topic of web PKI security on Linux (and other non-Apple Unix platforms) and being impressed with Canonical’s efforts to adopt sudo-rs and the Rust coreutils in Ubuntu, we talked to them about improving certificate verification on Linux. This has resulted in them funding our work on addressing Linux’s missing PKI infrastructure through the upki project. It is still a bit early, but we’re making good progress and hope to make this another substantial security improvement, and not just for tools written in Rust.
Hickory DNS
We released Hickory DNS 0.25 in March, which included substantial simplification, and soon after branched off 0.26 development towards improving compliance, particularly for DNSSEC and the recursive resolver. Parts of my efforts have been in cleaning up and modernizing the codebase, resulting in the removal of 18k lines of code over the past 5 years.
In the past 6 months, and going forward into 2026, we’re working on enabling the use of the Hickory DNS recursive resolver at Let’s Encrypt. Hopefully this will be a first step towards broader adoption of Hickory DNS in production.
Miscellaneous
Over the years I have been trying to help out with maintenance of a substantial number of Rust crates that I use myself or that are widely used in the ecosystem. In 2025, I adopted a few more orphaned crates:
- humantime (29M recent downloads, used in tokio-console, cargo-nextest)
- hashlink (27M recent downloads, used in sqlx, rusqlite, salsa)
- console (32M recent downloads, used in indicatif)
- hostname (15M recent downloads, used in kube-runtime, lettre)
- resolv-conf (9.3M recent downloads, used in hickory-resolver)
- dialoguer (6.7M recent downloads, used in cargo-nextest, wasmpack)
I typically don’t do much proactive development on these, but at least make sure dependencies are kept up to date, and straightforward contributions get reviewed (and hopefully, merged!) in a timely manner.
To balance out the ongoing adoption of orphaned crates, I’m inclined to wind down maintenance of chrono and chrono-tz in the coming months. The API design for these crates is quite dated, revising it would be a lot of effort, and with jiff there is now an alternative I feel comfortable recommending.
Other notable crates I spent significant effort on:
- While I made many small improvements to Quinn, most of them have not been very interesting. Our QUIC implementation seems mature in the sense that there are few remaining bugs, although performance could definitely be improved more. One interesting recent development is a PR to substantially revise our implementation of the BBR congestion control algorithm. I’ve also been excited to see Mozilla adopt our quinn-udp utility crate in Firefox. I hope to see support for HTTP/3 in reqwest and hyper in 2026.
- In July I released instant-acme 0.8.0, with a cleaner API and support for modern ACME extensions. instant-acme is now the most popular ACME library on crates.io, and we’ve received essentially no feedback – which is usually good news with low-level libraries!
- Towards the end of the year, I finally took the time to get some documentation done for instant-xml, my serde-like library which tries to be more correct and reliable in the context of the XML data model; in particular, when dealing with namespaces. While it doesn’t seem to have gained widespread adoption, feedback from users who did try it has been positive.
Across the entire year, I ended up submitting 850 and reviewing 1600 PRs, distributed over 100 repositories (a handful of which for my own use).
Closing words
So far, being a professional Rust maintainer is a great experience. I hope to continue making the Rust ecosystem a fun, safe and efficient environment for building software in 2026. Thanks to all my sponsors past and present, including:
- aws
- syntaxfm
- canonical
- getsentry
- sourcegraph
- conradludgate
- espoal
- instant-labs
- bdaehlie
- Quad9DNS
- denoland
- mstange
- thomaseizinger
- astral-sh
- MJDSys
- stepfunc
- repi
- dconnolly
- tweedegolf
Details
For a deep dive on what I worked on, feel free to peruse this table I generated: