[Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

Wed May 24 11:54:28 UTC 2017

On Wed, May 24, 2017 at 1:12 PM, Rhonda D'Vine <rhonda at deb.at> wrote:

> * Jan Ingvoldstad <frettled at gmail.com> [2017-05-24 12:02:18 CEST]:
> > On Wed, May 24, 2017 at 11:54 AM, Rhonda D'Vine <rhonda at deb.at> wrote:
> > > * Jan Ingvoldstad <frettled at gmail.com> [2017-05-24 11:37:49 CEST]:
> > > > Basically: if you need security updates, don't rely on backports,
> don't
> > > put
> > > > things in backports. The backport policy is incompatible with keeping
> > > > systems up-to-date and secure.
> > >
> > >  That's a highly unfair statement.  The backport policy is the reason
> > > that maintainers are unwilling to update their backports?  Come on,
> > > that's a very very low blow and not a constructive comment.
> >
> >
> > Well, let's look at what the Debian Security FAQ says:
> >
> > *Q: How is security handled for testing?*
> >
> [...]
> > So, as a general principle, security updates are delayed, sometimes by
> two
> > days, sometimes more.
>
>  Right.  And backports could (and should) have the security updates in
> the same timeframe (or earlier) as testing.  That possibility is
> actively hindered if the version in backports does differ from that.
> With the upload exception for fast-tracking of security issues backports
> should have it even faster than testing, that's the idea behind it.
>
>
> > Then we have similar issues as the ones raised by Raphael, where the life
> > of the package maintainer is made difficult.
>
>  He actively chose to ignore the guidelines, and actively chose to not
> communicate about that.  That's very disappointing, for everyone.
>

Is this point really necessary to spend more time on? Should I have avoided
mentioning Raphael by name in order to get the basic point across?

>
> > As a Debian user, I have learned not to use backports for anything
> > important because, let's face it, I'm *toast* if I do so.
>
>  The same goes for testing.
>

Quite so.

Yet you seem to think this is an "unfair" and "low blow" assessment. Why
was it unfair and low blow?

>
> > I have griped about the backports security policy years ago, and others
> > have, too, but you and Alexander shoot any constructive criticism down
> with
> > frankly very off-putting, negative, unconstructive responses.
>
>  I have actively worked with the security team to get backports
> integrated into the security tracker, to be able to ease the job of
> tracking issues.  I've also actively poked people to update their
> backports, and in case they didn't have the time I offered to do the
> upload.  That was before I got into the team.  And that was *only*
> possible because packages were kept in sync on a more or less regular
> basis.
>
>  Unfortunately it looks like many decided to move away from there,
> without communication, which is highly depressing, and yes, I can see
> that it is perceived as negative unconstructive response to a
> non-communication approach by those maintainers.

I think you misunderstand. In my experience, it's the negative and
unconstructive responses to constructive criticism of both the policy and
implementation of the policy that's the problem.

This is the principal reason why I never became a Debian package maintainer
- the responses here are poisonous to those of us who might have a little
bit of time to contribute something.

So instead, we contribute (a little) outside of the community.

>   That very approach
> which stirred these discussions was very unconstructive and negative to
> start off with.  If you consider it only constructive to accept that
> people ignore the rules then I'm very sorry, I'm not available for that.
> What I am very much available is to have a discussion on equal grounds
> and *not* on a forcing-my-view-by-ignoring-the-rules level.
>

I don't see that discussion happening. I don't see any willingness to look
beyond that initial slight made by Raphael, instead this is a repeated
hangup in this discussion, and it's very obviously not leading anywhere
useful to you, to the maintainers, or to us, the users.

>
> > This is why users tend to go to dotdeb and other external package
> > repositories for updated packages. We do it for PHP, we do it for Puppet,
> > we do it for MariaDB, MySQL, etc. The backports policy and/or the way
> > backports are practically handled are in the way.
>
>  Again, it's not the backports policy that hinders the security updates.
>

Huh, you seemed to agree that it was, earlier in your response.

> It's the opinion of backporters that actively ignore that policy and see
> their own approach which actively works against the policy to be the
> only way to get this resolved, and refuse to communicate or coordinate
> beforehand to see how to move forward.  The rules are there for a reason
> - to actually *ease* the possibility to get security fixes in, not to
> make it harder.
>

Well, they *do* make it harder. Added complexity and constraints to what
may be uploaded means that you have a pretty long window of opportunity for
attacks between upstream updates and implementation of these fixes. The
"fast track" doesn't appear to make much of a difference, sorry.

> > Until this changes, it's security 101 to stay away from backports, sorry.
>
>  There is no security team for backports indeed, as there is none for
> testing neither.  The approach for testing is just easier because it has
> this very strict rule as that it ultimately can only have packages from
> unstable moving over.  The more relaxed possibility for backports (and
> human mistakes in accepting such uploads) is the cause of this issue,
> not the solution.
>

I agree that human mistakes compound the issue, at least.
-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/python-modules-team/attachments/20170524/c853181c/attachment.html>