On Sat, Jan 18, 2025 at 12:14:16PM +1100, George at Clug wrote: > > I rarely use backports, but when I do, I like the "adjusted and > recompiled for usage on Debian stable" part, much better that grabbing > packages from other distributions and just installing them, hoping > there will not be issues. Though I had not realised that at times, a > package would be moved/copied from backports into security, I would > not have expected that action, but it does make sense when you > explained it. > To be entirely clear, "at times, a package would be moved/copied from backports into security" is 100% NOT what happens.
Backporting (at least in the Debian context) has two distinct meanings: - a specific patch or set of patches, which are prepared for a given version of a package, are adapted to an older version of that package - a newer version of some package is rebuilt for an older version of Debian (using the older tools and dependencies of that older Debian version) Both of these may happen within the context of a security update, the second also happens at times outside of a security context. For the "specific set of patches" case, many open source projects only maintain a single active development branch of their project. When a security vulnerability is announced, they fix it in that active release branch and then move on with life. When that happens, distro maintainers that are responsible for the security of older versions of these projects are left to grab the patches from upstream (usually in the form of one or more git commit diffs) and then adapt those patches to the older version. This activity is "backporting of one or more specific patches". This is what was done recently in the case of rsync. There is almost never a need to perform this sort of backporting outside of a security context, though it has happened on occasion. As far as the two types of full package backports, there is a security reason to this and a non-security reason. In the case of security fixes, certain projects make dedicated releases that restrict the fixes on a given branch to security and high severity bugs. Projects with a good reputation for this and with policies that align well with Debian's stable release criteria include Mozilla, Chromium, MariaDB, PostgreSQL and some others. In general, when they fix a vulnerability, they fix it in all actively maintained branches. When that happens and those branches include a new release in the same series as what is in Debian stable (which is often the case), then the security team is able to incorporate that new version of the package, build it for Debian stable and release that as a security update (with something like a +deb12uX version number). The other type of full package backport is not for security reasons but for reasons of wanting a newer version of a package (along with newer features) in an older Debian release. These packages are provided via the backports archive, they are not given any security support, and importantly they do not conform to Debian's stable release criteria. This means that these packages may have open security vulnerabilities, and they may have features and behaviors which differ substantially from what was released in Debian stable. In other words, they may break your existing whatever (programs you are compiling in the case of a library, scripts you've written in the case of an interperter, etc). Regards, -Roberto -- Roberto C. Sánchez
