Re: Backports upgrade policy (ButAutomaticUpdates:yes)
martin f krafft <email@example.com> writes:
> While this might seem like a good idea at first — like when
> a security fix reaches the backports archive
> I am sure we all agree that the
> deny-all-but-what-is-explicitly-allowed policy is the better one. So
> why did we make the switch?
Because of security fixes. :)
The basic problem is that we have no way of knowing whether an updated
backport is a security fix or not, and not installing security fixes is
> The problem in the past was that security fixes to the package in stable
> may well never reach users with backports installed. This problem is
> actually not addressed, as security fixes might not appear in testing
> anytime soon, nor is it guaranteed that the backport will be upgraded.
I always understood that I had a responsibility as a backporter to release
security fixes as necessary, and if I wasn't going to do that, I shouldn't
upload the backport in the first place. I handle backport security fixes
exactly the way that I handle stable security fixes.
There is not, so far as I know, a security team like there is for stable,
and that team does a ton of great work for stable. Manpower would be
required to duplicate that work. But while we aren't providing stable
levels of security support for backports, I don't think we're doing as
poorly as all that.
> In the long run, maybe we need a stable-backports-security repository,
> which can be used to ensure that backport users don't miss out on
> security fixes without having to accept major changes. Ping me when the
> security team has 30 active members working 5 days a week on Debian and
> I'll look into writing the dak patches. ;)
This would immediately introduce another problem: what version of the
backport are you goint to patch for the security vulnerability? Certainly
not every version that's ever been uploaded and that someone might
possibly be stuck at. :)
Also, backports, as with testing, frequently get security fixes in the
form of upstream releases that include other changes.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>