OpenBSD's openrsync rewrites a 30-year-old file-sync tool from scratch—with security as the design goal

The team behind one of the most security-focused operating systems has built a clean-room rsync implementation. Here is what that means for the millions of systems that depend on the original.

Written by Iris Vale · Bureau Tech · May 30, 2026

A 30-year-old protocol gets a security-first rewrite

rsync—short for remote sync—is one of the most widely deployed file-transfer tools in computing. First released in 1996, it underpins backup systems, software mirrors, and deployment pipelines across millions of servers. Its longevity is also its liability: the reference implementation carries decades of accumulated complexity, and that complexity has historically been a source of vulnerabilities.

The OpenBSD project, known for shipping OpenSSH and for aggressive in-tree security auditing, has published openrsync: a clean-room reimplementation of the rsync protocol written entirely from scratch. The project is hosted on GitHub under the handle of Kristaps Dzonsons, one of the OpenBSD contributors.

What 'clean-room' means in practice

A clean-room implementation shares no source code with the original. That distinction matters for two reasons. First, it eliminates inherited bugs—vulnerabilities present in the original codebase cannot be copied in if the code itself is not copied. Second, it allows the authors to make different architectural choices, including privilege separation (splitting a program into components that run with minimal permissions) and strict input validation from the start.

OpenBSD has applied this approach before. OpenSSH, now the dominant SSH implementation globally, began as a security-focused fork and rewrite of the original SSH software. openrsync follows a similar philosophy.

What is known about the security posture

The openrsync repository documents its use of OpenBSD's pledge and unveil system calls—mechanisms that restrict what a running process is allowed to do and which file paths it can access. These are OS-level sandboxing primitives that limit the blast radius if a bug is exploited.

The codebase is substantially smaller than the reference rsync, which reduces the attack surface in a measurable way. Smaller, more auditable code is a core OpenBSD design value.

What is not yet known: openrsync has not been subjected to the same volume of independent third-party security research as the original rsync, simply because it is newer and less widely deployed. A fresh codebase can introduce novel bugs even as it eliminates inherited ones. Users should not assume that 'new and clean' equals 'bug-free.'

Deployment status and compatibility gaps

openrsync ships as the default rsync binary in OpenBSD. That is a meaningful signal—it is not a research prototype but production software used on a platform where security failures are taken seriously.

However, openrsync does not yet implement every feature of the original rsync. Organizations running complex rsync configurations—custom filter rules, specific compression options, or less common protocol flags—should test compatibility carefully before substituting openrsync in existing workflows. The project's README documents known limitations.

Why this matters beyond OpenBSD

The original rsync is used in contexts where a compromise could be severe: software distribution mirrors, automated backup systems, and CI/CD pipelines. Any implementation that reduces the risk of remote code execution or privilege escalation in those contexts is worth tracking.

For security teams doing supply-chain risk assessments, openrsync represents an alternative worth evaluating—particularly for environments already running OpenBSD or for new deployments where feature parity is not a constraint.

For everyone else, the project is a useful reminder that foundational Unix tools are not immutable. The rsync protocol can be reimplemented, and the OpenBSD team has demonstrated that doing so with security as the primary design goal is tractable.

Key takeaways

openrsync is a clean-room implementation of the rsync protocol, not a fork—it shares no code with the original tridge rsync.
The project is maintained by the OpenBSD team, which has a documented track record of proactive security auditing and privilege separation in system software.
openrsync ships as the default rsync binary in OpenBSD, meaning it is already in production use on a security-focused platform.
The original rsync codebase dates to the mid-1990s and has had multiple CVEs over its lifetime; a fresh implementation reduces inherited technical debt but introduces its own risk of novel bugs.
openrsync is not yet feature-complete relative to the original rsync, so organizations should verify compatibility before substituting it in existing pipelines.

FAQ

Is openrsync a drop-in replacement for rsync?

Not fully, as of current releases. openrsync implements the core rsync protocol and is compatible with the original rsync for common use cases, but it does not support every flag and feature of the reference implementation. Check the project's documentation for a current list of limitations before substituting it in production pipelines.

What is the difference between openrsync and the original rsync?

The original rsync, sometimes called tridge rsync after one of its authors, dates to 1996 and has been extended incrementally for decades. openrsync is a clean-room rewrite—no shared code—written by OpenBSD contributors with an emphasis on small codebase size, privilege separation, and use of OpenBSD-specific sandboxing primitives like pledge and unveil.

Has openrsync had any known security vulnerabilities?

No CVEs specific to openrsync are publicly documented at the time of writing. However, the project is newer and has received less independent security research than the original rsync. Absence of known vulnerabilities in a young codebase should not be read as a guarantee of security.

What is pledge and unveil, and why do they matter?

pledge and unveil are OpenBSD kernel system calls that allow a process to voluntarily restrict its own capabilities at runtime. pledge limits which categories of system calls a process can make; unveil limits which file paths it can access. If a bug is exploited in a program using these primitives, the attacker's ability to cause damage is constrained by the restrictions the program declared. They are a form of OS-enforced sandboxing.

Where can I find the openrsync source code?

The project is hosted on GitHub at https://github.com/kristapsdz/openrsync. It is also included in the OpenBSD base system source tree.

Citations

openrsync — GitHub repositoryopenrsync is a clean-room implementation of the rsync protocol by the OpenBSD team, shipping as the default rsync in OpenBSD
Hacker News discussion thread on openrsyncCommunity discussion surfaced via Hacker News as a research signal for this story
OpenBSD pledge(2) man pagepledge is an OpenBSD system call that restricts the system calls a process may make after invocation, used in openrsync for sandboxing
OpenBSD unveil(2) man pageunveil is an OpenBSD system call that restricts filesystem path visibility for a running process, used alongside pledge in openrsync
rsync project — original implementationThe reference rsync implementation, first released in 1996, is the software openrsync reimplements from scratch