Why rsync update?

Asked by buhtz


I'm an upstream maintainer of a GUI application using rsync in the back. I try to understand the update policy of Ubuntu and want to learn.

To my knowledge in Ubuntu 22.04 (LTS) rsync has been updated from 3.2.3 to 3.2.7 on Feb 27.

Regarding to semantic versioning this should be a problem. But rsync doesn't follow the semantic versioning. There was a big breaking change in version 3.2.4 which made the "new argument protect" the default behavior.

This will break some rsync using applications and scripts using rsync over SSH.

It seems to me someone didn't understand the changelog and there wasn't a review and now good testing.
IMHO that update need to be rolled back in Ubuntu 22.04.

But it is just my IMHO and I'm sure there are good reasons why you did it the way you did. I'm asking with intention to learn.

Christian Buhtz

Question information

English Edit question
Ubuntu rsync Edit question
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Marc Deslauriers (mdeslaur) said :

We updated to a new version in order to fix CVE-2022-29154. The new argument protection feature is part of the fix for CVE-2022-29154 and will likely be backported by distros to all previous rsync versions.

While we usually backport specific security fixes to our stable releases, in this case most of the commits that went into 3.2.5, 3.2.6 and 3.2.7 were to fix that particular CVE, and to fix a whole slew of regressions caused by it. The best approach was to update jammy and kinetic to 3.2.7.

Revision history for this message
buhtz (buhtz) said :

Dear Marc,
thank you for your reply. I'm not sure if I got all details.

There is the description of CVE-2022-29154
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29154
 - https://download.samba.org/pub/rsync/NEWS#SECURITY_FIXES-3.2.5

I don't see that it has something to do with the "new argument protection".

And beside the fix for CVE-2022-29154 in rsync 3.2.5 I don't see any security fixes in the changelog of rsync 3.2.6 and 3.2.7 (the currently latest).

Keep in mind that the "new argument protected" was introduced some years ago with somewhere around version 3.0. But it was not the default behavior. Rsync 3.2.4 made the behavior default.

It sounds to me that making the new behavior default would fix some security issues. If this is the case then the old argument protection does cause security issues and should be deactivated?

I assume I misunderstand something here.

Does it have any security implications if the "new argument protection" is default or not?


Revision history for this message
Bernard Stafford (bernard010) said :
Revision history for this message
Marc Deslauriers (mdeslaur) said :

From the 3.2.5 release notes:

A note to those wanting to patch older rsync versions: the changes in this release requires the quoted argument change from 3.2.4. Then, you'll want every single code change from 3.2.5 since there is no fluff in this release.

These changes are regressions from the CVE-2022-29154 security fixes introduced in 3.2.5:


- Fixed the client-side validating of the remote sender's filtering behavior.

- More fixes for the "unrequested file-list name" name, including a copy of
  "/" with `--relative` enabled and a copy with a lot of related paths with
  `--relative` enabled (often derived from a `--files-from` list).


- More path-cleaning improvements in the file-list validation code to avoid
  rejecting of valid args.

- A file-list validation fix for a [`--files-from`](rsync.1#opt) file that ends
  without a line-terminating character.

Can you help with this problem?

Provide an answer of your own, or ask buhtz for more information if necessary.

To post a message you must log in.