Adam Jackson wrote:
> You can compute this statically. You know the DT_NEEDED tree for every
> dynamic object.
… only if dlopen is not used (which, as I am going to explain below, is not
anywhere near as harmless as you think).
> For applications that don't call dlopen (themselves or in their
> dependencies), that's good enough, any instance of two conflicting
> libraries in the same tree is a bug.
Sure, but most non-trivial applications do call dlopen somewhere, so this
statement, while technically true, is entirely useless in practice.
> For callers of dlopen you also add every possible plugin they might load
> to the tree.
Every single shared library on the system is a "possible plugin they might
load". Therefore, the result you will get is again entirely useless. (All
applications are in the potentially conflicting set.)
And this is not purely theoretical, there are applications (and libraries)
dlopening all sorts of system libraries, from OpenSSL to GTK+, directly (not
through a plugin that is linked to the system library) for varying reasons.
And yes, this GTK+ example is real:
$ nm -D /usr/lib64/libQtGui.so.4 | grep Gtk
0000003ffee56680 T _ZN9QGtkStyle11qt_metacallEN11QMetaObject4CallEiPPv
0000003ffee56630 T _ZN9QGtkStyle11qt_metacastEPKc
[snip 32 lines]
0000003fff2d7e40 V _ZTI9QGtkStyle
0000003ffeec09a4 V _ZTS9QGtkStyle
0000003fff2d7e80 V _ZTV9QGtkStyle
so QGtkStyle is defined here, not in a plugin, but:
$ ldd /usr/lib64/libQtGui.so.4 | grep gtk
[nothing]
(This is GTK+ 2, by the way.)
An application linking both GTK+ 3 and Qt 4 will crash if and only if the
QGtkStyle ends up getting used at runtime (which is a decision at C++ class
level, not at file level). Good luck figuring that out with automated static
analysis, especially on the binaries only.
> In any case you may get false positives, but you'll get no false
> negatives.
Either you get essentially the whole distribution as false positives (which
makes the results entirely useless) or you WILL get false negatives.
> The rest of your argument reduces to "we haven't written the tool to do
> that yet", which, fair enough, but we're talking maybe 500 lines of
> python, and an optional and small amount of package metadata to trim
> the false-positive tree for dlopen.
The go ahead and write that tool. But I think you are underestimating the
difficulty (see above).
> If you consider that scale of problem to be a "giant scary minefield" I'm
> not sure we have common grounds for communication.
The mere fact that it is possible to develop a minesweeper (which we don't
even have yet) does not mean we are not in front of a minefield.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
