Re: Backports policy for security updates (was: Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED)
On Wednesday, May 24, 2017 06:42:22 AM Alexander Wirt wrote:
> 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_"
OK. I can understand that. Thanks.
I realize that socially, granting an exception for python-django right now is
not ideal since the discuss first didn't happen, but I think technically a
really good case can be made for python-django updates and I'd like to try.
At this point in it's lifecycle, all Django 1.8 is getting is security fixes.
The Django Project has a very defined policy about post release maintenance
[1]. They also have a very extensive test suite that the package runs for
both python and python3 at build time.
The most recent release had two CVE fixes. As with all web frameworks, it's
security history is not wonderful, but upstream is very responsive about
addressing issues when they are identified for all supported releases.
As an LTS release, Django 1.8 is supported for security releases until at
least April of 2018, which will be near the end of Jessie's support window
(and two months of hand backporting patches if needed is not typically
difficult - I'm doing it locally for Django 1.6 now). If allowed to continue
we can support this through Jessie's life.
Bottom line is the current python-django in jessie backports has open security
issues that should be addressed through package removal, patch cherry-picking,
or updating to the new release. Given the scope of the latest release,
there's no technical difference between those last two and I think it's less
risk to update to the new version than extracting patches and re-applying
patches.
Personally, I think updating is better than removing. Please consider this
talking to you in advance of trying to do this per the policy.
Thanks,
Scott K
[1] https://www.djangoproject.com/download/ (second half of the page)
Reply to: