Keeping OpenBSD Up to Date with syspatch

OpenBSD, like FreeBSD, separates updating the base system from updating installed packages. Package updates go through pkg_add -u, which we covered in installing packages with pkg_add. This post covers the other half: syspatch, OpenBSD’s tool for applying binary security patches to the base system itself.

What syspatch does – and doesn’t do

syspatch applies official, pre-compiled binary patches to base system files – the kernel and core userland utilities that ship as part of OpenBSD itself. These patches are strictly security fixes and reliability corrections that the OpenBSD team has decided are important enough to backport to your current release, and nothing else. Feature changes, new functionality, and anything that isn’t a fix don’t go through syspatch – they wait for the next release.

That last point matters: syspatch only ever patches you within the release you’re already running. If you’re on OpenBSD 7.8, syspatch will keep 7.8 current with 7.8’s security fixes, but it will never turn your system into OpenBSD 7.9. Moving between releases is a separate process handled by sysupgrade, which is out of scope for this post – just know that it exists and that you’ll need it eventually, since syspatch alone won’t carry you forward indefinitely.

Why this still matters given OpenBSD’s release cycle

OpenBSD ships a new release roughly every six months, as we explained in what is OpenBSD and why is it considered one of the most secure OSes. syspatch is what keeps you secure in the gaps between those releases – it’s not a substitute for eventually upgrading. A reasonable approach on a production server is: run syspatch regularly to stay current within your release, and plan a sysupgrade when a new release ships, rather than letting your installation drift multiple releases behind.

Applying patches

Run syspatch with no arguments, as root, to apply everything currently available for your release:

syspatch

It checks the official patch server, downloads anything you’re missing, verifies signatures, and installs the patches in order. If a patch touches the kernel, syspatch will tell you a reboot is required to run the patched kernel – the same underlying principle as most binary patch systems: the files on disk are updated immediately, but a running kernel stays as it was until you restart.

shutdown -r now

If nothing is available, syspatch will simply report that your system is already up to date – that’s expected and not an error.

Listing applied patches

To see what’s already been applied to your system, use -l:

syspatch -l

This lists the patches currently installed, which is useful both for auditing what state a server is in and for confirming a patch run actually took effect.

Rolling back a patch

If a patch causes a problem, syspatch keeps the files it replaced so you can revert. Use -r to roll back the most recently installed patch:

syspatch -r

This only reverts the single most recent patch, not everything you’ve ever applied – if you need to go back further, you’d run it again for the next most recent, and so on. As with applying patches, if the reverted patch touched the kernel, you’ll need to reboot for the rollback to take effect.

A sensible routine

• Run syspatch periodically (many admins check weekly, or wire it into a scheduled task) to stay current with security fixes for your release.
• Reboot promptly when a kernel patch is applied – don’t leave a patched-on-disk-but-unpatched-in-memory kernel running for weeks.
• Keep pkg_add -u as a separate, regular habit for your installed packages – syspatch won’t touch them.
• Track OpenBSD’s roughly six-month release cadence and plan a sysupgrade when a new release ships, rather than relying on syspatch to carry an old release indefinitely.

Summary

syspatch is OpenBSD’s straightforward, no-drama tool for applying official security and reliability patches to the base system within your current release – syspatch to apply, syspatch -l to see what’s installed, syspatch -r to back out the last one. It’s not an upgrade path between releases; that’s what sysupgrade is for. Used together with regular pkg_add -u runs and an eye on OpenBSD’s release cycle, it’s most of what you need to keep a production OpenBSD server secure.