Openrsync: OpenBSD's Lean, Secure Implementation of the Rsync Protocol

For decades, rsync has been the gold standard for efficient file synchronization, utilizing a sophisticated delta-transfer algorithm to minimize data movement. However, as software ages, codebases can grow complex, and licensing can become a constraint for certain operating system vendors. Enter openrsync, a clean-room implementation of the rsync protocol developed by the OpenBSD team.

Originally created as part of the rpki-client(1) project—an RPKI validator for OpenBSD funded by organizations like NetNod and SUNET—openrsync has since been merged into the OpenBSD base system. It provides a BSD-licensed (ISC) alternative that is compatible with modern rsync (specifically protocol 27), offering a streamlined approach to file synchronization with a heavy emphasis on security and code maintainability.

The Core Algorithm: How openrsync Works

At its heart, openrsync remains faithful to the original rsync algorithm described by Andrew Tridgell and Paul Mackerras. The process is divided between a sender (managing source files) and a receiver (managing the destination).

The Block Exchange

The efficiency of the tool relies on the "block exchange" mechanism. For regular files, the process follows these steps:

  1. Hashing: The receiver divides the existing file into fixed-size blocks. Each block is hashed twice: first with a fast Adler-32 type 4-byte hash, and then with a slower MD4 16-byte hash.
  2. Matching: The receiver sends these hashes to the sender. The sender scans its version of the file, computing fast hashes on the fly. When a match is found, it verifies it with the slow hash.
  3. Reconstitution: The sender transmits only the data that differs from the receiver's blocks, along with identifiers for the blocks the receiver already possesses. The receiver then reconstructs the file using this stream of bytes and its own local blocks.

Block Size Optimization

To maintain efficiency, openrsync calculates block sizes based on the total file size—typically the rounded square root of the file size, with a minimum threshold of 700 bytes. This ensures that the overhead of sending hashes doesn't outweigh the benefit of the delta transfer.

Architecture and Design Philosophy

One of the most significant departures from the original rsync is the architectural simplification. While the original rsync uses a separate "generator" process forked from the receiver, openrsync merges the generator and receiver into a single process. It utilizes an event loop to handle read and write requests, which reduces process overhead and simplifies the execution flow.

Locality and Routing

Openrsync handles three primary host specifications:

  • Local: ../path/to/source
  • Remote Server: host:path/to/source
  • Remote Daemon: rsync://host/module/path

When a remote server is involved, the client forks and initiates the server process over SSH, communicating via socketpair(2) pipes. If a daemon is used, the client connects via a network socket.

A Security-First Approach

Coming from the OpenBSD team, security is not an afterthought. Openrsync leverages native OpenBSD security primitives to minimize the attack surface:

  • pledge(2): This limits the system operations the process can perform. For instance, the receiver is only granted write access to the disk when not in "dry-run" mode.
  • unveil(2): This restricts the process's view of the filesystem. The receiver is "unveiled" only at and beneath the destination directory, preventing the process from accessing or modifying files outside the intended target—a safer alternative to chroot(2) that doesn't require root privileges.
  • Randomized Seeding: Unlike some implementations that use time(3), openrsync seeds its MD4 hashes with arc4random(3) in server mode to increase robustness.

Portability and Trade-offs

While officially supported only on OpenBSD, openrsync is designed to be portable. It currently compiles and runs on Linux (glibc and musl), FreeBSD, NetBSD, macOS, and OmniOS. However, the author notes a critical caveat: the security benefits of pledge and unveil are central to the project's design. Porting these to Linux is described as a complex task due to the fragmented nature of Linux security facilities.

Community Perspectives and Limitations

Feedback from the community highlights both the strengths and the current gaps in the implementation:

  • Feature Parity: Some users have noted that openrsync supports a subset of the original rsync's command-line arguments. While --exclude was recently added in OpenBSD 7.9, other features like -z (compression) have been reported as missing in some versions.
  • Behavioral Quirks: Some users have observed differences in how remote files are created compared to the Samba rsync implementation.
  • The "Vibe Coding" Debate: Some commenters suggest that the original rsync codebase has suffered from "vibe-coded" commits and regressions, making a clean-room rewrite like openrsync a welcome "v2" for the ecosystem.

As one user noted, the move toward a BSD license makes the tool more attractive for integration into other operating systems, with reports that it is already being used in macOS 15.0.

Conclusion

Openrsync is more than just a reimplementation; it is a distillation of the rsync protocol into a modern, secure, and maintainable C codebase of approximately 10,000 lines. By prioritizing security primitives and reducing architectural complexity, the OpenBSD team has provided a robust alternative for those who value transparency and a reduced attack surface over an exhaustive feature set.

Sources