From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Bakke Subject: Re: Expat 2.2.7 with security fixes has been released / CVE-2018-20843 Date: Fri, 12 Jul 2019 23:01:55 +0200 Message-ID: <87wognklvg.fsf@devup.no> References: <9ba7e06a-e907-4703-7aa4-1c46961786ad@pipping.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42277) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hm2g7-00031v-9x for guix-devel@gnu.org; Fri, 12 Jul 2019 17:02:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hm2g5-0005m4-Q6 for guix-devel@gnu.org; Fri, 12 Jul 2019 17:02:03 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:43699) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hm2g5-0005kg-Ei for guix-devel@gnu.org; Fri, 12 Jul 2019 17:02:01 -0400 In-Reply-To: <9ba7e06a-e907-4703-7aa4-1c46961786ad@pipping.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Sebastian Pipping , Jack Hill Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sebastian, Thank you very much for reaching out downstream! Sebastian Pipping writes: > Hi Jack, > > > On 12.07.19 01:17, Jack Hill wrote: >> I'm pleased to let you know that we've applied the fix for >> CVE-2018-20843 in GNU Guix as of >> 5a836ce38c9c29e9c2bd306007347486b90c5064 [0]. We elected to backport the >> patch that fixed the problem instead of upgrading due to a change in the >> expat abi with 2.2.7 [1]. >>=20 >> Many thanks to Marius Bakke for advice and patience while reviewing the >> patches. >>=20 >> [0] >> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=3D5a836ce38c9c29e9c= 2bd306007347486b90c5064 >>=20 >> [1] https://issues.guix.gnu.org/issue/36424#2 > > thanks for the update on that matter! > > Regarding the removed API symbols, those were never part of the public > API so whoever used them needed to have copied prototypes for those into > his own code base and be aware that using internal API is asking for > trouble =E2=80=94 the opposite of something to rely on. They made that c= hoice, > it should be their cost. > > openSuse started using -fvisibility=3Dhidden with their expat package way > before Expat itself and they seem fine. I discussed with senior Linux > distro developers how hiding those symbols should affect Expat's .so > versioning, if it should be an incompatible bump or not. There was no > demand for doing an incompatible bump because all related symbols were > never exposed by headers. Right, I was probably overly cautious here. Because we already had Expat 2.2.7 on a different branch-in-progress, I went with the path of least surprise in order to get the security fix to users while we work on merging it. > If you don't upgrade to 2.2.7, are you going to backport all bugfixes to > 2.2.6 from now on? I maintain a few distro packages myself and I would > consider that a big pain point and waste of time. > I know of at least to parties how went with modifying a fork in the past > and they are not in a good place with their fork regarding effort, > bugfix, and security. Please don't add to that list, just please don't := -) > > Is there anything I can do to make you reconsider? > > Is there something that I can do upstream in the Expat code base to > smooth your path to Expat 2.2.8/2.3.0? As Jack explains, we cannot update Expat directly because it would force a rebuild of 7719 packages, due to the functional nature of Guix. Instead we use a special mechanism called "grafting"[0] to quickly deliver security updates to users, which replaces references to the vulnerable Expat with a fixed version. [0] https://www.gnu.org/software/guix/manual/en/guix.html#Security-Updates As long as the ABIs are compatible, this mechanism works well. But the grafting operation is fairly expensive and happens on end-user systems, so we do not do it without a good reason. I don't think there is much you can do other than continue to write good change logs. Thanks, and sorry for the misunderstanding! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl0o9UMACgkQoqBt8qM6 VPp4MAgAg60Qs8AIWtoRIUN81oWcqC1tyrnOS0IAhr4OdNt+38ssi7QAQCw1ShVm UQNa//cYxW0gCrc0MDSGLri7ySXQ+WghFOLmzWLu66j+3LYBCnAdtGi2Z+TVVqbB Wvd0uJYnqP79dSExeXX0uQc/3IsR+q8OOHYt6Dyf+8c/pR3tXjW9qxHsB7CG+/ua 1r9kvBDzq0A/M7kqwborCGyhqRUI35vDVY7vgabAWcT2HQz2cByqNzLF++U9uxAO RhiuajWDnSlOPB6UXvgv5xvMwP3r+GSDwBQ0TUQRhsWdu/b2kxaVXKIcN3UD7Hj3 NT1U7yNmFjvnlnhFEeImUGvj2EHyQQ== =4U6Z -----END PGP SIGNATURE----- --=-=-=--