Hi Yoann, Paul, Thanks for the feedback.
I have opened a discussion [1] with the rsync upstream project to clarify the status and maintenance model of the v3.4.1-sec-patches3 and v3.2.7-sec-patches3 branches, including whether they will remain available and whether future security patch branches will be published. Regarding the 3.4.4 upgrade, I noticed that upgrading from 3.4.1 to 3.4.4 would still leave us with around 33 CVEs to address. The rsync 3.5.0 release [2] addresses these 33 CVEs. I will continue to investigate the available options [1] https://github.com/RsyncProject/rsync/discussions/1095 [2] https://download.samba.org/pub/rsync/NEWS#3.5.0 Thanks & Regards, Vijay On Thu, Sep 17, 2026 at 6:21 PM Paul Barker <[email protected]> wrote: > On Thu, 2026-09-17 at 14:31 +0200, Yoann Congal wrote: > > On Thu Sep 17, 2026 at 1:38 PM CEST, Yoann Congal wrote: > > > On Thu Sep 17, 2026 at 12:55 PM CEST, Vijay Anusuri via > lists.openembedded.org wrote: > > > > Backport the security fixes from the upstream v3.4.1-sec-patches3 > > > > branch to address the known rsync security vulnerabilities. > > > > > > > > The v3.4.1-sec-patches3 branch contains 239 commits. The GitHub > > > > workflow commits (037, 038, and 160), which only modify > > > > .github/workflows files, and the testsuite-only commits (238 and > > > > 239) are excluded because they are not applicable to the Yocto > > > > build. > > > > > > > > The remaining 237 security fixes are combined into a single patch > > > > series and applied on top of the rsync 3.4.1 source. > > > > > > > > SUSE has also backported these security fixes to > rsync-3.4.1-160000.6.1 > > > > to address the corresponding CVEs. > > > > > > > > References: > > > > > > > > https://rsync.samba.org/security.html > > > > https://github.com/RsyncProject/rsync/tree/v3.4.1-sec-patches3 > > > > https://bugzilla.suse.com/show_bug.cgi?id=CVE-2026-53802 > > > > > > > > This fix handles CVE-2025-10158 CVE-2026-29518 CVE-2026-43617 > CVE-2026-43618 CVE-2026-43619 CVE-2026-43620 CVE-2026-45232 CVE-2026-44507 > CVE-2026-44508 CVE-2026-44509 CVE-2026-44510 CVE-2026-53783 CVE-2026-53784 > CVE-2026-53785 CVE-2026-53786 CVE-2026-53788 CVE-2026-53789 CVE-2026-53790 > CVE-2026-53791 CVE-2026-53792 CVE-2026-53793 CVE-2026-53794 CVE-2026-53795 > CVE-2026-53796 CVE-2026-53797 CVE-2026-53798 CVE-2026-53799 CVE-2026-53800 > CVE-2026-53801 CVE-2026-53802 CVE-2026-53803 CVE-2026-70452 CVE-2026-70453 > CVE-2026-70454 CVE-2026-70455 CVE-2026-70456 CVE-2026-70457 CVE-2026-70458 > CVE-2026-70459 CVE-2026-70460 CVE-2026-70461 CVE-2026-70462 CVE-2026-70463 > CVE-2026-70464 > > > > > > > > Dropped CVE-2025-10158.patch > > > > Refreshed the patch > 0001-Add-missing-prototypes-to-function-declarations.patch > > > > > > > > Signed-off-by: Vijay Anusuri <[email protected]> > > > > --- > > > > ...-prototypes-to-function-declarations.patch | 81 +- > > > > .../rsync/files/CVE-2025-10158.patch | 36 - > > > > .../files/rsync-3.4.1-sec-patches3.patch | 34052 > ++++++++++++++++ > > > > meta/recipes-devtools/rsync/rsync_3.4.1.bb | 2 +- > > > > 4 files changed, 34071 insertions(+), 100 deletions(-) > > > > delete mode 100644 > meta/recipes-devtools/rsync/files/CVE-2025-10158.patch > > > > create mode 100644 > meta/recipes-devtools/rsync/files/rsync-3.4.1-sec-patches3.patch > > > > > > Hello, > > > > > > I don't think I want to carry a 34000 lines patch. > > > > > > Does the rsync project released a v3.4.1-sec-patches3 archive? > > > > > > If not, can we try to switch the recipe to git and point SRCREV to the > > > "rsync-3.4.1-sec-patches" branch? > > > Since the recipe is not git-based now, we'll need to switch to git > > > first, then upgrade. > > > > Paul asked a good question about this idea though: How official is this > > branch? > > Can you ask upstream the status of it? Will it stay published? Will we > > see v3.4.1-sec-patches4,5... branches someday? > > Hi Yoann, Vijay, > > Some thoughts here... > > The upgrade to v3.4.3 was rejected [1] due to a few minor feature > additions. In this case it may be lower risk to take an upgrade rather > than backporting a 34 kLOC patch. I think we should avoid v3.5.0 due to > the number of regressions reported [2]. v3.4.4 is an option. We can then > see how many CVEs remain open and decide what to do about them. > > The onus here is on contributors, not on Yoann as stable maintainer. To > go ahead we would need some investigation, testing and a proposal to the > TSC to approve the update as an exception to our usual stable policy. > > [1]: https://lore.kernel.org/all/[email protected]/ > [2]: > https://github.com/RsyncProject/rsync/issues?q=is%3Aissue%20%223.5.0%22 > > Best regards, > > -- > Paul Barker > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246066): https://lists.openembedded.org/g/openembedded-core/message/246066 Mute This Topic: https://lists.openembedded.org/mt/121293944/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
