Re: [Xen-devel] Design session report: Xen on Distros

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/07/2019 18:52, Amit Shah wrote:
> On Mon, 2019-07-15 at 14:52 +0000, Jan Beulich wrote:
>> On 15.07.2019 16:42, George Dunlap wrote:
>>> On 7/15/19 3:23 PM, Jan Beulich wrote:
>>>> On 15.07.2019 16:11, George Dunlap wrote:
>>>>> There was a long discussion about security patches, with the
>>>>> general
>>>>> proposal being that we should cut a point release for every
>>>>> security issue.
>>>> Interesting. Looks like in politics that until a decision fits
>>>> people
>>>> they keep re-raising the point. Iirc on a prior meeting
>>>> (Budapest?)
>>>> we had settled on continuing with the current scheme. Were there
>>>> any
>>>> new arguments towards this alternative model?
>>> Well I don't know if there were any new arguments because I don't
>>> immediately remember the old discussion.  Do we have a summary of
>>> the
>>> discussion in Budapest, with its conclusions, anywhere?
>> I don't recall if suitable notes were taken back then; as indicated
>> I'm not even sure which meeting it was at.
>>
>>> The basic idea was that:
>>>
>>> 1. Most distros / packagers are going to want to do an immediate
>>> release
>>> anyway.
>>>
>>> 2. Distros generally seemed to be rebasing on top of staging as
>>> soon as
>>> the XSA went out anyway (and ISTR this being the recommeneded
>>> course of
>>> action)
>>>
>>> So for all intents and purposes, we have something which is, in
>>> fact, a
>>> release; all it's missing is a signed tag and a tarball.
>>>
>>> Obviously there are testing implications that would need to be
>>> sorted
>>> out before this could become a reality.
>>>
>>> In any case, the ball is in the court of "VOLUNTEER" to write up a
>>> concrete proposal which could be discussed.  You'll be able to
>>> raise all
>>> your concerns at that point if you want (although having a sketch
>>> would
>>> of course be helpful for whoever is writing such a proposal).
>> Sure - I realized soon after having sent the initial reply that
>> perhaps
>> this was the wrong context in the first place to raise my question.
> In any case, I'd like to know why it doesn't make sense for Xen to have
> a point release frequently, and not have a point release after an XSA
> above some severity level (pick one - high/critical/important).

We specifically do not rate XSAs like that.  One persons apple is a
different persons orange, considering how varied the environments which
Xen runs in are.

If in doubt, people should take all the XSA fixes.

> As George mentioned, distros have to do it anyway, and the upstream
> project not doing it only makes it more difficult for all distros
> involved.
>
> Not sure of the politics involved though, and what can of worms this
> opens.

Its a perfectly valid discussion to have, and comes down (in large part)
to the overhead of doing releases, which comes largely from other areas
of our infrastructure which are currently under question.

A full point release includes tagging a load of repos (2x qemu, seabios,
ovmf iirc), then waiting for generally 2-3 weeks for OSSTest to
stabilise enough to declare the patches good, even for ones which were
tested (elsewhere) to various downstream's satisfaction during the
embargo period.

We could trivially throw the fixes into the branch, tag it, sign it and
throw it out into the open, but doing that on the embargo date itself
would result in an official release of Xen which has had 0 testing in
the incumbent test system.

One aspect which would ease things is to not include 3rd party packages
in releases.  This was discussed as part of the build system gripes
session iirc, and would reduce the number of in-flight moving parts to
just xen.git.

Another aspect is that of the test system.  At the moment, nothing can
be released on the older security branches, because they still haven't
recovered from the carnage of the Debian upgrade.  Irrespective of that
particular issue, the general delay between patches appearing and
OSSTest saying yes is a concerning factor in how much effort it takes to
get a release out.


What a number of people want is for the patches in an XSA advisory to
apply cleanly to whatever random thing they have in their local/distro
patch queue.  This is entirely impossible for the security to arrange,
and furthermore, we have exactly one location where the patches we
produce will be committed.

As a personal view here, I don't think blindly taking the latest
staging-$X.$Y is a viable substitute for at least understanding the
patches well enough to work around trivial offsets/fuzz due to minor
variations.

However, if the overhead of doing a micro release became substantially
less, and producing a micro release after every XSA would help a decent
chunk of our downstreams consume security fixes more easily, then it
would be worth considering.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel