GNU bug report logs - #47228
Check binary consistency after grafting with e.g. ldd

Previous Next

Full log

Message #8 received at 47228 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Léo Le Bouter <lle-bout <at> zaclys.net>
Cc: 47228 <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#47228: Check binary consistency after grafting with e.g. ldd
Date: Thu, 18 Mar 2021 14:38:16 +0100

Hi,

(Cc: Leo Famulari who has been taking care of many security issues in
Guix over years.)

Léo Le Bouter <lle-bout <at> zaclys.net> skribis:

> We had an issue after grafting ImageMagick fixed by <
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd
>>.
>
> Basically Inkscape did not work because ImageMagick's soname had been
> bumped (probably for forward compat?):
>
> /gnu/store/g75q5v1gqi4x08qcf1ydfl9xhp4slmxy-inkscape-
> 1.0.2/bin/.inkscape-real: error while loading shared libraries:
> libMagickCore-6.Q16.so.6: cannot open shared object file: No such file
> or directory
>
> It seems technically possible to automatically check for this kind of
> breakage, therefore I suggest we run ldd (might actually run code from
> the binary) or objdump -x (pure static analysis), so after grafting we
> could check that every binary can load all it's dependents declared in
> the ELF headers successfully and report errors if not?
>
> What do you think?

I don’t think all the testing that needs to be done when grafting can be
automated.

In particular, packagers who want to introduce a replacement for a
library should use libabigail’s ‘abi-diff’ tool to check that the
package and its replacement are ABI-compatible.  It’s also a good idea
to make some quick manual tests.

The .so file symlinks in
<https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd>
look very scary to me.  To me, it’s likely to hide the ABI
incompatibility issue rather than “fix” it.

Léo, please make sure to submit patches for review, as noted in
<https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html>.
Such changes do not qualify as “trivial” and we should strive to get
more than one pair of eyeballs on it.

Leo F. has always done that, even with years of experience, and I think
it’s been fruitful, even when that meant delaying the patch by a couple
of days.

The good thing with being a “rolling release” distro is that we can
quickly roll out fixes; the bad thing is that we can just as quickly
roll out bugs.  :-)

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.