Fixes land on master first and ship in the next 0.6.x release. Changes merged since 0.6.4 are listed under Unreleased in CHANGELOG.md.

If you discover a security vulnerability in oc-rsync, please report it responsibly:

1. Do not open a public GitHub issue for security vulnerabilities
2. Email the maintainer directly at: skewers.irises.3b@icloud.com
3. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact assessment
   • Any suggested fixes (optional)

You can expect:

• Initial acknowledgment within 48 hours
• Regular updates on the fix progress
• Credit in the security advisory (unless you prefer anonymity)

Safe Rust rules out out-of-bounds access, use-after-free, reads of uninitialised memory and data races in the code it covers. It does not rule out logic flaws: a fail-open access check, an unconfined path or an unbounded peer-supplied count is as reachable in safe Rust as in C. OS-level races at filesystem boundaries (TOCTOU) are also outside what the language prevents, which is why path handling goes through the confined *at walk described below.

Every crate root sets #![deny(unsafe_code)] (engine outside tests only), so each unsafe block needs a targeted #[allow(unsafe_code)] and a SAFETY comment. Unsafe code belongs to two owning crates, split by subject, that expose safe APIs:

• platform - process, identity, environment and signals: daemonization, per-connection fork/waitpid, name and group resolution, privilege transitions, chroot, environment access, local time, signal disposition and Windows service dispatch.
• fast_io - I/O syscalls: io_uring, copy_file_range, sendfile, mmap, reflink and copy dispatch, IOCP and Winsock, and the confined-path resolver.

New unsafe code goes first to a safe wrapper crate (nix, rustix, socket2, exacl, windows), then to a safe API on platform or fast_io, and only then to a new #[allow(unsafe_code)] function whose SAFETY comment says why the first two could not express it.

That is the target, not yet the whole tree. Several crates outside the two owners still declare FFI crates such as libc or nix directly, and four hold production unsafe from before the split, permitted until their sites migrate: metadata (ownership, identity, xattr, timestamp and Windows ACL FFI), checksums (SIMD intrinsics, with scalar fallbacks and parity tests), engine (platform FFI and the buffer pool) and protocol (one site in multiplex frame parsing). windows-gnu-eh holds Windows GNU exception-handling shims, and the oc-rsync binary has one #[unsafe(no_mangle)] static that sets jemalloc's decay options. Other crates allow unsafe only in tests.

The reference version is upstream rsync 3.5.1. Its release notes name no CVE ids; its fixes are tracked in the 3.5.1 table below. Each CVE row carries one of five statuses:

• Fixed: the code closes it, and a named test or PR shows it.
• Partially fixed: some affected paths are closed and shown by a test or PR, but at least one path is still exposed.
• Open: oc-rsync is still exposed, or a test that covers it fails.
• Not applicable: the affected code has no counterpart in oc-rsync.
• Unverified: not yet established either way from the code or a test.

"Passes on every leg that runs it" refers to the upstream 3.5.1 test suite, run against oc-rsync on the legs listed in the README. Some cells skip on some legs, for example when they need root.

3.5.0 kept protocol 32, so none of these stem from a wire-format change. They are implementation flaws in code oc-rsync reimplements independently. Re-derive the id list from the 3.5.0 section of the 3.5.1 NEWS.md and check that every id has a row (the section also names two 3.4.3 ids, CVE-2026-43617 and CVE-2026-43620, which have rows above):

awk '/^# NEWS for rsync 3.5.0/,/^# NEWS for rsync 3.4/' \
  target/interop/upstream-src/rsync-3.5.1/NEWS.md \
  | grep -o 'CVE-2026-[0-9]*' | sort -u > /tmp/batch
grep -oE '^\| CVE-2026-[0-9]+' SECURITY.md | cut -c3- | sort -u > /tmp/rows
comm -23 /tmp/batch /tmp/rows      # ids with no row: prints nothing
grep -cE '^\| CVE-2026-(5|7)[0-9]{4} \|' SECURITY.md      # 3.5.0 rows: 33

Count the statuses:

grep -E '^\| CVE-2026-(5|7)[0-9]{4} \|' SECURITY.md | cut -d'|' -f5 | sort | uniq -c

Hardening gaps without a CVE. The coverage matrix in docs/audits/cve-uts351-matrix.md found these next to the rows above. All four are now fixed:

