[Pkg-owncloud-maintainers] Bug#922489: qtkeychain: relies on existence of libsecret-1.so -dev symlink

[Simon McVittie]

Control: reassign -1 qtkeychain 0.9.1-1
Control: retitle -1 qtkeychain: relies on existence of libsecret-1.so -dev symlink

On Sun, 17 Feb 2019 at 00:21:55 +0100, Sandro Knauß wrote:
> qtkeychain is using libsecret as a backend to request passwords. ldd is
> showing me that it is linked against libsecret-1.so.0 (fine). But strace
> shows one sucessfull read of libsecret-1.so.0 (fine) but afterwards, it
> tries to load libsecret-1.so without success (as libsecret-1-dev is not
> installed). If I create this symlink from libsecret-1.so ->
> libsecret-1.so, qtkeychain can load/store successfully passwords.

Sorry, this is not how shared libraries are packaged in
Debian. libsecret-1-0 must not contain the libsecret-1.so symlink. If it
did, it would not be co-installable with a future libsecret-1-1, defeating
a large part of the purpose of having an ABI version in the name.
(See Debian Policy §8.)

> For me this looks like an error in libsecret, as qtkeychain only imports
> libsecret/secret.h in libsecret.cpp [0]. Or maybe the usage in that file
> is wrong or cmake screws things up...

I think this is a qtkeychain bug. This code that appears to be responsible
for dlopen()ing libsecret:

    LibSecretKeyring::LibSecretKeyring()
        : QLibrary("secret-1")

doesn't mention the ABI version, so it could equally easily end up loading
an incompatible future library libsecret-1.so.1 or libsecret-1.so.27,
and then crashing when it calls a function by assuming that it has the
same ABI as the corresponding function in libsecret-1.so.0.

I haven't programmed against Qt for years, but the documentation
suggest that it should probably inherit from QLibrary("secret-1", 0)
as described at <https://doc.qt.io/qt-5/qlibrary.html#QLibrary-2>,
so that Qt will specifically load libsecret-1.so.0 on Unix platforms.

    smcv