Openrsync: An implementation of rsync, by the OpenBSD team

Original Article ↗ Hacker News Discussion ↗

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.