Bug 12947 - rsync in CU170 crashes with an error
Summary: rsync in CU170 crashes with an error
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: - Unknown - Crash
Assignee: Adolf Belka
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-04 10:35 UTC by Adolf Belka
Modified: 2022-10-20 13:23 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adolf Belka 2022-10-04 10:35:33 UTC
In CU 170 a security patch was applied to rsync for CVE-2022-29154

5 days after this patch was merged into the IPFire git repo a bug was identified with it and fix carried out. Three further fixes were then required to resolve additional bugs created in the first fix.

None of these fixes got into CU170. The fixes were applied in rsync git without any notification.

The CVE patch and all subsequent fixes are built into versions from 3.2.5 onwards
Comment 1 Adolf Belka 2022-10-04 10:37:44 UTC
See community thread on this topic

https://community.ipfire.org/t/rsync-via-ssh-doesnt-work-anymore-since-core-170/8708
Comment 2 Adolf Belka 2022-10-04 10:57:57 UTC
Patch for version 3.2.6 submitted to dev mailing list and patchwork.

https://patchwork.ipfire.org/project/ipfire/patch/20221004105442.3649212-1-adolf.belka@ipfire.org/
Comment 5 Adolf Belka 2022-10-07 11:29:12 UTC
The person who flagged up the original problem on the community forum does not want to test out CU171 Testing as he doesn't want to have to do a full install when CU171 goes to Stable release.

I tried a test with my vm testbed.

With CU171 Testing I did an rsync from a green client to the ipfire machine from the ipfire machine. The rsync at both ends was 3.2.6
The synchronisation worked without a problem.

As a reference I then, with CU170, did the same rsync command. This time the rsync version on ipfire was 3.2.4 while on the green client it was 3.2.6
That synchronisation also worked without a problem.

I then went back and read the report about the problem with rsync that camne from the CVE-2022-29154 patch and realised that most files were being synchronised successfully but the synch could fail on random files.

So it looks like for verification of this bug we will have to wait for the person who flagged up the problem to test out CU171 when it is released as a Stable version and tested with the same fileset as caused the original problem.

I expect it will solve the problem as since rsync-3.2.5 when the bug fixes were included no-one has been flagging up this issue on the rsync git issues page.