It's not like the world needs yet another WireGuard tutorial,\nbut I thought I'd write one since one of the top SEO-ranked ones I stumbled upon was pretty low quality,\nwith several obvious errors and omissions.
\nIn this post, I'll focus on how you can set up a VPN tunnel\nin the sense that such things were used before shady companies hijacked the term.\nIt's just a way to tunnel traffic between networks.\nFor example, to connect non-internet-facing servers behind a firewall\nto a public host that firewalls and selectively routes traffic over the tunnel.
\nI'll assume a pair of FreeBSD servers for the rest of the post,\none that's presumably more accessible (the "server"),\nand a client which is not necessarily routable over the internet.
\nWe'll start with the server setup.\nThis is where your client(s) will connect.\nAt a high level, we'll generate a keypair for the server,\na keypair for the client,\nand generate configuration files for both.\nAnd finally we'll do some basic firewall configuration.
\nThe following can be run,\neither in a script or line-by-line in a POSIX shell as root.
\n# Set this to your server's public IP\nSERVER_PUBLIC_IP="192.0.2.42"\n\n# We'll be setting up some config files here that we only want to be readable by root.\n# The umask saves us the effort of having to chmod these later.\numask 077\n\n# Wireguard kernel-level support is available in FreeBSD 14+,\n# but this port has a nice service wrapper\npkg install wireguard-tools\n\n# Set up WireGuard config directory\nchmod 770 /usr/local/etc/wireguard\ncd /usr/local/etc/wireguard\n\n# Create a keypair for the server\nSERVER_PRIV_KEY=$(wg genkey)\nSERVER_PUB_KEY=`echo $SERVER_PRIV_KEY | wg pubkey`\n\n# Generate the first section of our WireGuard server config.\n# We'll use 172.16.0.1/24 (no real reason for the choice;\n# it's just somewhat convenient as it doesn't collide with the more common\n# Class A and Class C private networks).\ncat > wg0.conf <<EOF\n[Interface]\nAddress = 172.16.0.1/24\nSaveConfig = true\nListenPort = 51820\nPrivateKey = ${SERVER_PRIV_KEY}\nEOF\n\n# Similarly, we need a client keypair\nCLIENT_PRIV_KEY=$(wg genkey)\nCLIENT_PUB_KEY=`echo $CLIENT_PRIV_KEY | wg pubkey`\n\n# Add peer to the server config.\n# This is what lets your client connect later.\n# The server only stores the client's public key\n# and the private IP that it will connect as.\nCLIENT_IP="172.16.0.2"\ncat >> wg0.conf <<EOF\n# bsdcube\n[Peer]\nPublicKey = ${CLIENT_PUB_KEY}\nAllowedIps = ${CLIENT_IP}/32\nEOF\n\numask 022 # Revert to normal umask\n\n# Enable the wireguard service\nsysrc wireguard_interfaces="wg0"\nsysrc wireguard_enable="YES"\nservice wireguard start\nDon't ditch this shell session yet!\nWe'll come back to the client config later and will need the vars defined above.\nBut first, a brief interlude for packet filtering.
\npf setupWe'll use pf, the robust packet filtering (colloquially "firewall") system\nported from OpenBSD.
I'm using vtnet0 for the external interface,\nsince that's the interface name with my VPS vendor.\nYou may need to change this based on what your main network interface is\n(check ifconfig).
DISCLAIMER: This is not necessarily everything you need to launch a production system.\nI've distilled just the parts that are relevant to a minimal WireGuard setup.\nThat said, here's a minimal /etc/pf.conf.
ext_if = "vtnet0"\nwg_if = "wg0"\n\n# Pass all traffic on the loopback interface\nset skip on lo\n\n# Basic packet cleanup\nscrub in on $ext_if all fragment reassemble\n\n# Allows WireGuard clients to reach the internet.\n# I do not nede this in my config, but noting it here\n# in case your use case is *that* sort of VPN.\n# nat on $ext_if from $wg_if:network to any -> ($ext_if)\n\n# Allow all outbound connections\npass out keep state\n\n# SSH (there's a good chance you need this)\npass in on $ext_if proto tcp from any to ($ext_if) port 22\n\n# Allow inbound WireGuard traffic\npass in on $ext_if proto udp from any to ($ext_if) port 51820\n\n# TODO: Forwarding for the services that YOU need\n# Here's one example demonstrating how you would allow traffic\n# to route directly to one of the WireGuard network IPs (e.g. 172.16.42.1/24 in this example)\n# over port 8080.\n# pass in on $wg_if proto tcp from $wg_if:network to ($wg_if) port 8080\n\n# Allow ICMP\npass in inet proto icmp all\npass in inet6 proto icmp6 all\nNext, we enable the service and start it.\nIf you're already running pf, then at least part of this isn't necessary.
# Allow forwarding of traffic from from WireGuard clients\nsysctl net.inet.ip.forwarding=1\n\n# Enable pf\nsysrc pf_enable="YES"\nservice pf start\nAnd now we come back to the client configuration.\nThe "client" in this case does not necessarily have to be routable over the internet;\nit just needs to be able to connect to the server.\nYou've still got the same shell session with those variables, right?
\ncat <<EOF\n[Interface]\nPrivateKey = ${CLIENT_PRIV_KEY}\nAddress = ${CLIENT_IP}/24\n\n[Peer]\nPublicKey = ${SERVER_PUB_KEY}\nAllowedIPs = 172.16.0.0/24 # Only route private subnet traffic over the tunnel\nEndpoint = ${SERVER_PUBLIC_IP}:51820\nPersistentKeepalive = 30\nEOF\nThat's it; that's the client config.\nRun through the same initial setup steps for adding the wireguard-tools package\nand creating the directory with the right permissions.\nThen put this config in /usr/local/etc/wireguard/wg0.conf.
The client will also need a similar pf configuration,\nbut rather than blanket allowing traffic in over $wg_if,\nyou probably want something a bit more granular.\nFor example, allowing traffic in over a specific port (e.g. 8080).\nI'll leave that as an exercise to the reader based on the specific scenario.
I'm approximately 2 weeks into using emacs as my daily editor and, well, I haven't opened JetBrains since.\nI honestly didn't expect that, but here we are.
\nHere's the list of things I noted in my last post that I said I'd come back to.\nThe list has changed a bit since the last post:
\nSolved:
\nglobal-auto-revert-mode)Haven't bothered to try resolving (infrequently used):
\nThe highlighting one is worth a bit of explanation.\nHere's what I had to do to get it working:
\n;; Highlight mutable variables (like RustRover/JetBrains).\n;; NB: Requires eglot 1.20+\n(defface eglot-semantic-mutable\n '((t :underline t))\n "Face for mutable variables via semantic tokens.")\n\n(with-eval-after-load 'eglot\n (add-to-list 'eglot-semantic-token-modifiers "mutable"))\nApparently this requires a fairly recent version of eglot to work,\nand it isn't necessarily supported by every LSP,\nbut it works for me with rust-analyzer.\nI spent way too much time on this because for some reason running M-x eglot-reconnect\nor M-x eglot and accepting a restart didn't reset the buffer settings or something.\nIf this doesn't work, try killing the buffer and then find the file again.
Here's a similarly categorized list of things that I found over the past week or so.
\nSolved:
\n(setq tab-bar-mode t)! It's great.\nIt's even better than I expected TBH since every tab can contain an arbitrary configuration of buffers.\nThis is a weird way of thinking at first, but it's really nice since stuff doesn't need to follow the traditional bounds\nthat I was used to in IDEs (e.g. a tab can be entirely terminal buffers, or cross "projects" which is useful to me).xref-matches-in-files was SLOW. Turned out to be an issue in my fish configuration (which isn't even my "preferred" shell,\nbut it's still my login shell due to being more supported than nushell, which I use for most things).\nRemoving pyenv fixed that.\nAlso you can set it to use ripgrep with (setq xref-search-program 'ripgrep)C-x p f (mnemonic: project find).consult-eglot package.\nSpecifically, it includes a consult-eglot-symbols command.Not solved yet:
\ndiff-hl package doesn't get the hint when files reload for some reason.I'll also add a quick note that it's (still) surprisingly easy to screw up your own config.\nEmacs as a system is super flexible but that also makes it somewhat fragile.\nEverything is programmable, in a single-threaded, garbage-collected language.
\nOne snag I hit was that after some period, the environment got super slow,\naffecting things like unit test runtimes in terminal buffers,\nand making input noticeably laggy.\nThe issue turned out to be my global-auto-revert-mode config.\nApparently if you do it wrong, it turns into a whole stack of polling operations for every buffer.\nThis was a consequence of Claude suggesting something dumb and me not researching it :P\nThe normal configuration will use filesystem notifications like kqueue or inotify.
I'm pretty happy with the new setup overall.\nObviously some room for tweaks, but it's pretty great overall,\nand I'm really enjoying the tab bar approach for organizing things.\nI'm also frankly shocked at how little CPU I'm using relative to previous norms on my MacBook.
\nNext up I'll probably try (in no particular order):
\nI have been a fan of JetBrains products for over a decade by now,\nand an unapologetic lover of IDEs generally.\nI've used PyCharm since shortly after it launched,\nand over the years I've used IntelliJ IDEA,\nWebStorm, DataGrip, RustRover, and more.\nI literally have the all products pack (and have for many years).
\nI truly believe that a good IDE can be a productivity multiplier.\nYou get refactoring, jump-to-definition, symbol-aware search,\nsaved build/run configurations, a nice and consistent interface\nto otherwise terrible tooling (looking at you CMake and the half dozen Python package managers\nof the last decade and change).
\nBut something has changed over the past few years.\nThe quality of the product has generally deteriorated in several ways.\nWith the advent of LSP, the massive lead JetBrains had in "code intelligence"\nhas eroded, and in many cases no longer exists.\nThe resource requirements of the IDE have also ballooned massively,\neven occasionally causing memory pressure on my amply equipped MacBook Pro with 32GB of RAM.
\n(Side note: I regularly have 3 JetBrains IDEs open at once because I need to work in many languages,\nand for some reason they refuse to ship a single product that does that.\nI would have paid for such a product.)
\nAnd as if that weren't enough, it seems like I have to restart to install some urgent nagging update\nseveral times/week, usually related to one of their confusing mess of AI plugins\n(is AI Chat what we're supposed to use? Or Junie? Or... what?).\nTo top it all off, stability has gone out the window.\nAt least once/week, I will open my laptop from sleep,\nonly to find out that one or more of my JetBrains IDEs has crashed.\nUsually RustRover.\nWhich also eats up like 30GB of extra disk space for things like macro expansions\nand other code analysis.\nThe taxes are high and increasing on every front.
\nSo, I decided the time was right to give Emacs another shot.
\nIf you know me personally, you may recall that I made some strong statements in the past\nto the effect that spending weeks writing thousands of lines of Lua to get the ultimate Neovim config was silly.\nAnd my strongly worded statements of the past were partially based on my own experiences with such editors,\nincluding Emacs.\nBasically, I appreciate that you can "build your own lightsaber",\nbut I did not consider that to be a good use of my time.\nOne of the reasons I like(d) JetBrains is that I didn't ever need to think about tweaking configs!
\nBut things have gotten so bad that I figured I'd give it a shot with a few stipulations.
\nWith these constraints, I set off to see if I needed to revise my philosophy of editors.
\nAside: why not (Helix|Neovim|Zed|something else)?\nA few reasons, in no particular order:
\nSo, how's it going so far?\nHere are a few of the highlights.
\nIt used to be the case that JetBrains had a dominant position in code analysis.\nThis isn't the case anymore, and most of the languages I use that would benefit from an LSP\nhave a great one available.\nThings have improved a lot, particularly in terms of Emacs integrations,\nover the past decade!\neglot is now bundled with Emacs,\nso you don't even need to go out of your way to get some funky packages hooked up\n(like I had to with some flycheck plugin for Haskell back in the day).
The LSP-guided tools for refactoring have also improved a lot.\nIt used to be that only a "real IDE" had much better than grep and replace.\nI was happy to find that eglot-rename "just worked".
I'm used to hovering my mouse over any bit of code, waiting a few seconds,\nand being greeted by a docs popover.\nThis is now possible in Emacs too with eldoc + your LSP.\nI added the eldoc-box plugin and configured it to my liking.
So far, every single quick-fix action that I'm used to in RustRover\nseems to be there in the eglot integration with rust-analyzer.\nIt took me a few minutes to realize that this was called eglot-code-actions),\nbut once I figured that out, I was rolling.
I frequently use the jump-to-definition feature in IDEs.\nUsually by command+clicking.\nYou can do the same in Emacs with M-., which is a bit weird, but okay.\nI picked up the muscle memory after less than an hour.\nThe weird thing though is what happens next.\nI'm used to JetBrains and most other well-designed software (glares in the general direction of Apple)\n"just working" with the forward+back buttons that many input devices have.\nEmacs did not out of the box.
One thing JetBrains did fairly well was bookmarking where you were in a file, and even letting you jump back after\nnavigating to the definition or to another file.\nThis had some annoying side effects with multiple tabs, which I won't get into but it worked overall.\nIn Emacs, you can return from a definition jump with M-,, but there is no general navigate forward/backward concept.\nThis is where the build-your-own-lightsaber philosophy comes in I guess.\nI knew I'd hit it eventually.
I tried out a package called better-jumper but it didn't immediately do what I wanted,\nso I abandoned it.\nI opted instead to simple backward and forward navigation.\nIt works alright.
(global-set-key (kbd "<mouse-3>") #'previous-buffer)\n(global-set-key (kbd "<mouse-4>") #'next-buffer)\nAside: I had to use C-h k (describe-key) to figure out what the mouse buttons were.\nAdvice I saw online apparently isn't universally applicable,\nand Xorg, macOS, etc. may number the buttons differently!
The emacs shell mode is terrible.\nIt's particularly unusable if you're running any sort of TUI application.\nA friend recommended eat as an alternative.\nThis worked pretty well out of the box with most things,\nbut when I ran cargo nextest for the first time,\nI was shocked at how slow it was.\nMy test suite which normally runs in under a second took over 30!\nYikes.\nI believe the slowness is because it's implemented in elisp,\nwhich is still pretty slow even when native compilation is enabled.
Another Emacs user recommended I try out vterm, so I did.\nHallelujah!\nIt's no iTerm 2, and it does have a few quirks,\nbut it's quite usable and MUCH faster.\nIt also works better with full-screen TUI apps like Claude Code.
I'm not going to get into the pros and cons of LLMs in this post.\nBut if you use these tools in your work,\nI think you'll be surprised by how good the experience is with vterm and the claude CLI.\nI have been evaluating JetBrains' disjoint attempts at integrations with Junie,\nand more recently Claude Code and Codex.
Junie is alright for some things.\nThe only really good thing I have to say about the product is that at least it let me select a GPT model.\nAnthropic models have been severely hampered in their ability to do anything useful in most codebases I work in,\ndue to tiny context windows.\nThat recently changed when Anthropic rolled out a 1 million token context window to certain users.
\nJetBrains confusingly refers to Claude Code as "Claude Agent" and team subscriptions automatically include some monthly credits.\nEvery single JetBrains IDE will install its own separate copy of Claude Code (yay).\nBut it is really just shelling out to Claude Code it seems\n(it asks for your permission to download the binary.\nCodex is the same.)
\nGiven this, I assumed the experience and overall quality would be similar.\nWell, I was VERY wrong there.\nClaude Code in the terminal is far superior for a number of reasons.\nNot just access to the new model though that helps.\nYou can also configure "effort" (lol), and the "plan" mode seems to be far more sophisticated than what you get in the JetBrains IDEs.
\nSo yeah, if you're going to use these tools, just use the official app.\nIt makes sense; they have an incentive to push people to buy direct.\nAnd it so happens that Claude Code fits comfortably in my Emacs environment.
\nMore directly relevant to this post,\nLLMs (any of them really) are excellent at recommending Emacs packages and config tweaks.\nSo it's never been easier to give it a try.\nI've spent something like 2-3x longer writing this post than I did configuring Emacs.\n(And yes, before you ask, this post is 100% hand-written.)\nMy basic flow was to work, get annoyed (thats pretty easy for me),\nand describe my problem to ChatGPT or Claude.\nI am nowhere near the hours I budgeted for config fiddling.\nThat surprised me!
\nWhile I'm no stranger to hacking around with nothing more than a console,\nI really don't like the git CLI.\nI've heard jj is better, but honestly I think GUIs are pretty great most of the time.\nI will probably try magit at some point,\nbut for now I'm very happy with Sublime Merge.
\nBut one thing I MUST have in my editor is a "gutter" view of lines that are new/changed,\nand a way to get a quick inline diff.\nJetBrains had a great UX for this which I used daily.\nAnd for Emacs, I found something just as great: diff-hl.
My config for this is very simple:
\n(unless (package-installed-p 'diff-hl)\n (package-install 'diff-hl))\n(use-package diff-hl\n :config\n (global-diff-hl-mode))\nTo get a quick diff of a section that's changed,\nI use diff-hl-show-chunk.\nI might even like the hunk review experience here better than in JetBrains!
I think JetBrains has the best search around with their double-shift, cmd+shift+o, and cmd-shift-f views.\nI have not yet gotten my Emacs configured to be as good.\nBut C-x p g (project-find-regexp) is pretty close.\nI'll look into other plugins later for fuzzy filename/symbol search.\nI do miss that.
The final pleasant surprise is that I don't miss JetBrains run configurations as much as I expected.\nI instead switch to putting a justfile in my repo and populating that with my run configurations\n(much of the software I work on has half a dozen switches which vary by environment).\nThis also has the side effect of cleaning up some of my CI configuration (just run the same thing!)\nand also serves as useful documentation to LLMs.
I have typos configured for most of my projects in CI,\nbut it drives me nuts when an editor doesn't flag typos for me.\nJetBrains did this well.\nEmacs has nothing out of the box (Zed also annoyingly doesn't ship with anything, which is really confusing to me).\nBut it's easy to add.
I went with Jinx.\nThere are other options, but this one seemed pretty modern and worked without any fuss, so I stuck with it.
\nThis is all a lot more positive than I was expecting to be honest!\nI am not going to cancel my JetBrains subscription tomorrow;\nthey still do make the best database tool I know of.\nBut I've moved all my daily editing to Emacs.
\nThat said, there are still some papercuts I need to address:
\neglot-x which I'll look into later.cargo fmt)!mut variables. I would love to get that back in Emacs.이제 漢字 쓰는 方法을 알게 되었다!
\nI was today years old when I finally figured out how to type Hanja (characters from China that were historically used to write Korean).\nIt struck me as very strange that this didn't seem possible in any of the obvious input methods.\nIn Japanese, for example, you get search-as-you-type style suggestions popping up as you type,\nwhether in Kana or Romaji mode.\nIn fact, until now, I mostly relied on my prior study of Japanese,\nswitched to that layout, and typed in a Japanese reading.\nThis was quite clunky though as I am now learning the Korean readings.
\nI even asked several Koreans if they knew how,\nand none did (at least for macOS), since it's relatively uncommon to use them these days,\nparticularly for younger people.\nWindows keyboards have a dedicated Hanja mode key,\nbut I've never seen an Apple keyboard with this,\nand I'm not even totally sure if macOS understands the key code\n(if anyone knows, let me know on Mastodon).
\nIt turns out this IS in fact possible; it's just uncharacteristically buried.\nThe trick is to press option+return.\nThen you'll get a menu where you can select Hanja matches\nfor the previous "word" (it seems to rely on spacing, which is not always completely consistent in colloquial writing,\nbut it's not too hard to get used to.)\nI found tip on Apple's website\nvia a search.
\nThis is probably only relevant to like 2 other people on the internet, but I thought I'd spread the word\nsince it was relatively hard to find!
\n", "summary": "", "date_published": "2026-03-07T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "macos", "i18n", "korean", "languages" ], "language": "en" }, { "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!
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.
\ntls_certs_merge.tls_certs_only\nto limit verification to only the certificates you specify.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. ¯\\_(ツ)_/¯
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.
Previously I had seen this solved in two ways.\nThe first is to install the certs from your distribution's package manager like so:
\nRUN apt-get update \\\n && apt-get install -y --no-install-recommends ca-certificates \\\n && rm -rf /var/lib/apt/lists/*\nThe 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).
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.
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\nThis 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
\nrustls-platform-verifier. This has the additional benefit of supporting OS provided CA constraints and revocation data.
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."
\nSo 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.
\nMy 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.
\nIn 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.
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.
\nIn 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.
\nHope 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" }, { "id": "https://ianwwagner.com//even-safer-rust-with-miri.html", "url": "https://ianwwagner.com//even-safer-rust-with-miri.html", "title": "Even Safer Rust with Miri", "content_html": "Recently some of the Miri contributors published a paper that was accepted to POPL.\nI've been using Rust professionally for about 7 years now,\nand while I'd heard of Miri several times over the years,\nI think there's a wide lack of knowledge about what it does, and why anyone should care.\nI only recently started using it myself, so I'm writing this post to share\nwhat Miri is, why you should care, and how you can get started easily.
\nMiri is an interpreter for Rust's mid-level intermediate representation (MIR; hence the acronym).\nThat's how I first remember seeing it described years ago,\nand that's what the GitHub project description still says.
\nThe latest README is a bit more helpful though: it's a tool for detecting undefined behavior (UB) in Rust code.\nIn other words, it helps you identify code that's unsafe or unsound.\nWhile it would be a bug to hit such behaviors in safe Rust,\nif you're using unsafe (or any of your dependency chain does!),\nthen this is a real concern!\nMiri has in fact even found soundness bugs in the Rust standard library,\nso even a transitive sort of #![forbid(unsafe_code)] won't help you.
I think to understand why Miri matters,\nwe first need to understand why UB is bad.\nThis is not something that most professional programmers have a great understanding of (myself included).
\nIn abstract, UB can mean "anything that isn't specified", or something like that...\nBut that's not very helpful!\nAnd it doesn't really explain the stakes if we don't avoid it.\nThe Rust Reference has a list\nof behaviors that are considered to be undefined in Rust,\nbut they note that this list is not exhaustive.
\nWhen searching for a better understanding,\nI've seen people online make statements like\n"UB means your program can do literally anything at this point, like launch nuclear missiles."\nWhile this is technically true, this isn't particularly helpful to most readers.\nI want something more concrete...
\nThe authors of the paper put UB's consequences in terms which really "clicked" for me\nusing a logical equivalence, which I'll quote here:
\n\n\nFurthermore, Undefined Behavior is a massive security problem. Around 70% of critical security vulnerabilities are caused by memory safety violations [38, 18, 32], and all of these memory safety violations are instances of Undefined Behavior. After all, if the attacker overflows a buffer to eventually execute their own code, this is not something that the program does because the C or C++ specification says so—the specification just says that doing out-of-bounds writes (or overwriting the vtable, or calling a function pointer that does not actually point to a function, or doing any of the other typical first steps of an exploit chain) is Undefined Behavior, and executing the attacker’s code is just how Undefined Behavior happens to play out in this particular case.
\n
I never made this connection on my own.\nI equate UB most often with things like data races between threads,\nwhere you can have unexpected update visibility without atomics or locks.\nOr maybe torn reads of shared memory that's not properly synchronized.\nBut this is a new way of looking at it that makes the stakes more clear,\nespecially if you're doing anything with pointers.
\nAnother connection I never made previously is that UB is relative to a very specific context.\nHere's another quote from the paper:
\n\n\nThe standard random number crate used across the Rust ecosystem performed an unaligned memory access. Interestingly, the programmers seemed to have been aware that alignment is a problem in this case: there were dedicated code paths for x86 and for other architectures. Other architectures used read_unaligned, but the x86 code path had a comment saying that x86 allows unaligned reads, so we do not need to use this (potentially slower) operation. Unfortunately, this is a misconception: even though x86 allows unaligned accesses, Rust does not, no matter the target architecture—and this can be relevant for optimizations.
\n
This is REALLY interesting to me!\nIt makes sense in retrospect, but it's not exactly obvious.\nLanguages are free to define their own semantics in addition to or independently of hardware.\nI suspect Rust's specification here is somehow related to its concept of allocations\n(which the paper goes into more detail about).
\nIt is obviously not "undefined" what the hardware will do when given a sequence of instructions.\nBut it is undefined in Rust, which controls how those instructions are generated.\nAnd here the Rust Reference is explicit in calling this UB.\n(NOTE: I don't actually know what the "failure modes" are here, but you can imagine they could be very bad\nsince it could enable the compiler to make a bad assumption that leads to a program correctness or memory safety vulnerability.)
\nI actually encountered the same confusion re: what the CPU guarantees vs what Rust guarantees for unaligned reads in one of my own projects,\nas a previous version of this function didn't account for alignment.\nI addressed the issue by using the native zerocopy U32 type,\nwhich is something I'd have needed to do anyways to ensure correctness regardless of CPU endianness.\n(If you need to do something like this at a lower level for some reason, there's a read_unaligned function in std::ptr).
TL;DR - UB is both a correctness and a security issue, so it's really bad!
\nOne of the reasons I write pretty much everything that I can in Rust is because\nit naturally results in more correct and maintainable software.\nThis is a result of the language guarantees of safe Rust,\nthe powerful type system,\nand the whole ecosystem of excellent tooling.\nIt's a real pit of success situation.
\nWhile you can run a program under Miri as a one-shot test,\nthis isn't a practical approach to ensuring correctness long-term.\nMiri is a complementary tool to existing things that you should be doing already.\nAutomated testing is the most obvious one,\nbut fuzzing and other strategies may also be relevant for you.
\nIf you're already running automated tests in CI, adding Miri is easy.\nHere's an example of how I use it in GitHub actions:
\nsteps:\n - uses: actions/checkout@v4\n - uses: taiki-e/install-action@nextest\n\n - name: Build workspace\n run: cargo build --verbose\n\n - name: Run tests\n run: cargo nextest run --no-fail-fast\n\n - name: Run doc tests (not currently supported by nextest https://github.com/nextest-rs/nextest/issues/16)\n run: cargo test --doc\n\n - name: Install big-endian toolchain (s390x)\n run: rustup target add s390x-unknown-linux-gnu\n\n - name: Install s390x cross toolchain and QEMU (Ubuntu only)\n run: sudo apt-get update && sudo apt-get install -y gcc-s390x-linux-gnu g++-s390x-linux-gnu libc6-dev-s390x-cross qemu-user-static\n\n - name: Run tests (big-endian s390x)\n run: cargo nextest run --no-fail-fast --target s390x-unknown-linux-gnu\n\n - name: Install Miri\n run: rustup +nightly component add miri\n\n - name: Run tests in Miri\n run: cargo +nightly miri nextest run --no-fail-fast\n env:\n RUST_BACKTRACE: 1\n MIRIFLAGS: -Zmiri-disable-isolation\n\n - name: Run doc tests in Miri\n run: cargo +nightly miri test --doc\n env:\n RUST_BACKTRACE: 1\n MIRIFLAGS: -Zmiri-disable-isolation\n\n - name: Install nightly big-endian toolchain (s390x)\n run: rustup +nightly target add s390x-unknown-linux-gnu\n\n - name: Run tests in Miri (big-endian s390x)\n run: cargo +nightly miri nextest run --no-fail-fast --target s390x-unknown-linux-gnu\n env:\n RUST_BACKTRACE: 1\n MIRIFLAGS: -Zmiri-disable-isolation\nI know that's a bit longer than what you'll find in the README,\nbut I wanted to highlight my usage in a more complex codebase\nsince these examples are less common.\n(NOTE: I assume an Ubuntu runner here, since Linux has the best support for Miri right now.)\nSome things to highlight:
\nMIRIFLAGS to disable host isolation for my tests, since they require direct filesystem access. You may not need this for your project, but I do for mine.s390x-unknown-linux-gnu is the "big-endian target of choice" from the Miri authors. This requires a few dependencies and flags.Hopefully you learned something from this post.\nI'm pretty sure I wrote my first line of unsafe Rust less than a year ago\n(after using it professionally for over 6 years prior),\nso even if you don't need this today, file it away for later.\nAs I said at the start, I'm still not an expert,\nso if you spot any errors, please reach out to me on Mastodon!
\n", "summary": "", "date_published": "2026-01-07T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "rust", "software-reliability" ], "language": "en" }, { "id": "https://ianwwagner.com//2025-in-review.html", "url": "https://ianwwagner.com//2025-in-review.html", "title": "2025 in Review", "content_html": "I have never done one of these kinds of public posts, but saw a few from friends so I thought it might be useful!
\nThis year I was simultaneously more focused on my technical craft than ever,\nbut also had more of a "life" than ever.\nI took more random days off to go chill with friends, go skiing, etc.,\nand had more time with family.
\nIt is probably also one of the darkest years in world history as a whole.\nThe worst humanitarian abuses in a century continue,\nencouraged and perpetrated by what is supposed to be the "free world."\nBut enough ink has already been spilled on that and you don't need to hear it from me.\nAnd South Korean politics show that you DO have a voice.\nSo make it heard, and let's focus on the good stuff.
\nI also traveled more than any year since COVID.\nIn addition to my annual pilgrimage to Latitude59 in Tallinn,\nother highlights were going to Hong Kong for Rust Asia\nand London for Anjunadeep Open Air.
\nSurprisingly, this was my first time to visit the UK,\nand I have to say London is one of the few other cities I could actually see myself living in.\nDespite its flaws, London had a charming atmosphere,\namazing public spaces, loads of greenery,\ngreat food and drink (I don't really get the hate... I thoroughly enjoyed all of my meals),\nand well-functioning public transportation.\nOverall it was a very "livable" city to me,\nand joins Tallinn and Seoul as one of the few places I'd really enjoy living.
\n2025 was a great year for musical experiences.\nHere are a few of my highlights of the year (in no particular order)\nwhich get regularly stuck in my head:
\nBesides all the great albums and mixes,\nI enjoyed more live shows than I have in a very long time (probably since 2015 or so).\nThe club nights and live bands in Tallinn were as amazing as ever.\nI got extremely lucky with tickets to a sold-out Fred Again tour show just 15 mins from home.\nThat was probably the best live show I've ever seen; absolutely incredible production and musical talent!\nAnd Anjunadeep Open Air was great.
\n2025 also saw me get back into creating music for fun.\nI hadn't made much time for this in the past decade,\nbut the time felt right.\nI bought myself an Ableton Push,\nand will probably upload something on SoundCloud at some point.\nOr not.\nI'm making music for me, for fun.\nI wish I could do house parties where I'm just jamming,\nbut that probably won't happen in a Korean apartment anytime soon.
\nI initially used "conferences" as a section heading,\nbut it struck me that the reason I go to conferences,\nmeetups, coworking, and online forums is the same: community.
\nAs I do basically every year, I went to Latitude59 in May\nfor the community gatherings.\nIt was a great time, and I got an early look at how AI agents were being adopted.
\nThe other international conference I attended was Rust Asia in Hong Kong.\nWhat a cool and diverse group of people!\nIt was also great to be back in Hong Kong again for the first time in quite a few years.\nI really hope they do the conference again in 2026.
\nI also got to attend two local conferences late in the year: FOSS for All, and FOSS4G Korea.\nBoth conferences wouldn't have been on my radar if not for some friends being involved organizing them.
\nFOSS for All is also a new conference, and the first edition was a huge success.\nIt was far more international than I expected for a Korean conference,\nand a model for running a properly international, bilingual conference.\nI was somewhat surprised that I gave the only talk with a heavy focus on Rust.\nAnd I was pleasantly surprised to see how much of the Korean FOSS community is active on Mastodon.\nI think I tripled the amount of Koreans I follow in an afternoon.
\nIt was also a surprisingly good value for my company as a sponsor.\nI had something like 20 serious conversations with people at our table,\nwhich was something I didn't really expect (the conference was maybe 200 attendees)!\nI'll definitely be back next year.
\nFOSS4G Korea was also surprisingly great!\nI think I was the only non-Asian there; a few dedicated people flew in from Japan, which was awesome!\nAI was definitely a theme, and it wasn't the sort of slop generating 10x "productivity" sort of narrative.\nThe talks were overall even more interesting than I had expected; better than the last international FOSS4G I attended!\nThis was also the first time I fully participated in a conference conducted in another language.\nI'm setting a goal to give a talk in Korean next time.
\nAnd speaking of international FOSS4G, it seems the next edition will also be close by\nin Hiroshima!\nI'm very excited to go, after several years of them being quite far away.\nGuess I need to start working on my talk proposals ;)
\nMeetup-wise, I took over hosting the Seoul Rust meetup this year, and we did a lot more events than any year since COVID.\nWe've had some great talks, and even started a YouTube channel,\nwhere we'll post recordings of talks in the future (provided that the speaker is OK with it).\nI also gave two talks at the Seoul iOS Meetup: one on Ferrostar, and another on Apple's new Foundation models.\nThe iOS meetup also spawned a new, more general meetup called Dev Korea,\nwhich is growing really fast and has a great community on Discord!
\nI read a lot last year!\nI finally finished reading Dragonball in Korean.\nI had never read / watch the series before (because I grew up in relatively rural America without cable TV),\nbut it came highly recommended.\nYou can read about that in my other post.
\nHere are some other things that I read + highly recommend:
\nI probably talk about this enough elsewhere, but it was a really fun year work-wise, and we grew a lot too!
\nFerrostar started as one of those audacious ideas which I just couldn't resist trying.\nIt's now a healthy open-source project with weekly meetings of the core contributors,\nover 300 stars on GitHub, and 56(!!) forks.\nI think it's pretty safe to say that it's now regarded as the first choice\nunless you want to pay Google millions of dollars, or have an extremely simple use case.\nIt's being adopted by large companies in the space,\nwe're benefiting from contributions back upstream,\nand we're getting new business as a result.
\nI'm pretty proud of this as I think it's an example of how open source can balance\ncommunity, collaboration, and sustainability.\nThat last 2 points is worth emphasizing.\nAll of the core contributors are working in a professional capacity,\nand find it valuable to work together on a shared foundation.
\nThe other big achievement that I haven't written as much about is rewriting our geocoder,\nmore or less from scratch, in a matter of months.\nYou've probably heard of the second-system syndrome.\nThe popular trope these days is for engineers to take something that works but is clunky / limited,\nand decide to rewrite it (maybe in Rust, like me 🤣), and never ship, or ship VERY late due to feature creep\nand wanting to get everything perfect.\nI'm definitely guilty of being a perfectionist, but I also believe you can get there gradually while shipping something valuable quickly.
\nI approached this rewrite with a clear set of things that I wanted to change,\nand focused almost all of the time initially on getting the foundations right,\nwhich would let me replace the higher layers in a more "agile" way\n(in the sense of the normal use of the word, not a specific methodology).\nIt worked.\nWithin a few months, I had replaced the existing API layer with a new one,\nwhich was serving 99% of our traffic.\nWe didn't have any downtime, and I'm only aware of one accidental breaking change.\nThis is a result of careful testing, including snapshot testing at several levels (using the insta crate),\nand oracle testing (simple Python scripts in this case which hit the current and next gen APIs and flagged any differences).
There will always be more improvements to make, but what's important is that we shipped,\nand we have a solid foundation to build from here.\nAnd not just that, we also have a v2 API with a bunch of improvements.\nAnd since the new API system is serving all the traffic,\nwe even get to backport a lot of the improvements to v1!\nIn fact, we have zero plans of deprecating our v1 API, since the internals are shared,\nand we can continue improving it within the limits of that API contract.\nThis is an engineering achievement I'm really proud of.
\nI don't do new years resolutions per se,\nbut I expect to work at a slightly less crazy pace,\nand make more time side projects like music and non-work-related tech.\nI've also decided on my next Korean reading series: Neon Genesis Evangelion.\nI'm currently on volume 5, and expect to finish that this year.
\n", "summary": "", "date_published": "2026-01-03T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "reflections" ], "language": "en" } ] }