Re: 01/01: gnu: glibc/linux: Add patches for CVE-2017-1000366.

[Mark H Weaver]

Hi Ludovic,

address@hidden (Ludovic Courtès) writes:

> civodul pushed a commit to branch core-updates
> in repository guix.
>
> commit 503a4df904b8d4b82caebdb17db9c5f76a952418
> Author: Ludovic Courtès <address@hidden>
> Date:   Thu Jun 29 12:53:14 2017 +0200
>
>     gnu: glibc/linux: Add patches for CVE-2017-1000366.
>     
>     * gnu/packages/patches/glibc-CVE-2017-1000366-pt1.patch,
>     gnu/packages/patches/glibc-CVE-2017-1000366-pt2.patch,
>     gnu/packages/patches/glibc-CVE-2017-1000366-pt3.patch: New files.
>     * gnu/local.mk (dist_patch_DATA): Add them.
>     * gnu/packages/base.scm (glibc/linux)[source](patches): Add them.
>     [replacement]: Remove.
>     (glibc-2.25-patched): Remove.
>     (glibc-2.24, glibc-2.23, glibc-2.22, glibc-2.21)
>     (glibc-locales): Remove 'replacement' field.

Why did you remove the (replacement #f) fields from glibc-2.24,
glibc-2.23, glibc-2.22, and glibc-2.21?  Keeping the inherited
replacements will never do the right thing here, because the inherited
replacement will always be for a newer version of glibc.

It would be nice to have things arranged in such a way that we can
simply add a replacement for 'glibc/linux', when needed.  We did that
work for CVE-2017-1000366.  It would be good not to revert that work,
to facilitate future security updates.

More generally, I think we need to give more thought to how to handle
'replacement' fields when we inherit packages, in order to do the right
thing when the inherited package is grafted.  One way is to override
(replacement #f).  Another is to use the 'package/inherit' macro from
(guix packages), which applies the same overrides to the replacement.
I can't think of a case where it's proper to leave the 'replacement'
unchanged when inheriting a package.

What do you think?

      Mark