Hi Yoann, Paul, I checked with the rsync upstream maintainers regarding the security patch branches and the possibility of an archive/tarball.
They confirmed that v3.4.1-sec-patches3 and v3.2.7-sec-patches3 are official rsync security-maintenance branches. They have now also published: - v3.4.1-sec-patches4 - v3.2.7-sec-patches4 These branches contain the security and compatibility fixes applicable to the respective older release lines after *-sec-patches3. Both branches have been tested against the refreshed stable testsuite. Regarding the archive/tarball, the maintainer clarified that they do not plan to provide release tarballs for these security branches. The branches are intended to be used as reviewable Git sources from which downstream maintainers can cherry-pick commits or construct their own patch series. Based on this, can we switch the rsync recipe to Git and use the v3.4.1-sec-patches4 & v3.2.7-sec-patches4 branches for Wrynose/Scarthgap? This would allow us to consume the upstream security and compatibility fixes directly from the maintained security branch instead of carrying the large 34KLOC patch series. The discussion with the rsync maintainers is here: https://github.com/RsyncProject/rsync/discussions/1095 Thanks & Regards, Vijay On Thu, Sep 17, 2026 at 8:03 PM Siddharth Doshi via lists.openembedded.org <[email protected]> wrote: > Hi Yoann, Paul and Vijay, > > v3.4.1-sec-patches3 and v3.2.7-sec-patches3 both the branches are part of > official security release afaik. > > these versions corresponds to ubuntu/launchpad PPA for racoon and noble > respectively so i see them being maintained till 2031 and 2029 > atleast(unless ubuntu decides on bumping those versions up in unforseen > situations). > > with that being said, yes it is trade-off between maintaining 34 kLOC > patch and minor upgrade which we need to figure out. > upgrading to 3.4.4 is less favourable as it still leaves 33 CVE's open and > for that we would still have a larger patch to maintain rather than patches > getting applied directly. > > Since rsync does not expose an architecture-wide library (librsync is a > completely distinct project), upgrading it will *never break the ABI of > other compiled packages* in rootfs. No other binary links against rsync > dynamically at the linker level. on top of it, rsync is maintaining > backword compatability. So upgrading to 3.5.x wouldn't be an issue too. > > To talk about the regressions in 3.5.0, they are being fixed in 3.5.1 > which is planned to release on 21st september. > > we have 2 ways in front of us: > 1) maintain the 34 kLOC patch for 3.4.1. > Pros: we will mostly have maintainence till 2031( 1 year more than wrynose > EOL). > cons: large patches to be maintained. (we can locally tar it though but > still has to be maintained) > > 2) upgrade the 3.5.1 > Pros: no need to maintain large patches and we would be in line with > upstream. > Cons: we will be violating the stable upgrade policy of no new features > and there are chances we would encounter same situation in future when more > CVE's are found affecting the newer version. > > i am fine with either of the way as one of fellow contributor. But, let me > know your thoughts. > > Regards, > Siddharth > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246314): https://lists.openembedded.org/g/openembedded-core/message/246314 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]] -=-=-=-=-=-=-=-=-=-=-=-
