SRU/CVE wholesale backport of (mostly) obscured blobs

[Dimitri John Ledkov]

On 27 June 2017 at 11:31, Robie Basak <robie.basak at ubuntu.com> wrote:
>
> Hi Dimitri,
>
> Thank you for raising this here.
>
> On Tue, Jun 27, 2017 at 10:45:39AM +0100, Dimitri John Ledkov wrote:
> > Instead, I have been asked by an SRU team member to create a more typical
> > targetted SRU update which uses divergent packaging on per-series basis,
> > increasing the delta of each SRU relative the devel series, and minimizing
> > packaging changes relative each of the series this package will land in.
>
> I don't think this statement accurately reflects my position. I did say
> that we could go down the route of an ongoing SRU exception on the basis
> of backports as you have done, but this would need separate
> consideration and documentation, in line with the other exceptions
> already granted. But this has not been done or requested, which is why I
> declined to accept the SRU at the moment yet did not reject it
> immediately. I specifically did not rule this path out, both on IRC and
> in my bug comment.
>
> 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.

> 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.

> releases at once. I don't think it makes sense to break out of this
> pattern in this case for a one-off SRU, for the same reason that we
> don't do the same thing with the kernel.
>
> I'd appreciate opinions from other SRU team members. But I don't
> understand why you aren't prepared to seek a documented, ongoing
> exception. Isn't that what you want anyway?
>

I believe I am already following the existing document process of hwe
feature backports to updates pocket.

> Separately, I've seen multiple claims that this is a security issue, but
> personally I remain unconvinced. If the security team agree with you
> that it is, then shouldn't this be going in via the security pockets and
> be moot from an SRU policy perspective? Could you please decide which it
> is, getting agreement from the security team if required, to avoid
> further confusion?
>

Upstream (Intel) are not following normal Linux security / CVE
disclosure process. It is unknown how many security vulnerabilities
microcode updates fix. It is prudent to assume it is an unsigned
integer value of more than zero.

-- 
Regards,

Dimitri.