Check binary consistency after grafting with e.g. ldd

DoneSubmitted by Léo Le Bouter.
Details
2 participants
  • Léo Le Bouter
  • Ludovic Courtès
Owner
unassigned
Severity
normal
L
L
Léo Le Bouter wrote on 18 Mar 11:37 +0100
(address . bug-guix@gnu.org)
22d6fde28a4646254061f56c342fb75d2a2846d9.camel@zaclys.net
Toggle quote (2 lines)>.
Basically Inkscape did not work because ImageMagick's soname had beenbumped (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 fileor directory
It seems technically possible to automatically check for this kind ofbreakage, therefore I suggest we run ldd (might actually run code fromthe binary) or objdump -x (pure static analysis), so after grafting wecould check that every binary can load all it's dependents declared inthe ELF headers successfully and report errors if not?
What do you think?
Léo
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBTLU0ACgkQRaix6GvNEKZJrg//Wdostj078M1GrVVw5Zi0WBgqQp2GEk10TE0a3gwmbcqOEjwzR1kk7lRcic4UqVVkhT/gu+89B3d+MXc1c9I/etHqZfAZmrBzNso26zi5qsmL2V/HA82KdQREfAO7ijsgavQoZ+8m/+k8oE7frlEkUqeTx57ZL++XQByOMGVK+Q+VRmPTt0Uej3MAUm1GqmOaA44W/Bbec6rf0lNKQ08v1kCGDbDRRqDrzkT4apiA/wYgYgCkS9JWKL0ItQaAbgSJj3AygHQwgZX/SGjFk3ZjdwnX0YHOfwg6VTLLT1KYdxJPy4EkYE+cVQ5Mv1mdMN9t0hJIgb3nWLs3Jha46WpTBPf2U7v2/kbH/HbD0FaZdrFV82k7gm8eh1l0neOyiEi19dtZr2OqCuobl6DhsQZndA7RD4+UtenMbVu5wQfX3bZiO+RuHIijPTs3jBd39RIfPfzJQ+80A+x7QxBX1bIy8yKCvWIOBtC/YQ5uo25XX/QhA9x2tHQvTbPFfrtLwRGXtmS6hR824fL1oBQnWwm8JCvodU80PqSnCEhBqR6dX1OeNZPx7ucGgJ7mLKFg7GgkziEYgv1RhV/uqF2bonXdgSQEV6ZDsqCOQledxB/DxQB+z6uw8DKiLldygPhZ+ZgiDoRTmLXCmMqkTrI8IigpN0ARkkUcTdhp21bnfUWQ1oM==Getz-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 18 Mar 14:38 +0100
(name . Léo Le Bouter)(address . lle-bout@zaclys.net)
878s6kpoon.fsf@gnu.org
Hi,
(Cc: Leo Famulari who has been taking care of many security issues inGuix over years.)
Léo Le Bouter <lle-bout@zaclys.net> skribis:
Toggle quote (20 lines)> 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 beautomated.
In particular, packagers who want to introduce a replacement for alibrary should use libabigail’s ‘abi-diff’ tool to check that thepackage and its replacement are ABI-compatible. It’s also a good ideato make some quick manual tests.
The .so file symlinks inhttps://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e0ff59f0cd836b156f1ef2e78791d864ce3cfcdlook very scary to me. To me, it’s likely to hide the ABIincompatibility issue rather than “fix” it.
Léo, please make sure to submit patches for review, as noted inhttps://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html.Such changes do not qualify as “trivial” and we should strive to getmore than one pair of eyeballs on it.
Leo F. has always done that, even with years of experience, and I thinkit’s been fruitful, even when that meant delaying the patch by a coupleof days.
The good thing with being a “rolling release” distro is that we canquickly roll out fixes; the bad thing is that we can just as quicklyroll out bugs. :-)
Thanks,Ludo’.
L
L
Léo Le Bouter wrote on 19 Mar 09:58 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)
ea674f0bd142d0f308f778b3e18205a01d895111.camel@zaclys.net
On Thu, 2021-03-18 at 14:38 +0100, Ludovic Courtès wrote:
Toggle quote (4 lines)> I don’t think all the testing that needs to be done when grafting can> be> automated.
Not all but part of it?
Toggle quote (6 lines)> 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.
That's great! Maybe we can have some quick tooling to in GNU Guix toaid that?
Toggle quote (7 lines)> 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.
:-/ Yes it is scary, we were having an user with an Inkscape issue onIRC and this commit fixed it for them and they could work without anissue though, we were discussing with rekado and rekado suggested wecheat like this and I've done it, the only alternative we have isporting/applying all patches to our version by digging commit history(with always the doubt of adding an incomplete fix which is likely ifwe have to dig commit history manually).
If nobody can put time to dig patches for all individuals CVEs until weungraft then I'd rather have this scary commit in.
Léo
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBUZ88ACgkQRaix6GvNEKZg/g//VpW5ff/cH8Y6Wz2x5CXlJYbLlcK4eOh6zcNMULwfbaSFx8ay+cUhv3X6M1zj19I1elqdx8nupsFDV1l3J71PR+TddKmQD/7Q3Ke40BLva3eurr8fOBqJXepnUbA5Da4aBbZxLppU0K0HtO6oxQjEsMnBaLfHMliFXnKeufEi8f81gqHJwjLKsv8eSLboBw9vRrV1pakFDHNYBWznNdUHDNSteE8ql/5xPpwoV5bsECvW86yNBfczL/qVJpCluT+zaORLomlz2X46xDWleh4dvEiRdl4l2JmySzsRbqcfX55nof1dmvKBxBQ1wMnr82dXSzg1pCy413Ist5iNVU6HxeLNrVr/T/Y9QRpYBm+X/v/6ziGZMmDN3+6yb55y4hq91C9z2T0/lWVdd4pmofYGEhwUs419mP2kE36AFgp19JMPMOV09WIbx6VQuPUouygDc8p7Q/TCPbsh8ZwJ1m4bOVAFnxm7Jij1bxx3azcOlpmHAabkhunQYcLw7tCzbdnOKStUapflqHW+qXL++qf0xKUxnBZhai789qSNlYtxEYYtsdrnmGNRolSQAYgeeUdYjueZbdqZ47zb/HWDNK4Mvw5pGIDyGsAFtKmjliPKvWHGivZqa0H9Vy0p0iSrqgJD7WRsPgTPCm4qFpP/BdoGEfascIqAKDO9f2CZe/fplX0==uyW9-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 19 Mar 11:39 +0100
(name . Léo Le Bouter)(address . lle-bout@zaclys.net)
87sg4rfmvj.fsf@gnu.org
Hi,
Léo Le Bouter <lle-bout@zaclys.net> skribis:
Toggle quote (7 lines)> On Thu, 2021-03-18 at 14:38 +0100, Ludovic Courtès wrote:>> I don’t think all the testing that needs to be done when grafting can>> be>> automated.>> Not all but part of it?
Not even sure; at least I don’t have any ideas.
Toggle quote (9 lines)>> 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.>> That's great! Maybe we can have some quick tooling to in GNU Guix to> aid that?
Again it’s on a case-by-case basis, it depends on what you’re grafting,so I wouldn’t know how to do that.
Perhaps a first step would be consolidate this “insider knowledge” aboutsecurity updates and grafts into a check list.
Toggle quote (15 lines)>> 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.>> :-/ Yes it is scary, we were having an user with an Inkscape issue on> IRC and this commit fixed it for them and they could work without an> issue though, we were discussing with rekado and rekado suggested we> cheat like this and I've done it, the only alternative we have is> porting/applying all patches to our version by digging commit history> (with always the doubt of adding an incomplete fix which is likely if> we have to dig commit history manually).
It’s the kind of patch that should be reviewed before it gets in.
In this case, review will have to happen after the fact, but it stillhas to happen IMO. I’d prefer not to do it myself; perhaps Leo F. cantake a look?
Toggle quote (3 lines)> If nobody can put time to dig patches for all individuals CVEs until we> ungraft then I'd rather have this scary commit in.
Security is a spectrum; we’ll never close all CVEs. :-)
Security issues often call for quick reaction, but to me that doesn’tmean we should dismiss our practices and workflow, in particular peerreview.
Thanks,Ludo’.
L
L
Ludovic Courtès wrote on 30 Mar 08:50 +0200
control message for bug #47228
(address . control@debbugs.gnu.org)
87czvhkudy.fsf@gnu.org
tags 47228 notabugclose 47228quit
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 47228@debbugs.gnu.org