Sebastian,

Thank you very much for reaching out downstream!

Sebastian Pipping <sebastian@pipping.org> 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!