[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Expat 2.2.7 with security fixes has been released / CVE-2018-20843

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
User-agent: Notmuch/0.29.1 ( Emacs/26.2 (x86_64-pc-linux-gnu)


Thank you very much for reaching out downstream!

Sebastian Pipping <address@hidden> 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].
>> Many thanks to Marius Bakke for advice and patience while reviewing the
>> patches.
>> [0]
>> [1]
> 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 — the opposite of something to rely on.  They made that choice,
> it should be their cost.
> openSuse started using -fvisibility=hidden 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.


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!

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]