<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 24, 2017 at 1:12 PM, Rhonda D'Vine <span dir="ltr"><<a href="mailto:rhonda@deb.at" target="_blank">rhonda@deb.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Jan Ingvoldstad <<a href="mailto:frettled@gmail.com">frettled@gmail.com</a>> [2017-05-24 12:02:18 CEST]:<br>
<span class="">> On Wed, May 24, 2017 at 11:54 AM, Rhonda D'Vine <<a href="mailto:rhonda@deb.at">rhonda@deb.at</a>> wrote:<br>
> > * Jan Ingvoldstad <<a href="mailto:frettled@gmail.com">frettled@gmail.com</a>> [2017-05-24 11:37:49 CEST]:<br>
> > > Basically: if you need security updates, don't rely on backports, don't<br>
> > put<br>
> > > things in backports. The backport policy is incompatible with keeping<br>
> > > systems up-to-date and secure.<br>
> ><br>
> >  That's a highly unfair statement.  The backport policy is the reason<br>
> > that maintainers are unwilling to update their backports?  Come on,<br>
> > that's a very very low blow and not a constructive comment.<br>
><br>
><br>
> Well, let's look at what the Debian Security FAQ says:<br>
><br>
</span>> *Q: How is security handled for testing?*<br>
><br>
[...]<br>
<span class="">> So, as a general principle, security updates are delayed, sometimes by two<br>
> days, sometimes more.<br>
<br>
</span> Right.  And backports could (and should) have the security updates in<br>
the same timeframe (or earlier) as testing.  That possibility is<br>
actively hindered if the version in backports does differ from that.<br>
With the upload exception for fast-tracking of security issues backports<br>
should have it even faster than testing, that's the idea behind it.<br>
<span class=""><br>
<br>
> Then we have similar issues as the ones raised by Raphael, where the life<br>
> of the package maintainer is made difficult.<br>
<br>
</span> He actively chose to ignore the guidelines, and actively chose to not<br>
communicate about that.  That's very disappointing, for everyone.<br></blockquote><div><br></div><div>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?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> As a Debian user, I have learned not to use backports for anything<br>
> important because, let's face it, I'm *toast* if I do so.<br>
<br>
</span> The same goes for testing.<br></blockquote><div><br></div><div>Quite so.</div><div><br></div><div>Yet you seem to think this is an "unfair" and "low blow" assessment. Why was it unfair and low blow?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I have griped about the backports security policy years ago, and others<br>
> have, too, but you and Alexander shoot any constructive criticism down with<br>
> frankly very off-putting, negative, unconstructive responses.<br>
<br>
</span> I have actively worked with the security team to get backports<br>
integrated into the security tracker, to be able to ease the job of<br>
tracking issues.  I've also actively poked people to update their<br>
backports, and in case they didn't have the time I offered to do the<br>
upload.  That was before I got into the team.  And that was *only*<br>
possible because packages were kept in sync on a more or less regular<br>
basis.<br>
<br>
 Unfortunately it looks like many decided to move away from there,<br>
without communication, which is highly depressing, and yes, I can see<br>
that it is perceived as negative unconstructive response to a<br>
non-communication approach by those maintainers.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So instead, we contribute (a little) outside of the community.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  That very approach<br>
which stirred these discussions was very unconstructive and negative to<br>
start off with.  If you consider it only constructive to accept that<br>
people ignore the rules then I'm very sorry, I'm not available for that.<br>
What I am very much available is to have a discussion on equal grounds<br>
and *not* on a forcing-my-view-by-ignoring-<wbr>the-rules level.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> This is why users tend to go to dotdeb and other external package<br>
> repositories for updated packages. We do it for PHP, we do it for Puppet,<br>
> we do it for MariaDB, MySQL, etc. The backports policy and/or the way<br>
> backports are practically handled are in the way.<br>
<br>
</span> Again, it's not the backports policy that hinders the security updates.<br></blockquote><div><br></div><div>Huh, you seemed to agree that it was, earlier in your response.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's the opinion of backporters that actively ignore that policy and see<br>
their own approach which actively works against the policy to be the<br>
only way to get this resolved, and refuse to communicate or coordinate<br>
beforehand to see how to move forward.  The rules are there for a reason<br>
- to actually *ease* the possibility to get security fixes in, not to<br>
make it harder.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Until this changes, it's security 101 to stay away from backports, sorry.<br>
<br>
</span> There is no security team for backports indeed, as there is none for<br>
testing neither.  The approach for testing is just easier because it has<br>
this very strict rule as that it ultimately can only have packages from<br>
unstable moving over.  The more relaxed possibility for backports (and<br>
human mistakes in accepting such uploads) is the cause of this issue,<br>
not the solution.<br></blockquote><div><br></div><div></div></div><div>I agree that human mistakes compound the issue, at least.</div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Jan</div>
</div></div>