Dirkjan Ochtman

OxiSH: a modern, memory-safe SSH server

2026-08-13T00:00:00+02:00

I'm happy to announce OxiSH, a modern, memory-safe SSH server that I've been working on for 20 months. OxiSH is written in Rust, with a safe sans-I/O protocol core and an abstraction for the underlying cryptography primitives.

Why?

Many large organizations have shown that up to 70% of security vulnerabilities in software written in C and C++ happen due to memory safety issues (Microsoft, Google). In the US, government agencies have been advocating for the use of memory-safe programming languages for a few years now. The Prossimo project lists three risk criteria to help prioritize where memory safety is most important:

Very widely used (nearly every server and/or client)
On a security boundary
Performing a critical function

SSH servers meet all three of these criteria.

OpenSSH is the predominant implementation; it's written in C and has been around for decades. It continues to suffer from memory safety issues to this day. I started OxiSH because I think it's worth investing in a memory-safe alternative.

What's been done?

Before starting on OxiSH, I spent some time looking for existing SSH implementations in Rust that could help me bring this idea to life sooner. In particular, I looked at russh which seems to be fairly popular. However, I noticed that it implements some old crypto primitives and seems to have a fairly monolithic design, so I decided to start from scratch instead.

Although I could keep working on OxiSH in (semi-) stealth mode, I think it's now in a good enough state to announce publicly. That does not mean it is ready for production usage, and there are a bunch of limitations (see below). This is a starting point, looking for feedback and contributions from other folks; I will soon start dogfooding this on my own server as well.

I have a Tokio-based async networking server with a sans-I/O SSH protocol core, public key authentication support (with Ed25519 and ECDSA P-256 keys only), and a basic shell implementation that can spawn a child process and connect it to the SSH session. It gets tested on Linux and macOS against OpenSSH clients in CI. Windows support would be nice but will require someone else to step in. There is no client implementation yet, and I currently don't have plans to work on that, but the sans-I/O core could well be used to enable it. Beyond the low-level sans-I/O API, there's also a (currently small) library API to enable reuse.

Cryptographic primitives are implemented with two different backends, graviola and aws-lc-rs. Cargo features can be used to select which backend is used at compile time; graviola, the default, is easier to build but only works on x86-64 and ARM64, while aws-lc-rs is more portable, should be slightly more efficient, and can be compiled in FIPS mode on Linux. It implements hybrid post-quantum key exchange using the mlkem768x25519-sha256 algorithm, and curve25519-sha256 is supported for key exchange as a fallback algorithm for older clients. Ed25519 and ecdsa-sha2-nistp256 are the only supported public key algorithms, AES-128-GCM is the only supported encryption algorithm and SHA-256 is the only supported hash algorithm. It should be fairly easy to add other algorithms that are supported by the underlying backends, but I'd like to keep the set as small as possible to reduce attack surface.

I have made an effort to review historic OpenSSH vulnerabilities to make sure both the design and implementation of OxiSH avoid similar mistakes outside the memory-safety realm. I would like to pay for an external audit of the codebase in the future, but I'm unlikely to be able to fund that work myself.

Here are some of the more obvious missing features:

No agent forwarding, let alone other kinds of forwarding
No scp or sftp support
No password authentication

Full feature (or even bug for bug compatibility) with OpenSSH is explicitly not a goal of this project, but I'd like to hear more about what people would need to see to replace OpenSSH in their environment. Please file an issue!

Who have been involved?

I wrote most of the code, and I have reviewed all of it in great detail. I have more than 10 years of experience writing Rust code, and have been maintaining some popular network protocol projects for the last few years, including:

rustls, a widely used TLS library in Rust
Quinn, a popular implementation of the QUIC protocol in Rust
Hickory DNS, a DNS implementation in Rust

For a few weeks earlier this year, I was fortunate to get help from the fine folks at the Trifecta Tech Foundation, who were able to get an investment from the Sovereign Tech Agency to help figure out some of the core platform interactions in the server, including an initial draft of privilege separation and terminal handling. We hope to continue our collaboration on this project in the future.

Where to from here?

