From: Paul Barker <paul@pbarker.dev>
To: Vijay Anusuri <vanusuri@mvista.com>, sdoshi@mvista.com
Cc: openembedded-core@lists.openembedded.org,
Yoann Congal <yoann.congal@smile.fr>
Subject: Re: [OE-core] [wrynose][patch] rsync: Security fixes from v3.4.1-sec-patches3
Date: Mon, 21 Sep 2026 20:52:56 +0100 [thread overview]
Message-ID: <4ccc62a34b7c0ff418951a62c873daa589e45683.camel@pbarker.dev> (raw)
In-Reply-To: <CANQUz19S86jm7H3aoNKvm3NwEZ_L=QEmt53g4i2j=fgOz=e8jw@mail.gmail.com>
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
next prev parent reply other threads:[~2026-09-21 19:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
2026-10-08 8:40 ` Hetvi Thakar -X (hthakar - E INFOCHIPS PRIVATE LIMITED at Cisco)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ccc62a34b7c0ff418951a62c873daa589e45683.camel@pbarker.dev \
--to=paul@pbarker.dev \
--cc=openembedded-core@lists.openembedded.org \
--cc=sdoshi@mvista.com \
--cc=vanusuri@mvista.com \
--cc=yoann.congal@smile.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox