SRU/CVE wholesale backport of (mostly) obscured blobs

[Steve Langasek]

Hi Dimitri,

On Tue, Jun 27, 2017 at 02:29:33PM +0100, Dimitri John Ledkov wrote:
> On 27 June 2017 at 11:31, Robie Basak <robie.basak at ubuntu.com> wrote:

> > On Tue, Jun 27, 2017 at 10:45:39AM +0100, Dimitri John Ledkov wrote:

> > https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1700373/comments/10
> > documents my position and that of one other SRU team member.

> > > I find this request to be inconsistent with the current practices of
> > > wholesale backports in the cases when it is not possible to distinguish
> > > piece-wise SRU/CVE bugfixes. It creates extra additional work to maintain
> > > distinct lines of packaging on per-series basis especially when it is not
> > > possible to create SRU / security templates on every individual change as
> > > they are SRUed.

> > I think this statement conflates the packaging and delivery mechanism
> > and the blobs themselves. Source is available for the packaging and your
> > "not possible to distinguish" does not apply to it. *It absolutely is
> > possible* to follow the regular SRU procedure on the changes I am
> > currently declining to accept.

> There is no way to distinguish changes of each microcode, what it
> does, and which bugs it fixes and to create templates on how to
> reproduce and validate each bug / vulnerability that is fixed. My
> understanding is that normal SRU process is there to document every
> change that goes into distribution, and validates that only the
> changes to fix those particular issues go in, and that the bugs an
> update claims to fix, are in fact actually fixed.

> This normal SRU process is not followed for an undocumented set of
> packages. And imho intel-microcode should be part of that set.

First, the fact that there is an undocumented set of packages that don't
follow the normal SRU process is a historical bug, which we should seek to
correct, not expand.

Second, the packaging of hardware enablement SRUs undergoes *extensive*
review by the SRU team, which can result in several rounds of rejects.
This mostly has to do with the fact that the HWE packages are presented as
parallel stacks in the archive, and therefore regularly include packaging
changes in addition to upstream changes, which is highly error-prone.  But
the point is that it is existing SRU team policy for packages which do have
some sort of upstream exception - whether it's an MRE, an SRE, or a hardware
enablement exception - that this exception does *not* cover the packaging. 
Changes to the packaging must still be justified on their own merits, and
where they are independent of the upstream changes, must follow the normal
SRU process (justification, test case, analysis of regression potential).


In the case of this intel-microcode SRU, it appears that the only changes to
the packaging in yakkety to the debhelper compat level and the standards
version.  The standards version change is entirely cosmetic, of course.  For
the debhelper compat change, one of two things is true.  Either the change
is a complete no-op, in which case it's trivial to revert this change as
part of the SRU; or the change results in some change to the contents of the
resulting binary package, in which case this should be accounted for as part
of the SRU (since whatever those changes are, they are not driven by
upstream).

If you don't know which of these is the case, this is also sufficient
argument that the packaging should not be changed in the SRU.


For xenial, the packaging changes are substantive.  They are probably
justifiable in an SRU.  But they require an SRU process, because they are
changes to the integration with Ubuntu - unrelated to the changes to the
upstream payload.

> > Maintaining distinct lines of packaging on a per-series basis is exactly
> > what we choose do in Ubuntu by choosing to maintain multiple stable

> That clearly is not done for many packages that land in the updates
> and security pockets. I have provided multiple examples of wholesale
> backports landing into updates pocket which clearly do not maintain
> minimal per-series changes.

The list of packages you presented was:

  nvidia-graphics-drivers-NNN, firefox, linux-hwe, nplan, cloud-archive.

I have not reviewed any nvidia packages recently in the SRU queue so I can't
personally comment on what has been done there or why.

firefox is handled through the security queue, not through the SRU queue,
and is therefore subject to a different process.  As Robie said, you are
welcome to make the case to the Security Team for intel-microcode.

linux-hwe is an SRU, and does include packaging changes.  The nature and
cadence of the updates for all of the kernel packages means it is both
infeasible to deliver as an SRU with per-packaging-change SRU bugs, and
higher risk to our users to deliver the upstream code with different
packaging than what has already been used in the devel series.  I do not
consider this a precedent for any package of less complexity than the
kernel.

nplan has been allowed a one-time exception on the basis that it is a new
component in yakkety and the risk of regression is small given the small
userbase.  But furthermore, there are no significant packaging changes
introduced.

I assume you mean cloud-init for the last one.  The lack of documented
exception for cloud-init is considered a bug, which the Server Team is well
aware of and has the task of drafting a proposal for a stable release
exception.


None of these are exceptions that I think map to what you had asked for with
respect to intel-microcode.

So I'm afraid I have to agree with rejecting these SRUs as presented.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20170629/d3d60b76/attachment.pgp>