Major rsync upgrade in Debian because of 33 CVEs
26 points by janus
26 points by janus
rsync (3.5.0+ds1-0+deb13u1) trixie-security; urgency=medium
In order to fix 33 CVEs, I have decided to bump the package to 3.5.0 rather than backporting all patches individually. After analysing the extra changes from the bump, not included in the CVE fixes, I have concluded this approach carries the lower amount of risk compared to the alternative.
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:
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.
-- Samuel Henrique samueloph@debian.org Tue, 15 Sep 2026 18:46:30 -0700
rrsync in 3.5.0 was quite broken. 3.5.1 fixes it.
I would like to know why you feel this Debian Security News belongs on lobsters. Care to elaborate?
Debian's "stable" distro usually doesn't bump package versions so this is, at least, an unusual event. I think it's reasonable to give lobsters a chance to discuss, although OP could/should have provided some context.
I'd expect Debian package version bumps to happen more often (at least for the near- to mid-term future) as the effort required to back-port our current flood of LLM-discovered fixes becomes greater than the maintainers can afford.
Yeah definitely interesting of how those bumps might break distro releases, and what this might mean moving forward (if it will be sustained, increase, or die down). And what mitigation folks might need to employ to avoid brokenness.
rrsync in 3.5.0 was quite broken. 3.5.1 fixes it.
Note that all of the fixes from 3.5.1 were added in the Debian Trixie package 3.5.0+ds1-0+deb13u1.
I was very careful in timing the fix of the CVEs for a moment where all known regressions were fixed and the risk of new unknown ones was lower
Its important news in the computing world. I'd rather read about this update than anything vibecoding related, but both still belong here.
Yes, they are. Its unfortunate, but its also the reality of the world we live in at the moment. I'd also rather see LLM's/"AI" be used to find CVE's and help get things fixed than let the vulnerabilities sit and be abused.
I mostly draw the line at using LLM's/"AI" to do all the coding from the start. I think as something like a 'linter' they're mostly fine. It gets to be a bit problematic when you're letting the bots write the code and you can't really attribute copyright properly.
It gets to be a bit problematic when you're letting the bots write the code and you can't really attribute copyright properly.
Anthropic offers an indemnification arrangement, which it's only going to be a problem for Anthropic!
This is covered in section K of the commercial terms.
Topicality: Lobsters is focused pretty narrowly on computing; tags like art don't imply every piece of art is on-topic. Some rules of thumb for great stories to submit: Will this improve the reader's next program?
Yes, if your Debian system is considered a program.
Will it deepen their understanding of their last program?
If their last program used rsync and they have automatic upgrades, I suppose it might?
Will it be more interesting in five or ten years?
Definitely more interesting, I love retrocomputing and old news. Something voyeur about it, and so weird that people in the old days were so different from us, and yet so similar.
Some things that are off-topic here but popular on larger, similar sites: entrepreneurship,
Doesn't apply
management,
Doesn't apply
news about companies that employ a lot of programmers,
Doesn't apply
investing,
Doesn't apply
world events,
Doesn't apply
anthropology,
Doesn't apply
self-help,
Doesn't apply
personal productivity systems,
Doesn't apply
last-resort customer service requests via public shaming, "I wanted to see what this site's amazing users think about this off-topic thing",
Doesn't apply
and defining the single morally correct economic and political system for the entire world when we can't even settle tabs vs. spaces.
Doesn't apply