Summary: | rsync in CU170 crashes with an error | ||
---|---|---|---|
Product: | IPFire | Reporter: | Adolf Belka <adolf.belka> |
Component: | --- | Assignee: | Adolf Belka <adolf.belka> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | Crash | ||
Priority: | - Unknown - | CC: | peter.mueller |
Version: | 2 | ||
Hardware: | unspecified | ||
OS: | Unspecified |
Description
Adolf Belka
2022-10-04 10:35:33 UTC
See community thread on this topic https://community.ipfire.org/t/rsync-via-ssh-doesnt-work-anymore-since-core-170/8708 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/ 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. |