Thank you for looking into this. The test case is described in https://github.com/backuppc/backuppc/issues/369#issuecomment-693663922 and boils down to:
> * Create temporary file on host [i.e. backup client, with rsync 3.2.3] > * Run `/usr/share/backuppc/bin/BackupPC_dump -v -f host` manually on the > server cmdline as correct user [use BackupPC v3 with buggy > libfile-rsyncp-perl, as present in Ubuntu 18.04 and 20.04) > * Wait for rsync to start dumping files (i.e. indexing is complete), then > delete temporary file on host HTH. ** Bug watch added: github.com/backuppc/backuppc/issues #369 https://github.com/backuppc/backuppc/issues/369 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/2007837 Title: 22.04: Backport request from 3.2.4 for fix of 3.2.3 regression Status in rsync package in Ubuntu: New Status in rsync source package in Jammy: Incomplete Status in rsync package in Debian: Unknown Bug description: rsync 3.2.3 (packaged in Ubuntu 22.04) changes stderr handling, leading another bug in libfile-rsyncp-perl (in Ubuntu 18.04 and 20.04) to surface [1]. It practically makes using BackupPC 3 impossible with clients using rsync 3.2.3, as is packaged for 22.04. The fact that BackupPC on 20.04 can't be used to back up machines with 22.04 is rather surprising and has bitten other users [2]. It's unclear whether the bug will be fixed in 18.04's and 20.04's libfile-rsyncp-perl package (for status, see [3]). Because of this, the rsync maintainer has included a patch in 3.2.4 that fixes this regression [4] (even though not strictly an rsync bug). As a result, rsync 3.2.3 is the only affected version, which happens to be the one packaged in 22.04. This report is to request backporting that fix [4] to Ubuntu 22.04, so that things don't silently break in scenarios where the backup server is left at 20.04, and some backup clients happen to upgrade to 22.04. I'm not sure what the criteria for security releases are, but as the issue causes backup denial of service and has easy mitigation, I think it would make sense to put it through the security channel. [1]: https://github.com/WayneD/rsync/issues/95#issuecomment-699185358 [2]: https://www.mail-archive.com/backuppc-users@lists.sourceforge.net/msg32673.html [3]: https://bugs.launchpad.net/ubuntu/+source/libfile-rsyncp-perl/+bug/2007833 [4]: https://github.com/WayneD/rsync/commit/4adfdaaf12db26c348b4d6150119b377f9b622c8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/2007837/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
