Status and maintenance of v3.4.1-sec-patches3 & v3.2.7-sec-patches3

[anusurivijay]

Hello Team,

Could you please clarify the status and maintenance model of the following branches?

v3.4.1-sec-patches3
v3.2.7-sec-patches3

We are looking at using these security patch branches for downstream maintenance of rsync versions 3.4.1 and 3.2.7.

In particular, could you please clarify:

Are these branches considered official rsync security-maintenance branches?
Are they expected to remain available?
If additional security fixes are required, is there an intention to create future branches such as v3.4.1-sec-patches4, v3.4.1-sec-patches5, or v3.2.7-sec-patches4, etc.?
Is there an official archive/tarball available for these security patch branches?
What is the recommended way for downstream projects to consume these security fixes?

We would like to understand the intended maintenance model for these branches before using them as a downstream security source.

Thanks!

[steadytao]

They are official security branches and they should remain available for quite some time. They receive backports upon release(s).

I would absolutely love to promise the full 2029 for 3.2.7 and 2031 for 3.4.1 but I cannot make a guarantee that far ahead in the future. However, they are expected to remain for quite some time and I am sure if a time comes that we are unable to continue maintaining those branches that we will be capable of triaging something with Ubuntu/Deb.

My message above as someone also asked this via the Discord. But essentially;

---

Are these branches considered official rsync security-maintenance branches?

Yes.

Are they expected to remain available?

For quite some time, yes. Primarily for Ubuntu/Deb LTS.

If additional security fixes are required, is there an intention to create future branches such as v3.4.1-sec-patches4, v3.4.1-sec-patches5, or v3.2.7-sec-patches4, etc.?

Yes.

Is there an official archive/tarball available for these security patch branches?

Not currently. Is that wanted?

What is the recommended way for downstream projects to consume these security fixes?

.patch files then simply replay that onto your branch and archive it in the way required by your downstream.

[anusurivijay]

They are official security branches and they should remain available for quite some time. They receive backports upon release(s).
I would absolutely love to promise the full 2029 for 3.2.7 and 2031 for 3.4.1 but I cannot make a guarantee that far ahead in the future. However, they are expected to remain for quite some time and I am sure if a time comes that we are unable to continue maintaining those branches that we will be capable of triaging something with Ubuntu/Deb.

My message above as someone also asked this via the Discord. But essentially;

Are these branches considered official rsync security-maintenance branches?

Yes.

Are they expected to remain available?

For quite some time, yes. Primarily for Ubuntu/Deb LTS.

If additional security fixes are required, is there an intention to create future branches such as v3.4.1-sec-patches4, v3.4.1-sec-patches5, or v3.2.7-sec-patches4, etc.?

Yes.

Is there an official archive/tarball available for these security patch branches?

Not currently. Is that wanted?

Yes, an official archive/tarball would be useful for downstream projects such as Yocto/OE-Core.

What is the recommended way for downstream projects to consume these security fixes?

.patch files then simply replay that onto your branch and archive it in the way required by your downstream.

Thanks for clarifying the status of these branches.

[steadytao]

The v3.4.1-sec-patches4 and v3.2.7-sec-patches4 backport branches are now available. They contain the security and compatibility corrections applicable to those older release lines after *-sec-patches3. Both branches have been tested against the refreshed stable testsuite.

After thinking it over, release tarballs are likely not best. Downstreams will maintain these older versions in different ways so the branches are intended as reviewable sources from which maintainers can cherry-pick commits or construct their own patch series.

Users who can upgrade should prefer using the latest version of rsync