As mentioned above, this is just a starting point. Please leave feedback and/or contribute PRs directly (but please check out the contributing guidelines including AI policy before jumping in). If you want to support my work on OxiSH and other projects, please consider sponsoring me. If you want to get in touch privately, my email address should be easy to find from my website.

Rust maintenance in 2025

2026-01-09T00:00:00+01:00

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).

Podcast appearances

It was great to be invited to appear on 4 podcast episodes this year:

Oxide and Friends S5 E9, the story of a rustup regression, in March
SustainOSS 268, on sustaining critical Rust libraries, in May
NetStack.FM episode 7, on Rust networking libraries, in September
Open Source Security, on rustls, in December

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:

Repostory	Auth	Rev
hickory-dns/hickory-dns	165	293
rustls/rustls	113	238
rust-lang/rustup	63	177
djc/instant-acme	36	50
quinn-rs/quinn	35	143
rustls/rcgen	31	29
rustsec/rustsec	30	43
rustls/webpki	29	29
chronotope/chrono	22	40
console-rs/console	15	19
djc/bb8	13	13
rustsec/advisory-db	12	125
chronotope/chrono-tz	12	17
djc/instant-xml	12	3
console-rs/indicatif	11	25
rustls/rustls-platform-verifier	11	13
rustls/rustls-native-certs	11	13
hickory-dns/resolv-conf	10	2
rustls/tokio-rustls	9	19
GitoxideLabs/gitoxide	8	0
flamegraph-rs/flamegraph	7	22
chronotope/humantime	7	5
nico-abram/blondie	7	0
memorysafety/rav1d	6	20
rustls/rustls-ffi	5	36
rustls/pki-types	5	15
rustls/webpki-roots	5	14
rustls/upki	5	11
djc/instant-epp	5	0
djc/abna-rs	5	0
rustls/rustls-openssl-compat	4	27
rustls/hyper-rustls	4	12
djc/instant-distance	4	6
djc/gcp_auth	4	4
djc/instant-segment	4	1
djc/tokio-imap	3	7
chronotope/pure-rust-locales	3	2
seanmonstar/reqwest	3	1
metrics-rs/metrics	3	0
djc/hostname	2	7
console-rs/dialoguer	2	6
rustls/ktls	2	6
rustls/openssl-probe	2	4
djc/hashlink	2	2
rust-lang/crates.io	2	1
rust-lang/team	2	1
aws/aws-lc-rs	2	0
stalwartlabs/mail-auth	2	0
tokio-rs/tracing	1	20
tokio-rs/tokio	1	4
rust-lang/blog.rust-lang.org	1	3
redis-rs/redis-rs	1	1
rust-lang/rfcs	1	1
steffengy/schannel-rs	1	0
nagisa/rust_libloading	1	0
tomtomwombat/fastbloom	1	0
awslabs/cargo-check-external-types	1	0
unicode-org/icu4x	1	0
pksunkara/cargo-workspaces	1	0
nicoburns/blessed-rs	0	11

October on GitHub (2024)

2025-01-21T00:00:00+01:00

Since leaving my job at the end of August, I figured I would try to write up a report of most of the open source stuff I worked on (see previous month). Turns out writing these is a lot of work, so it took me a while to write up October's activity -- I ultimately wrote this with the help of some tooling I wrote.

rustls

rustls is a pure Rust implementation of the TLS protocol.

Here are some things I worked on:

I migrated both tokio-rustls and rustls-native-certs to the new PEM API in rustls-pki-types (as discussed last month), cutting down on dependencies.
I implemented the Error trait for the new pem::Error type in rustls-pki-types, which we had missed in the PR implementing PEM decoding.
As I tried to switch instant-epp (see below) to the rustls-platform-verifier, I had to remind myself of how the high-level rustls-platform-verifier worked and found it non-trivial to incorporate into the instant-epp RustlsConnector. I decided to improve the API by exposing a couple of extension traits, which needed some additional rustls API (adding API while net removing code!).
Reworked the rustls-native-certs README to clarify that most users should use rustls-platform-verifier instead, as an alternative to an earlier PR which made more cautious changes, and linked to the deployment considerations.
I addressed an issue report about excessive logging in rustls by refining when we log warning alerts.

Joe and Daniel did more performance work:

This culminated in a post on how rustls outperforms OpenSSL and BoringSSL.

There was some discussion on a better interface to setting the certificate verifier for an entire process, potentially by mimicking the crypto provider API.

Finally, initial support for RFC 7250 raw public keys (which is helpful especially in P2P scenarios) was released as part of 0.23.16.

Hickory DNS

Hickory DNS is a project to build a comprehensive suite of Rust libraries to build DNS services on top of. Because the project is nearing a (fairly large) feature release, I've been trying to make a number of improvements to the project, cleaning up the API and moving code around to reduce complexity.

I removed the synchronous client API, which was a thin, not very well maintained wrapper around the larger, more capable async API. This entailed porting some tests and also removing the synchronous resolver API.
I started looking at the DNSSEC cryptography API to figure out what needed to be done to both support ring as a full-fledged replacement for OpenSSL and add support for the ring-like aws-lc-rs provider. The DNSSEC API wasn't very well-designed, so this took quite some efforts. I started by looking at the KeyPair type which had a lot of functionality attached to it, and cleaned it up by moving code out of it and clarifying private/public key responsibilities.
Improved CI cycle times by avoiding unnecessary release builds.
Made a number of generic code quality/API improvements, like simplifying socket address literals, moving StoreConfig to bin crate, making error modules private, switching to using doc_auto_cfg, cleaning up rustdoc warnings, and replacing TryParseIp trait with IntoName::to_ip().
Simplified rustls usage by leveraging the new PEM reading API.

Notable PRs I reviewed:

Start propagating NX domain and no record found errors.
Marcus addressed a very old request to enable blackholing DNS requests.
Someone contributed an implementation of the CERT record type from RFC 4398 for storing certificates in the DNS (likely with some LLM help).
David added configuration to avoid specific UDP ports on outbound traffic.

KumoMTA

I've been doing some consulting work for KumoMTA, a startup building a mail transfer agent (MTA) for enterprise senders. In October, I continued my work on SPF support, threading through the raw SPF implementation to the Lua-based configuration API and generalizing the DNS resolution API.

Quinn

Quinn is the most popular Rust implementation of the QUIC transport protocol.

I wasn't very active on Quinn in October, and only fixed a small bug in the datagram state management around dropping too large datagrams.

Fortunately, several other folks contributed interesting work:

A Solana engineer contributed an optional alternative send stream scheduling strategy as well as work to reduce memory allocations.
An Iroh engineer changed quinn-proto such that it can be used on the wasm32-unknown-unknown target.
Someone cleaned up some edge cases in idle timeout negotiation.
Someone added support for aws-lc-rs FIPS cryptography.
A Mozilla engineer implemented faster UDP/IO on Apple platforms.
Someone enabled support for Apple's visionOS and tvOS platforms.

tracing-opentelemetry

For lack of anyone else doing the work, I maintain the tracing-opentelemetry integration crate that allows the tracing project to work with the opentelemetry crates. The OpenTelemetry Rust SIG have been increasing the pace of semver-incompatible releases, but unfortunately missed some things.

As such, I cleaned up their tonic code generation to use the right crate versions and bumped their MSRV to match the new dependencies.
I wrote up a note in the tracing-opentelemetry README on version compatibility between the opentelemetry-* crates and tracing-opentelemetry.
Reviewed the upgrade to opentelemetry 0.26.
Reviewed a locking efficiency improvement.
Reviewed optional attaching the level of exported spans.

bb8

bb8 is a full-featured async connection pool for Tokio. Apparently it's being used in PgCat, because an AWS engineer dropped by with some improvements:

(The latter two were ultimately merged as part of a roll-up PR that added some cleanup, and released with other accumulated fixes as 0.8.6.)

instant-epp

instant-epp implements the EPP protocol used for provisioning domains. It relies on instant-xml (see below) for getting the namespace-heavy EPP specs right. Although instant-epp does not see a lot of activity, a contributor popped up that contributed some changes. Apparently most EPP users fork their dependencies instead of contributing upstream -- or funding upstream development.

