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

[ludo@gnu.org (Ludovic Courtès)]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> civodul pushed a commit to branch core-updates
>> in repository guix.
>>
>> commit 503a4df904b8d4b82caebdb17db9c5f76a952418
>> Author: Ludovic Courtès <ludo@gnu.org>
>> 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?

Simply to remove redundant lines.

> 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.

OK, I agree.

> 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?

First, we could mark the ‘replacement’ field as “innate”, which means it
will never be inherited (like the ‘location’ field.)  Like you, I can’t
think of a situation where inheriting the replacement makes sense.

Then ‘package/inherit’ seems to be doing the rest of the job correctly.
The bad thing is that it’s easy to forget to use it.  If we’re
motivated, we could hack this feature (let’s call it “recursive
inheritance”) right into (guix records).

Thoughts?

Thanks,
Ludo’.