Openrsync: An implementation of rsync, by the OpenBSD team

Original Article ↗ Hacker News Discussion ↗

Openrsync, a BSD-licensed reimplementation of the widely used rsync file synchronization tool by the OpenBSD team, is drawing attention as a simpler, security-focused alternative that integrates tightly with OpenBSD’s pledge/unveil sandboxing. Commenters debate its partial feature set, protocol compatibility, and behavioral differences from “original” rsync, especially as macOS and possibly other platforms adopt it, raising concerns about fragmentation and script breakage. The thread also widens into a broader argument over GPL vs BSD licensing, the ethics and quality implications of AI-assisted code in rsync, and whether reimplementations like openrsync are necessary or a wasteful duplication of effort.

Project goals & scope

  • openrsync is a from-scratch, ~10k‑line C reimplementation of rsync by the OpenBSD team.
  • Primary drivers mentioned:
    • Need a second independent implementation of the rsync protocol for RPKI work and standards.
    • Preference for BSD licensing and OpenBSD-style “lean, audited” code.
  • The stated goal is not full feature parity with rsync; only a subset needed for RPKI and typical use cases.

Security model & OS support

  • On OpenBSD, openrsync uses pledge(2) and unveil(2) to sandbox the process; this is emphasized as critical to mitigate the impact of bugs while handling untrusted network data.
  • On other OSes (Linux, etc.) it is “portable” only in the sense that it runs; equivalent sandboxing is absent or harder.
  • Linux is characterized as having fragmented primitives (cgroups, namespaces, seccomp) versus OpenBSD’s simpler model; Landlock-based unveil/pledge wrappers exist but are still evolving.
  • Some argue the README overstates the risk (“accepts arbitrary data”) and that pledge/unveil limit damage rather than network exposure.

Compatibility & fragmentation

  • openrsync historically lacked some widely used features (e.g., --exclude, -z), though --exclude now works on OpenBSD 7.9.
  • It supports only older rsync protocol versions; commenters note missing 64‑bit timestamp support.
  • Differences in path handling (e.g., file vs directory semantics) have already broken scripts, especially after Apple adopted openrsync in macOS and later changed behavior in a point release.
  • Concern: multiple implementations (original rsync, openrsync, Go rsync, etc.) will force power users to learn diverging quirks, similar to GNU vs BSD tar/cpio.

Licensing and naming debates

  • Some see “openrsync” as confusing because rsync is already GPL‑licensed free software.
  • Others say “open” is just the OpenBSD family naming convention (OpenSSH, OpenBGPD, etc.) and reflects BSD licensing.
  • Extended debate over BSD vs GPL:
    • BSD is framed as maximizing developer freedom and ease of forking (e.g., Redis/Valkey discussion).
    • GPL/AGPL is framed as protecting user freedom by preventing closed derivatives.
  • No consensus; both sides see their approach as morally superior or more “open.”

AI-generated code controversy

  • A major subthread reacts to a burst of AI‑assisted (“Claude”) commits in upstream rsync, coinciding with a spike in bugs and at least one non-building release.
  • One camp views this as evidence that “vibecoded” AI changes are degrading quality and plans to avoid such projects, favoring tools like openrsync.
  • Another camp argues regressions are normal in evolving software, that AI is just another tool, and that blanket avoidance is unrealistic and unproductive.
  • Similar suspicion is raised about AI involvement in Postfix; others point out the cited evidence refers to AI used for bug-finding, not clearly for code-writing, calling the claim unsubstantiated.