instant-xml

instant-xml is a serde alternative specifically focused on the XML data model, with pretty good support for XML namespaces (which is necessary for EPP). The same person who contributed changes to instant-epp also made some minor improvements in instant-xml to facilitate their development.

instant-acme

instant-acme is a RFC 8555 client for provisioning TLS certificates.

Reviewed a contributed PR to expose account IDs, which can be used in CAA records to restrict which account can request certificates.

gcp_auth

gcp_auth is a simple API for authenticating to Google Cloud Platform services. It supports both production and development environments, similar to official Google SDKs for other languages (though likely more limited in scope).

In October, someone contributed support for setting the audience in custom service account token providers, which had been asked for a few times.

chrono

chrono is one of the most popular date/time libraries in the Rust ecosystem. I took over maintenance because the previous maintainers didn't want to maintain it anymore, so I support the community by reviewing incoming pull requests.

This month, someone contributed support for OpenHarmony OS.

On sustainability

Since my last post, a few more companies started sponsoring my work, for which I am very grateful. For now, I'm still funding most of my open source activity from contract work, though I'm currently talking to some organizations that are looking to more directly fund open source work. Excited to see how that goes!

Many thanks to these sponsors (5 USD/month or more):

syntaxfm
getsentry
denoland
ctz
astral-sh
bdaehlie
Quad9DNS
thomaseizinger
stepfunc
tweedegolf
codecov
repi
MJDSys
mstange
stackabletech
dimlev
Shnatsel
eightseventhreethree
malyn
dconnolly
paolobarbolini
block

September on GitHub (2024)

2024-10-18T00:00:00+02:00

Since leaving my job at the end of August, I figured I would try to write up a report of all the open source stuff I worked on in September. Herewith a not quite complete account of things I was involved in.

rustls

rustls is a pure Rust implementation of the TLS protocol.

Substantial effort last month went into migrating support for PEM decoding from the rustls-pemfile crate (backed by the base64 crate) to the rustls-pki-types crate. While the new decoder is slightly slower, it avoids timing side channel attacks (only used for PEM items containing private keys). We iterated a number of times on making the new API easy to use. Adopting the new APIs should shrink dependency graphs by getting rid of both rustls-pemfile (which got a semver-compatible bump to use the new implementation) and the base64 crate.

We went through a number of iterations reviewing a PR from Bart Dubbeldam and Adolfo Ochagavía adding support for RFC 7250 raw public keys.

ComplexSpaces added deployment considerations to the rustls-platform-verifier README. We now recommend (almost) everyone use the platform verifier for their server certificate verification needs.

Joe has been doing interesting work to improve performance:

We can now send flights of handshake messages in a single message.
He eliminated an allocation in signature verification.
And eliminated large copies in resumption code paths.

I contributed some smaller improvements last month:

I finally converted one of the rustls examples from the long-dead docopt to clap. Joe kindly offered to take care of the others.
I finished a contributed PR to enable signing without a private key in rcgen.
Clarified error handling in rustls-native-certs.

Hickory DNS

I moved the RuntimeProvider trait from hickory-resolver down into hickory-proto. This abstraction was created to allow the resolver to abstract over different async runtimes (and their I/O traits and types), but it did not actually depend on the resolver infrastructure itself. Meanwhile, at the lower -proto level we had a somewhat parallel set of abstractions, so I set out to move the RuntimeProvider into -proto and try to make it the focal point of abstracting over runtimes and I/O. This work was split over two PRs, one for UDP and one for TCP. I should probably review whether there is potential for further simplification in the other protocols (H2, QUIC, H3).
Hickory DNS depends on the resolve-conf crate in order to find the system DNS configuration (on Unix systems). Unfortunately the resolv-conf crate has been unmaintained for a while. While attempts to contact the maintainer didn't lead to any results, Ferrous team member Andrei Listochkin mentioned that he knew the original maintainer and could talk to them via Telegram. Soon, the repository and crate ownership had been transferred to us, so that we can start fixing some of the outstanding issues soon.
After reviewing a PR to allow customization of the DNS over HTTP URL path I noticed that the configuration for the main Hickory DNS binary crate was distributed over the -server library crate and the hickory-dns binary crate. Some of this didn't really make sense, so I submitted a collection of config tweaks to improve on the situation.
While reviewing another PR, I noticed that the hickory-server crates had a bunch of instances of Arc<Box<dyn AuthorityObject>>, which seemed unnecessarily complex. I cleaned these up so that we use Arc<dyn AuthorityObject> instead.
After we noticed that some tests against the Quad9 name servers kept causing issues in CI, I decided to kill the quad9 tests. We still run tests against Google and Cloudflare to help validate our code.
A user reported that the Cargo features for the server were pulling in OpenSSL even when that should be necessary. I submitted a PR to clean up server features which improved the situation.
While working on KumoMTA (see below), I noticed that RecordSet::new() took a &Name argument only to clone it. I changed it to take a Name directly so the caller can hand over ownership where possible.
Made some minor recursor tweaks.

