From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: Xen 4.1.x security support Date: Wed, 18 Sep 2013 10:37:33 +0200 Message-ID: <5239664D.4080202@invisiblethingslab.com> References: <52377FC0.6000302@invisiblethingslab.com> <5238172E02000078000F3DBB@nat28.tlf.novell.com> <52389387.10008@invisiblethingslab.com> <5239818202000078000F4416@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7885925024032624301==" Return-path: In-Reply-To: <5239818202000078000F4416@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: marmarek@invisiblethingslab.com, "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7885925024032624301== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCD69D89061A5DF249F8F7B73" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCD69D89061A5DF249F8F7B73 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/18/13 10:33, Jan Beulich wrote: >>>> On 17.09.13 at 19:38, Joanna Rutkowska wrote: >> On 09/17/13 08:47, Jan Beulich wrote: >>>>>> On 17.09.13 at 00:01, Marek Marczykowski-G=F3recki wrote: >>>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that f= urther >>>> 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= =2E >>> >> >> 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 suc= h >> 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? >=20 > 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. >=20 > 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). >=20 Perhaps the decision to kill 4.1 branch so early should be revisited then? This forces people who used Xen 4.1 to build products (e.g. because back when they made the decision the 4.2 was still not released) to make a significant work now to adopt the 4.2. joanna. --------------enigCD69D89061A5DF249F8F7B73 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJSOWZNAAoJEJwtLfzExk0LdpAH/04ZHRLfavlCk+J9ShCqIAXy siiw/ePcMM+X9ovx5PeMnJ2NK1azV+gqTPIiPXxKHe/whZJKqUkpdcsZgHbhwr0i Xgi3lb8CAtEX8bkCDNjF0MFfOvGijBcxBnGPnP6/EijWq2cSeFKgu9boHRujjnMj FqBnr7s2Qd/D2QTG3uQO1a6Yk3aDKNa9Nl/PC5A4DNfaICU40wBGTWNrbnYG7zLj 2xLyQKh/8ezgNy15m2M5WNd07WVtsvxEAkYMjvJnoScnji/CrNul+KtwpeYa+nDI xBrSH/GUQrVcm0ME/gRUbytEus3cNyNt8Pe7Dua+cqmW5rE1WEqRyaJbJMD2ZHs= =4lnj -----END PGP SIGNATURE----- --------------enigCD69D89061A5DF249F8F7B73-- --===============7885925024032624301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7885925024032624301==--