bug#24703: Store references in 8-byte chunks in compiled code

[Mark H Weaver <mhw@netris.org>]

ludo@gnu.org (Ludovic Courtès) writes:

> Török Edwin <edwin+ml-guix@etorok.net> skribis:
>
>> On 2016-10-16 22:04, Ludovic Courtès wrote:
>>> Mark H Weaver <mhw@netris.org> skribis:
>>> 
>>>> When grafting, how will we achieve confidence that we've found the
>>>> correct occurrence of the last character?  I think we will have to give
>>>> up our recently added feature of being able to change the version number
>>>> of grafts.
>>> 
>>> Wait, don’t jump to the conclusions.  :-)
>>
>> I've just encountered the same problem with fontconfig (after installing GuixSD, running guix pull and guix system reconfigure, --no-grafts was required).
>> Would it be possible for the grafts to keep a symlink (somehow
>> registered to be part of the grafted fontconfig so that guix gc
>> doesn't remove it) instead of patching the binaries?
>> /gnu/store/<old-hash>-fontconfig-2.11.94 -> /gnu/store/<grafted-hash>-fontconfig-2.11.94
>
> We could use a self symlink, or we could use something like
> <http://git.savannah.gnu.org/cgit/guix.git/commit/?id=9d50da70608de32d9db0c29859caec6f2cddb95f>.
>
> Mark, WDYT?
>
> What remains to be seen is how many packages are affected by this issue,
> and whether a generic solution needs to be found.

Unfortunately, it is too widespread.  As I just pointed out in

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24712#13

Among the many packages that include these obfuscated store references,
one is 'glibc-final'.  My attempt to graft 'bash' in 'master' to fix
CVE-2016-0634 and CVE-2016-7543 has resulted in a system where I cannot
build *any* derivation, because 'guile-final' crashes during boot while
its 'glibc-final' tries to find its 'gconv' modules in the ungrafted
'glibc-final', which is not available in the build environment.

So, if our approach is to use -fno-builtin-strcpy, then we will have to
apply it system-wide, and rebuild all of 'core-updates' from scratch.

I've been investigating another approach: to enhance our scanner and
grafter to handle these 8-byte-chunked references.  I believe it is
feasible, but only if we abandon the ability to change the file names of
grafts outside of the hash.  The reason is that the hash portion of
store references are surrounded by enough other known characters on both
sides that the hash portion is almost always contained entirely within
8-byte chunks.

To be continued...

     Mark