all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jack Hill <jackhill@jackhill.us>
To: Sebastian Pipping <sebastian@pipping.org>
Cc: guix-devel@gnu.org
Subject: Re: Expat 2.2.7 with security fixes has been released / CVE-2018-20843
Date: Fri, 12 Jul 2019 16:12:13 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.20.1907121551200.9756@marsh.hcoop.net> (raw)
In-Reply-To: <9ba7e06a-e907-4703-7aa4-1c46961786ad@pipping.org>

[-- Attachment #1: Type: text/plain, Size: 3214 bytes --]

Hi Sebastian,

On Fri, 12 Jul 2019, Sebastian Pipping wrote:

> On 12.07.19 01:17, Jack Hill wrote:
>> 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].
>>
>> [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.
>
> 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?

I'm far from a Guix expert, so if I get something wrong I hope others will 
jump in to correct me. Before I get into Guix details, though, the future 
of new versions of Expat in Guix looks good. Version 2.2.7 is available in 
our core-updates branch [2], which will hopefully be merged into the 
released version soon (it was recently frozen for final stabilization, 
fixes, and package building) [3].

[2] http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/xml.scm?h=core-updates#n69
[3] https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00157.html

However, I also wanted to make the DoS fix available in the current Guix 
master. Changing a package in Guix requires all of its dependent packages 
to be rebuild. Expat has so many dependent packages (yay) that this would 
be too disruptive to do without the extra process around staging it in a 
separate branch first. For security fixes, which we want to provide as 
quickly as possible, there is a mechanism, grafting, for changing a 
package without triggering rebuilds of the dependent packages [4]. 
Grafting implies doing a binary-path of all the dependent packages to 
refer to the fixed Expat version instead of the one they were originally 
build against. Therefore, we are extra-cautious about what changes are 
introduced via grafts.

[4] https://guix.gnu.org/manual/en/html_node/Security-Updates.html

I appreciate your willingness to adjust future Expat versions to make it 
easier for us. I don't think this will be necessary. Other Guix folk 
(Marius?), is this correct?

All the best,
Jack

  reply	other threads:[~2019-07-12 20:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 22:21 Expat 2.2.7 with security fixes has been released / CVE-2018-20843 Sebastian Pipping
2019-07-11 23:17 ` Jack Hill
2019-07-12 19:29   ` Sebastian Pipping
2019-07-12 20:12     ` Jack Hill [this message]
2019-07-12 21:01     ` Marius Bakke
2019-07-13 16:21       ` Sebastian Pipping

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1907121551200.9756@marsh.hcoop.net \
    --to=jackhill@jackhill.us \
    --cc=guix-devel@gnu.org \
    --cc=sebastian@pipping.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.