Debian Patches

Status for rsync/3.4.1+ds1-5+deb13u2

Patch Description Author Forwarded Bugs Origin Last update
disable_reconfigure_req.diff Remove need to run reconfigure target

===================================================================		 Samuel Henrique <samueloph@debian.org> not-needed 2024-04-12
skip_devices_test_non_linux.patch Skip "devices" test as it fails on kfreebsd and hurd
Error log:
sent 160 bytes received 117 bytes 554.00 bytes/sec
total size is 0 speedup is 0.00
check how the directory listings compare with diff:

+ + /<<PKGBUILDDIR>>/rsynctee -aii /<<PKGBUILDDIR>>/testtmp/devices/rsync.out --link-dest=/<<PKGBUILDDIR>>/testtmp/devices/to
/<<PKGBUILDDIR>>/testtmp/devices/from/ /<<PKGBUILDDIR>>/testtmp/devices/chk/
rsync: failed to hard-link /<<PKGBUILDDIR>>/testtmp/devices/to/fifo with fifo: Invalid cross-device link (1073741842)
cd ./
hD block
hD block2
hD block3
hD block3.5
hD char
hD char2
hD char3
cSc........ fifo
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]
+ cat
+ diff -u /<<PKGBUILDDIR>>/testtmp/devices/rsync.chk /<<PKGBUILDDIR>>/testtmp/devices/rsync.out
/--- /<<PKGBUILDDIR>>/testtmp/devices/rsync.chk 2019-10-15 01:26:43.000000000 +0000
/+++ /<<PKGBUILDDIR>>/testtmp/devices/rsync.out 2019-10-15 01:26:43.000000000 +0000
@@ -6,4 +6,4 @@
hD char
hD char2
hD char3
-hS fifo
+cSc........ fifo
+ test_fail test 5 failed
+ echo test 5 failed
test 5 failed
+ exit 1
/bin/fakeauth: Error 1 for child 7541
/bin/settrans: Error 1 for child 7540
----- devices log ends
FAIL devices		 Samuel Henrique <samueloph@debian.org> no 2024-04-12
env_shebang.patch =?utf-8?q?Removes_usage_of_env_on_shebangs_as_per_Debian_Policy_?= =?utf-8?q?=C2=A7_10=2E4?= Samuel Henrique <samueloph@debian.org> not-needed 2024-04-12
fix_rrsync_man_generation.patch Fix manpage installation for rrsync
Otherwise we would get "ERROR: support/rrsync.1 cannot be created."
I'm not confident this is the best approach on solving this issue,
but I know this works with no regressions.
This patch needs to be reviewed before being submitted to upstream.
===================================================================		 Samuel Henrique <samueloph@debian.org> no 2024-04-12
fix-flaky-hardlinks-test.patch Fix flaky hardlinks test
The test was added in dc34990, it turns out that it's flaky. It failed
once on the Debian build infra, cf. [1].

The problem is that the command `rsync -aH '$fromdir/sym' '$todir'`
updates the mod time of `$todir`, so there might be a diff between the
output of `rsync_ls_lR $fromdir` and `rsync_ls_lR $todir`, if ever rsync
runs 1 second (or more) after the directories were created.

To clarify: it's easy to make the test fails 100% of the times with this
change:

```
makepath "$fromdir/sym" "$todir"
+sleep 5
checkit "$RSYNC -aH '$fromdir/sym' '$todir'" "$fromdir" "$todir"
```

With the fix proposed here, we don't use `checkit` anymore, instead we
just run the rsync command, then a simple `diff` to compare the two
directories. This is exactly what the other `-H` test just above does.

In case there's some doubts, `diff` fails if `sym` is missing:

```
$ mkdir -p foo/sym bar
$ diff foo bar || echo KO!
Only in foo: sym
KO!
```

I tested that, after this commit, the test still catches the `-H`
regression in rsync 3.4.0.


[1]: https://buildd.debian.org/status/fetch.php?pkg=rsync&arch=ppc64el&ver=3.4.1%2Bds1-1&stamp=1741147156&raw=0		 Arnaud Rebillout <arnaudr@kali.org> yes 2025-03-06
CVE-2025-10158.patch fixed an invalid access to files array
this was found by Calum Hutton from Rapid7. It is a real bug, but
analysis shows it can't be leverged into an exploit. Worth fixing
though.

Many thanks to Calum and Rapid7 for finding and reporting this		 Andrew Tridgell <andrew@tridgell.net> no 2025-08-23
syscall_use_openat2_RESOLVE_BENEATH_on_Linux_for_secure_relative_open.patch syscall: use openat2(RESOLVE_BENEATH) on Linux for secure_relative_open

The CVE fix in commit c35e283 made secure_relative_open() walk every
component of relpath with O_NOFOLLOW. That blocks every symlink in the
path, which is stricter than the threat model required: legitimate
directory symlinks within the destination tree (e.g. when using -K /
--copy-dirlinks) are also rejected, breaking delta transfers with
"failed verification -- update discarded". See issue #715.

On Linux 5.6+, openat2(RESOLVE_BENEATH | RESOLVE_NO_MAGICLINKS) gives
us exactly what we want: the kernel rejects any resolution that would
escape the starting directory (via "..", absolute paths, or symlinks
pointing outside dirfd) while still following symlinks that resolve
within it. /proc magic-links are blocked too.

Use openat2 first; fall back to the existing per-component O_NOFOLLOW
walk on ENOSYS (kernel < 5.6). The lexical "../" checks at the head
of the function are kept as defense in depth. The Linux gate is
plain #ifdef __linux__: the runtime ENOSYS fallback covers the only
case that actually matters (header present + old kernel), and any
Linux build environment without linux/openat2.h will fail with a
clear "no such file" error rather than silently disabling the
protection.

Verified manually that openat2(RESOLVE_BENEATH) blocks all four
escape patterns (absolute symlink, ../ symlink, lexical .., absolute
path) while allowing direct and within-tree symlinks. The new
testsuite/symlink-dirlink-basis.test (taken from PR #864 by Samuel
Henrique) exercises the issue #715 regression and passes; full
make check passes 47/47.		 Andrew Tridgell <andrew@tridgell.net> no 2026-04-30
CVE-2026-41035.patch xattrs: fixed count in qsort
this fixes the count passed to the sort of the xattr list. This issue
was reported here:

https://www.openwall.com/lists/oss-security/2026/04/16/2

the bug is not exploitable due to the fork-per-connection design of
rsync, the attack is the equivalent of the user closing the socket
themselves.		 Andrew Tridgell <andrew@tridgell.net> no 2026-04-22

All known versions for source package 'rsync'

Links