Hello,
regarding the many CVEs discovered in rsync lately.
In Debian LTS we will follow what was done for Debian stable (trixie)
in DSA 6527-1. That is to say: backport rsync 3.5.0, plus regressions
fixes from 3.5.1, into Debian bookworm.
It is a more viable option than trying to backport all the patches one
by one to an old rsync version. And going forward, it will be much
easier to keep applying security fixes as they come.
The change is potentially disruptive, given that those security fixes
also come with some behavior changes. Below I'll reproduce the NEWS
entry from trixie, that also applies for bookworm.
The new package will be uploaded this Monday, 9 of November.
Regards,
Arnaud
--------
DSA 6527-1:
https://lists.debian.org/debian-security-announce/2026/msg00440.html
--------
Extract from the NEWS entry (credits to Samuel Henrique)
This update contains behavior changes, all of which stems from the
CVE fixes
themselves, not exclusive to the version bump. The ones most likely
to break
an existing setup are listed here; /usr/share/doc/rsync/NEWS.md.gz
has the
full list.
Operator-supplied paths are no longer followed through untrusted
symlinks.
The destination directory and the arguments to --backup-dir, --temp-dir,
--partial-dir, --link-dest, --compare-dest, --copy-dest, --log-file,
--password-file, --files-from, --include-from, --exclude-from,
--write-batch, --read-batch and --filter merge files are now resolved one
component at a time, following a symlink only when it is owned by root or
by the user running rsync; one owned by anyone else is refused with
"refusing to follow a symlink owned by an untrusted user".
--insecure-links restores the old behaviour, but it is local only and a
daemon never honours it. For a single trusted module, set
"insecure links = yes" in that module instead.
rrsync now refuses --debug on every invocation. When restricted to a
subdirectory it additionally denies --copy-unsafe-links, passes the new
--confine-root so the server will not resolve a client-named filter merge
file outside that directory, and passes --drop-D when receiving, so an
upload can no longer create devices or special files there ("skipping
non-regular file"). A plain "rsync -a" otherwise still works.
--chmod=a+s now sets both the setuid and setgid bits, matching chmod(1);
it previously set setuid alone.
rsyncd changes that can change who gets in:
* "proxy protocol = true" without "proxy protocol hosts" now rejects
every connection and warns at startup, instead of trusting a
client-supplied PROXY header.
* "hosts deny" now fails closed when a configured hostname cannot be
resolved (with "forward lookup", the default), so a host previously
admitted by an unresolvable deny entry is now blocked.
* "auth users" values that start with a comma now split on commas alone,
as documented, so a deny or :ro rule naming a group whose name
contains
a space now takes effect where it was silently ignored.
* "hosts allow" / "hosts deny" patterns now fold case inside a [...]
bracket expression as well, so a rule such as [A-Z]* matches hosts it
used to miss.
* A client-requested --compress-threads is capped at 8.
rsync-ssl now verifies the server certificate. The default openssl
backend additionally binds it to the requested hostname, so a certificate
valid for some other name is now rejected. The stunnel and gnutls
backends refuse to run unless RSYNC_SSL_CA_CERT is set, or
RSYNC_SSL_ALLOW_INSECURE_STUNNEL=1 / RSYNC_SSL_ALLOW_INSECURE_GNUTLS=1 is
set to opt out.
--------