I reviewed 25 PRs Hickory DNS last month, here are the more notable ones:

rustup

rustup is the tool most Rust developers to use manage their compiler toolchains; I joined the team last year after some of the previous members had left, reducing the available capacity. We're currently gearing up for the beta of rustup 1.28 which contains some larger changes, including:

No implicit toolchain installs
Default to rustls with the rustls-platform-verifier for downloads
Improved logging based on tracing-rs

In September I recruited Chris to the team. He had already been helping out a bunch with the Windows parts of rustup in particular, and we decided it made sense to ask him to join the team, which he happily agreed to.

Notable changes from last month:

We finally merged a contributed PR to replace winreg with windows registry, after we coordinated with the windows-rs team and Chris on the best way forward. This included scrapping some unsafe code from the rustup code base because we can now build on better upstream abstractions.
Improve the logging setup to better integrate tracing.

pyrtls

I launched a new project called pyrtls last month. pyrtls provides Python bindings to rustls, seeking to expand access to rustls' great performance and security track record as an alternative to the OpenSSL-based ssl module that is a part of the standard library.

I started working on this intermittently back in 2021 and finally decided to write up some documentation and "ship" it by announcing the project on social media. At the end of the month, it earned a mention in last month's issue of the Feisty Duck Cryptography and Security Newsletter. I was happy to receive my first contributed PR adding a typing stub a few days later.

