Re: [Xen-devel] Xen 4.1.x security support

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.09.13 at 10:37, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> 
>>> wrote:
> On 09/18/13 10:33, Jan Beulich wrote:
>>>>> On 17.09.13 at 19:38, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> 
>>>>> wrote:
>>> On 09/17/13 08:47, Jan Beulich wrote:
>>>>>>> On 17.09.13 at 00:01, Marek 
>Marczykowski-GÃrecki<marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that further
>>>>> XSAs will not carry patches for 4.1?
>>>>
>>>> That's the way I view it, but that doesn't mean it has to be that way.
>>>>
>>>
>>> That would be rather unfortunate. E.g. we're planning to stick to Xen
>>> 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such
>>> as the GPLPV Windows drivers not working with it correctly.
>>>
>>> I could imagine that it should not be very costly for xen.org to
>>> backport each XSA patch to 4.1, should it?
>> 
>> Depends - there are cases (XSA-52, -53, and -55 for example)
>> where the backport is not straightforward. And doing backports
>> in the trivial cases, but not in the non-trivial ones would be sort
>> of odd.
>> 
>> That said, for the next few months at least we (SUSE) will need to
>> do backports to 4.1 too. But it's not clear to me whether it would
>> be sending the right sign if we were to include these in advisories
>> - after all, from a xen.org perspective we _want_ people to
>> recognize that dead trees are dead (unless someone steps up to
>> continue maintaining them, in which case it would also be that
>> someone to create the respective security fix backports, or at
>> least coordinate this between the parties doing such backports
>> anyway).
>> 
> 
> Perhaps the decision to kill 4.1 branch so early should be revisited
> then?

Again - if you're willing to step up and maintain that tree, we
could consider that (just like 3.4 got maintained for an extended
period of time by a non-core-xen.org person).

To me, who does the maintenance of the stable trees, keeping
two of them up to date already requires non-neglectable amounts
of time. Three is too much for more than a brief overlapping
period - remember that there's other work I need and want to do.

And again - terminating maintenance of the second to last major
release tree after a last wrap-up stable release has been, if not
a written rule, a model we've been following for at least the last
couple of years.

An intermediate solution might be to _only_ put security fixes in
the least recently abandoned stable tree, and do another wrap-up
release once even that activity stops. But whether that would be
a good idea needs input from others (along with working out who's
going to do the resulting work).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel