Re: Backports policy for security updates (was: Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED)

[Alexander Wirt <formorer@formorer.de>]

On Wed, 24 May 2017, Scott Kitterman wrote:

> > On Tue, 23 May 2017, Scott Kitterman wrote:
> > > On May 23, 2017 5:28:04 PM EDT, Alexander Wirt <formorer@formorer.de> 
> wrote:
> ...
> > > There are security fixes in this upload.  What's the way to get those
> > > fixed?  Backporting 1.10 isn't an option because it is incompatible with
> > > many other packages.
> > > 
> > > Would cherry-picked security fixes be okay?
> > 
> > The policy is pretty clear. Backporting 1.10 and backport the other packages
> > too.
> > 
> > It is maybe a problem and maybe we should get the policy changed - I
> > personally don't think too. I don't wan't software that isn't in testing in
> > backports - but doing it behinds our back is not an option.
> > 
> > Alex
> 
> OK.  Let's try and step away from this one instance for a moment and discuss 
> what makes sense for policy for backports.
> 
> It does happen that changes get into testing that make it impractical to do 
> further backports (in the case at hand it potentially impacts 125 packages, I 
> would consider that impractical, but I suppose not everyone would agree).  
> Regardless of python-django, I think there are going to be cases where 
> updating from testing will no longer be feasible.
> 
> If a severe bug is present in the backported package and updates via testing 
> aren't feasible, what's the right answer?  I can think of three options, none 
> of them ideal:
> 
> 1.  Remove the backport.  Per the policy, backports are supposed to be 
> supported and supportable for the life a release.  If that's no longer true, 
> it should be removed.  While this gets the buggy package out of the archive 
> and prevents new installs, it does nothing for users that have previously 
> installed the package.
> 
> 2.  Leave the bug unaddressed.  Depending on the severity of the issue, this 
> may be the best answer.
> 
> 3.  Allow fixes to be added to existing backports packages to address severe 
> (including security) bugs.  This breaks the backport from testing paradigm and 
> is sure to get abused by some, but in cases where it is no longer feasible to 
> update the backport, it may be the only answer.
> 
> As you can probably guess from the way I wrote them up, I favor choice 3 and 
> would like to see about getting the policy updated to explicitly allow it.  As 
> a concept, does that seem reasonable to you?
I don't think adding this as a general policy is a good idea. People will
abuse it, history clearly shows this. 

It may make sense from case to case and this is already in the policy:

"If you feel you would need to diverge from these rules, either discuss it on the mailing list or bring it up with the Backports Team for an exception."

I think usually it is perfectly ok to expect maintainers to maintain their
backports from within stable. 

Lets have a look on your options: 

1) has the advantage that it prevents new people from installing the broken
backports

2) has the disadvantage that it doesn't prevent people from installing the
broken backport

so looking only at 1 and 2, I would prefer 1). 

Now option 3). This may work from case to case, but to be honest - from all
the cases I saw in the last months, none of them warranted such an excusion.

So I am really against a generic policy change, everything is else "talk to
us in _advance_"

Alex