[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 (https://notmuchmail.org) Emacs/26.2 (x86_64-pc-linux-gnu) |
Sebastian,
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]
>> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=5a836ce38c9c29e9c2bd306007347486b90c5064
>>
>> [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 — 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.
[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!
signature.asc
Description: PGP signature