New options in 3.5.0. --confine-root=DIR, --drop-D / --no-drop-D, --insecure-links / --no-insecure-links, and the auth digest, insecure links and proxy protocol hosts daemon directives are implemented (PRs #7396, #7299, #7350, #7484, #7648). Like upstream, --confine-root and --drop-D are not forwarded to the remote side.

--drop-D makes a receiver refuse to create device and special files. It exists because --no-D on one end only desynchronises the file list: a -D sender writes rdev fields that a --no-D receiver never reads. --drop-D refuses the creation and leaves the wire format alone.

3.5.1 raises the protocol to 33 and names no CVE ids. Its security-relevant fixes, from its NEWS.md:

No 3.5.1 testsuite cell fails on any leg. A future fail row would be listed, with cause and owner, by awk '!/^#/ && $2=="fail" {print $1}' tools/ci/upstream-3.5.1-expect.*.txt | sort -u.

The rsync 3.4.3 defense-in-depth audit, the path-syscall (*at) migration record for CVE-2026-29518 / CVE-2026-43619, and the rsync 3.4.2 audit list are kept in docs/audits/security-upstream-audit-history.md.

Sources:

1. rsync-announce: https://lists.samba.org/mailman/listinfo/rsync-announce
2. NVD: https://nvd.nist.gov/vuln/search?query=rsync
3. GitHub Security Advisories for this repository
4. Scheduled watcher: upstream-release-watch.yml runs tools/ci/check_upstream_release.sh every Monday and opens a tracking issue when a new upstream rsync release ships

For each new upstream CVE:

1. Analyse the root cause (memory corruption, logic error, etc.)
2. Check whether oc-rsync has an equivalent code path
3. Check whether Rust's guarantees actually cover it (logic flaws are not covered)
4. Record the analysis in this file
5. If oc-rsync is affected, issue a security advisory and a fix

Three cargo-fuzz workspaces hold 36 targets. They are excluded from the main workspace and do not commit a Cargo.lock, so each fuzz build resolves a fresh lockfile.

Every target runs every day. fuzz-coverage-report.yml ("Fuzz Daily Sweep") fuzzes 31 of them for 120 seconds each, built from the workspaces' [[bin]] tables by tools/ci/fuzz_target_matrix.py, and fails on any crash, sanitizer report, timeout or OOM. The five differential targets run for longer in differential-fuzzer-overnight.yml and filter-fuzzer-overnight.yml. See fuzz/README.md for how to run a target locally.

recycle_buffer(buf_id) in the io_uring path (crates/fast_io/src/io_uring/buffer_ring/mod.rs) validates that buf_id falls within the registered buffer pool and returns BufferRingError::BufferIdOutOfRange when it does not. The check runs in both debug and release builds, and the recycle is refused before any state is mutated, so a corrupted or attacker-influenced buf_id cannot advance the ring tail or write into kernel-shared memory.

io_uring buffer-group IDs (bgid) live in a 16-bit namespace. Allocation is capped at this bound, and exhaustion returns BgidAllocError::Exhausted rather than wrapping. Released ids go back to a free list. No production caller allocates one today: BufferRing and BgidAllocator appear only inside fast_io and its tests, so exhaustion is not a live operational condition (docs/audits/bgid-lifecycle.md, section 5). Peak-occupancy telemetry becomes relevant once per-session rings are wired in.

• Transport. The daemon protocol is plaintext, like upstream: it authenticates but does not encrypt. On an untrusted network, bind the daemon to 127.0.0.1 or a private interface and reach it through an SSH tunnel (ssh -L) or the SSH transport, or through a TLS terminator such as stunnel or HAProxy / nginx in TCP mode. oc-rsync has no built-in TLS client (the former --ssl / client-tls path was removed to match upstream), so clients use an external wrapper such as rsync-ssl or stunnel.
• Confinement. use chroot = yes, and expose only the paths you need. Prefer read only = yes where possible.
• Access control. hosts allow / hosts deny run before authentication; auth users with a secrets file of mode 0600, owned by the daemon user only. With proxy protocol = true, list the trusted proxies in proxy protocol hosts; left unset, every PROXY header is refused.
• Identity mapping. numeric ids = yes keeps uid/gid mapping independent of the daemon's passwd/group.
• Options. refuse options = delete * for read-only mirrors.

1. Verify the server's identity: use SSH for transport when possible
2. Check --delete targets: make sure you are syncing to the intended destination
3. Review exclude patterns: avoid transferring sensitive files by accident
4. Confine untrusted transfers: --confine-root=DIR confines every operator- and peer-supplied path beneath DIR, and --drop-D makes a receiver refuse device and special files

Security researchers who have contributed to oc-rsync's security:

• (Your name could be here - report responsibly!)