On Mon, 29 Jun 2020 at 15:33:48 +0100, Simon McVittie wrote:
> On Sun, 28 Jun 2020 at 15:45:41 +0200, Chris Hofstaedtler wrote:
> > We seem to have multiple problems here:
> >
> > 1) Software that is not shipped by Debian and uses a statically
> > linked or private copy of libssl crashes, because libmount1 pulls
> > in libssl1.1, transitively.
> ...
> > 2) Some part of libmount1 or libcryptsetup1 introduces a memory
> > corruption, which is "found" by libjansson users.
>
> Also json-glib users, probably (all of json-c, jansson and json-glib
> collide at json_object_iter_next()).
Given the number of moving parts involved in this, and the fact that the
verity feature is specifically described as experimental in the upstream
release notes, would you be willing to consider reverting the enablement
of the cryptsetup feature until there is at least a concrete plan for
a solution? This would reopen #951048, but would at least temporarily
resolve #963721, #963525 and #963933, and would mitigate #963932. Then we
can do a coordinated transition with everything happening in the right
order, when we know what that order is.
Some possible angles to attack this from:
- not enabling the feature
- enabling the feature, but via dlopen rather than linking libcryptsetup
normally (the developer who added verity support to util-linux seemed
to be in favour of this, although I've lost the relevant tab and can't
find a URL right now, sorry)
- enabling the feature, but via invoking a helper subprocess
- json-c, libjansson and json-glib *all* gaining versioned symbols
(but the maintainer of json-glib has previously rejected requests to
add versioned symbols, and this doesn't work unless all three libraries
do it)
- at least two of json-c, libjansson and json-glib renaming their public
symbols (the maintainer of json-glib already rejected this, and
the maintainers of the others are likely to be equally reluctant to
break ABI)
- GLib moving from normal linking of libmount to dlopen with RTLD_LOCAL
in order to mitigate this by not pulling libmount into everything in
the GLib/GNOME/MATE/Cinnamon/XFCE/LXDE ecosystem
(but the GLib upstream maintainers don't like this idea and think
low-level libraries like libmount should avoid gaining significant
dependencies, instead)
- changing how Steam links OpenSSL (we cannot do this unilaterally, only
its upstream maintainers can; I've raised this upstream with various
suggestions, but it would involve significant restructuring, so don't
expect immediate results)
- changing how other proprietary binary-only software like Minecraft
links OpenSSL (we cannot do this unilaterally, only its upstream
maintainers can)
Thanks,
smcv