Although the project has managed to earn 70 stars over the past 4 weeks, I've been a little disappointed with the lack of feedback so far. Given that I don't have a use case for this project myself (since I don't really use Python anymore), I probably won't spend much more time on it until there is some uptake.

KumoMTA

I've been doing some consulting work for KumoMTA, a startup building a mail transfer agent (MTA) for enterprise senders. I had connected with their cofounder Wez (of wezterm fame) through issues against rustls and Hickory (both of which KumoMTA uses to build their MTA).

My first issue was to build a Redis rate limiting implementation that doesn't use the redis-cell Redis extension. This integrated a Lua script-based implementation of the generic cell rate algorithm which can be used in deployments where custom Redis extensions are not viable.
Then, I started working on an implementation of the Sender Policy Framework (SPF) standard. This will be used in KumoMTA to help detect spam. Wez had already started on an implementation, so I picked up from where he had left off and started implementing the core protocol.
I noticed that the KumoMTA codebase was using both lazy-static and once_cell, so I decided to spend a little time (after getting approval from Wez, of course) cleaning this up and migrating the entire project to the newly available OnceLock and LazyLock types stabilized in 1.70.0 and 1.80.0.

Quinn

Quinn is the most popular Rust implementation of the QUIC transport protocol. Some interesting PRs I reviewed last month:

Enabling building quinn-proto for WASM targets from the folks at n0 computer, who are building Iroh on top of Quinn.
Faster UDP I/O on Apple platforms, from the Mozilla folks who are in the process of adopting quinn-udp for Firefox's UDP needs.

I also submitted some PRs of my own:

Fixed bookkeeping for datagrams in response to an issue.
Cleaned up some new clippy lints.
Avoided a potential panic in TLS server config setup.
Published 0.11.7 and 0.11.8 releases for quinn-proto and quinn. We also investigated a DoS vulnerability that was introduced in quinn-proto 0.11.0 and published a security advisory after 0.11.7 was released.
Published 0.5.5 for quinn-udp.

Askama

Askama is a compile-time template engine using a Jinja-like syntax.

Reviewed some changes to:

Fix include statements within block fragments.
Improve CI to run all tests and packages to completion even if some fail.
Accept a trailing comma in arrays.

I also:

Improved the error in case a Rust operator is used as a delimiter in a custom syntax, in response to an issue report.
Applied clippy suggestions from Rust 1.81 and fixed dependencies after a new version of Axum was published that uses tower 0.5.

I should really reserve some time to finish the 0.13 release.

tokio

I prepared a tokio-stream release to support some work I was doing in tonic to improve newly public API.
Although I am only peripherally involved with the tracing-rs project, I spent some time cleaning up all the warnings that had accumulated over time.
Reviewed a tracing-opentelemetry upgrade to opentelemetry 0.25 and published the 0.26.0 release.

instant-acme

instant-acme is a RFC 8555 client for provisioning TLS certificates.

Reviewed a contributed PR to avoid bad nonce errors which the Pebble test CA generates to exercise client code. As suggested by the spec, we now retry requests that trigger a bad nonce error a few times before giving up.

On sustainability

Although I have been reaching out to organizations that I'd hoped would be interested in funding this kind of work across the Rust ecosystem, so far I have not succeeded in finding any. Although I'm very grateful to my current sponsors, I'd like to find some companies that can help make my work more sustainable. Happy to get on a call to discuss how I could help out your team!

Many thanks to these sponsors (5 USD/month or more):

astral-sh
codecov
thomaseizinger
stepfunc
MJDSys
repi
sourcegraph
eightseventhreethree
paolobarbolini

Rust 2019: Ownership without fear

2019-01-01T00:00:00+01:00

Like last year, the Rust community team asked community members to write blog posts "proposing goals and directions for 2019"; this is mine. Like withoutboats' post and Niko Matsakis' take, this post will focus on organizational issues. As such, the "ownership" from the title refers to a leadership principle, not the technical type system concept we all know and love.

Finance without fear

I believe the Rust project must figure out how accept donations for the benefit of the Rust language, compiler and ecosystem. Whether this involves a new legal entity or not, we should use the corporate money on the table where it could enable the community to move the ecosystem faster than otherwise possible.

Even if other communities have run into trouble with this, the focus of the Rust project on positive-sum outcomes and careful involvement with the community should make it possible to come up with proposals that are widely supported. Things like improving the state or scope of CI, having a procedural macro book written or even building custom tooling might all be good ideas.

So far, the Rust project has preferred existing tools over building our own. However, I think we run into the limitations of this strategy both in the example of CI and in the limitations of GitHub issues for some of the more involved discussions. This is a classic build vs buy discussion -- if we consider CI and RFC discussions to be a "core business" of the Rust project, then it might make sense to invest in improving these parts of the project's process.

(Is "tooling without terror" too terrible a pun?)

Foundation without fear

Setting up a legal entity and governance structure for the Rust project appears to be a controversial topic in the Rust community. Of course, it could be a home within an existing foundation: joining Thunderbird under the umbrella of the Mozilla Foundation, or another entity like the Software Freedom Conservancy. I would like the increased transparency and accountability that might come with a more explicit setup where it concerns how the leadership of the project evolves.

Since it keeps coming up, it would be good to have an RFC about the foundation idea; to have a thorough conversation on the benefits and downsides. If the latter end up outweighing the former, the RFC can serve as negative space documentation (per Graydon) for everyone thinking about it.

In a different vein, I think PEP 8016 is worth exploring as a carefully considered alternative we could crib ideas from. As an experiment, we could have part of the core team be elected by a (large cross-section of) the community.

Asynchronous alignment

I think the Rust project could benefit from an increased sense of the direction of the project. While the language design and library evolution processes "just" some adjustments to the increased scale at which we're operating, other parts of how the project executes are not so well-defined, or happen in synchronous meetings that are opaque to the community. I'm used to open source projects where decision making happens exclusively in asynchronous venues, and the current way Rust teams and working groups function is quite different -- with a notable exception for the way the compiler team documents their work.

The yearly roadmap building effort is one great way of doing this, but the yearly cycle makes it a very coarse-grained check-in. One suggestion I've been thinking about is to have a community event (maybe with video?) every release cycle or two where a group of core team members answers crowd-sourced questions from the community (along the lines of an AMA or Google's TGIF event).

