* Re: [OE-core][wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 [not found] <20260917105551.76512-1-vanusuri@mvista.com> @ 2026-09-17 11:38 ` Yoann Congal 2026-09-17 12:31 ` Yoann Congal 0 siblings, 1 reply; 8+ messages in thread From: Yoann Congal @ 2026-09-17 11:38 UTC (permalink / raw) To: vanusuri, openembedded-core 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 <vanusuri@mvista.com> > --- > ...-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. Regards, -- Yoann Congal Smile ECS ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core][wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 2026-09-17 11:38 ` [OE-core][wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 Yoann Congal @ 2026-09-17 12:31 ` Yoann Congal 2026-09-17 12:51 ` Paul Barker 0 siblings, 1 reply; 8+ messages in thread From: Yoann Congal @ 2026-09-17 12:31 UTC (permalink / raw) To: Yoann Congal, vanusuri, openembedded-core; +Cc: Paul Barker 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 <vanusuri@mvista.com> >> --- >> ...-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? Thanks! -- Yoann Congal Smile ECS ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core][wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 2026-09-17 12:31 ` Yoann Congal @ 2026-09-17 12:51 ` Paul Barker 2026-09-17 14:00 ` Vijay Anusuri 0 siblings, 1 reply; 8+ messages in thread From: Paul Barker @ 2026-09-17 12:51 UTC (permalink / raw) To: Yoann Congal, vanusuri, openembedded-core 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 <vanusuri@mvista.com> > > > --- > > > ...-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/DL0HY2YT9WGM.3ACOQJL408XKI@smile.fr/ [2]: https://github.com/RsyncProject/rsync/issues?q=is%3Aissue%20%223.5.0%22 Best regards, -- Paul Barker ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core][wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 2026-09-17 12:51 ` Paul Barker @ 2026-09-17 14:00 ` Vijay Anusuri 2026-09-17 14:33 ` [wrynose][patch] " Siddharth Doshi 0 siblings, 1 reply; 8+ messages in thread From: Vijay Anusuri @ 2026-09-17 14:00 UTC (permalink / raw) To: Paul Barker; +Cc: Yoann Congal, openembedded-core [-- Attachment #1: Type: text/plain, Size: 4907 bytes --] 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 <paul@pbarker.dev> 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 <vanusuri@mvista.com> > > > > --- > > > > ...-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/DL0HY2YT9WGM.3ACOQJL408XKI@smile.fr/ > [2]: > https://github.com/RsyncProject/rsync/issues?q=is%3Aissue%20%223.5.0%22 > > Best regards, > > -- > Paul Barker > > [-- Attachment #2: Type: text/html, Size: 6972 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 2026-09-17 14:00 ` Vijay Anusuri @ 2026-09-17 14:33 ` Siddharth Doshi 2026-09-21 10:26 ` [OE-core] " Vijay Anusuri 0 siblings, 1 reply; 8+ messages in thread From: Siddharth Doshi @ 2026-09-17 14:33 UTC (permalink / raw) To: openembedded-core [-- Attachment #1: Type: text/plain, Size: 1822 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 7258 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] [wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 2026-09-17 14:33 ` [wrynose][patch] " Siddharth Doshi @ 2026-09-21 10:26 ` Vijay Anusuri 2026-09-21 19:52 ` Paul Barker 0 siblings, 1 reply; 8+ messages in thread From: Vijay Anusuri @ 2026-09-21 10:26 UTC (permalink / raw) To: sdoshi; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 3821 bytes --] 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 <sdoshi=mvista.com@lists.openembedded.org> 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 (#246070): > https://lists.openembedded.org/g/openembedded-core/message/246070 > Mute This Topic: https://lists.openembedded.org/mt/121293944/7301997 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > vanusuri@mvista.com] > -=-=-=-=-=-=-=-=-=-=-=- > > [-- Attachment #2: Type: text/html, Size: 8888 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] [wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 2026-09-21 10:26 ` [OE-core] " Vijay Anusuri @ 2026-09-21 19:52 ` Paul Barker 2026-10-08 8:40 ` Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) 0 siblings, 1 reply; 8+ messages in thread From: Paul Barker @ 2026-09-21 19:52 UTC (permalink / raw) To: Vijay Anusuri, sdoshi; +Cc: openembedded-core, Yoann Congal On Mon, 2026-09-21 at 15:56 +0530, Vijay Anusuri wrote: > 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 Hi Vijay, Thanks for checking with upstream. It seems a bit of a strange way of doing things to me - I am surprised these aren't further releases in the 3.4.x and 3.2.x series. Or at least they could be 3.4.1.x and 3.2.7.x releases. But if this is the way upstream want to handle things then that's their call. We do need to discuss how this fits in with our policies on LTS maintenance. We will get back to you soon. Best regards, -- Paul Barker ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 2026-09-21 19:52 ` Paul Barker @ 2026-10-08 8:40 ` Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) 0 siblings, 0 replies; 8+ messages in thread From: Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco) @ 2026-10-08 8:40 UTC (permalink / raw) To: openembedded-core [-- Attachment #1: Type: text/plain, Size: 2122 bytes --] On Tue, Sep 22, 2026 at 01:23 AM, Paul Barker wrote: > > On Mon, 2026-09-21 at 15:56 +0530, Vijay Anusuri wrote: > >> 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 > > Hi Vijay, > > Thanks for checking with upstream. It seems a bit of a strange way of > doing things to me - I am surprised these aren't further releases in the > 3.4.x and 3.2.x series. Or at least they could be 3.4.1.x and 3.2.7.x > releases. But if this is the way upstream want to handle things then > that's their call. > > We do need to discuss how this fits in with our policies on LTS > maintenance. We will get back to you soon. > > Best regards, > > -- > Paul Barker Hi Paul, Yoann, Could you please share if there are any updates on this? Regards, Hetvi Thakar [-- Attachment #2: Type: text/html, Size: 2379 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2026-10-08 8:40 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260917105551.76512-1-vanusuri@mvista.com>
2026-09-17 11:38 ` [OE-core][wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3 Yoann Congal
2026-09-17 12:31 ` Yoann Congal
2026-09-17 12:51 ` Paul Barker
2026-09-17 14:00 ` Vijay Anusuri
2026-09-17 14:33 ` [wrynose][patch] " Siddharth Doshi
2026-09-21 10:26 ` [OE-core] " Vijay Anusuri
2026-09-21 19:52 ` Paul Barker
2026-10-08 8:40 ` Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco)
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.