This could also help cut down on the "Why don't you just" and "Be Heard" sentiments that I've seen core project team members lament over the past year. I think those sentiments come from a feeling of powerlessness and being underinformed. In my mind, more deliberate and continuous communication about the state of the project could go a long way towards improving on this.

Careful conduct

Although I wholly support the code of conduct and appreciate many aspects of the way we interact online, there's some things that I think could be improved. While I've seen people expressing their personal frustration with a project decision get quickly moderated, I've also seen users who keep posting vague forum threads or exert significant stop energy on others' proposals. I wish we could be more openly critical of decisions (not people) while at the same time more strict towards net-negative participants.

On a more subtle note, I've felt that core project team members cast the community as an angry mob at times. Although I realize it is a big job, I think it's fair to ask project leaders to bring more empathy to the table in these cases -- to me, that is an important part of leadership. If a significant part of the community is up in arms about something, there likely is a kernel of truth to their argument, and the leadership should respond to the sentiment to prevent it from festering.

Update: interesting discussion on these topics on Reddit.

Taking the long view

To my taste, too much focus in 2018 was spent on releasing the edition. We could have spent more time addressing technical and organizational debt and released the edition 3 or 6 months later to little consequence. The Rust release process has been carefully engineered to optimize for cautious movement towards long-term goals -- and the edition process, in setting a fixed scope and an arbitrary hard deadline, subverted a number of these goals. This caused issues around the release of the website as well as problems with tools when 1.31 was released.

On the one hand, the cautious, deliberate approach to language design and compiler development have served us well, and will likely continue to do so. However, we should not forget that this process functions well in part due to an imposed feedback cycle that gives enough time and space for people to experiment before casting the new feature in (stable) stone per Hyrum's law. In a similar vein, we cannot expect to get our organizational changes right on the first try, and so we should not be afraid to experiment and iterate with the way the community works on the Rust project, rather than taking a long time to get it just right. This is especially true because the experiment period allows a wider community to participate and interact with the proposed change, thus reinforcing community alignment and improving feedback.

In this sense, we might learn from Jeff Bezos when he talks about a bias to action, saying that we should not spend too much time discussing decisions that are easy to change after the fact. For Rust, too, we want to remain at Day 1 for as long as we can -- let's remember the "without stagnation" part.

Contemplating Cargo

On a somewhat more technical note, I hope for more attention given to Cargo. While Cargo is a great tool in many ways, it also suffers from a number of usability cliffs where the behavior is hard to predict or understand. When I tried to contribute, I found that there's also a decent amount of technical debt, and my attempts to improve this through refactoring were met with such reluctance that I stopped contributing. From recent reports, it seems I'm not the only one.

Since Cargo is so central to the Rust experience, I think we should not undervalue it; as one example, the interactions between Cargo and rustc also influence the perception of those compile times people keep talking about. I was very happy to see the leadership changes and increase of the team's size, and I hope those changes will lead to further Cargo improvements this year.

Unused inventory, redux

Last year, I wrote at some length about the concept of unused inventory. This is still very much on my mind, and I was happy to see Niko talk about it in very similar terms. I hope we can improve things here.

Closing thoughts

I'm still as bullish on the Rust language as ever. Non-lexical lifetimes and the module system changes have made an already great language even better, async/await is going to be great. What I most want from Rust, though, is that more of the software in my life can enjoy its reliability and efficiency (in performance vs footprint), and for that we need adoption and sustainability. While the technical side of the project is working well, I've been concerned about the functioning of the project's governance and processes. A number of Rust 2019 posts have addressed similar concerns, which makes me hopeful for 2019.