Control: severity -1 serious On Mon, Feb 10, 2025 at 2:57 AM John Scott <jsc...@posteo.net> wrote: > I did some additional digging. My worst fear was realized: Secrets appears to > make the bogus assumption that OpenSC's PKCS11 module is the one to use, and > Secrets does not specify any relationship with the opensc-pkcs11 package. > This is coded into the package here: > https://gitlab.gnome.org/World/secrets/-/blob/master/gsecrets/meson.build#L11 > > As you can see, the build system never makes any inquiry as to where the > module is located but bakes a magic path into the final program, assuming > instead that 'opensc-pkcs11.so' is located in the architecture-dependent > directory where shared objects are normally kept. (Note that PKCS11 modules > are never really supposed to be linked against, so they can hardly be called > "libraries" in the first place.) However, Secrets is an Architecture: all > Python package, so this has the very bizarre side effect of trying to find > the amd64 shared object at runtime even when running Secrets on a different > machine. > For example, I alluded in my first message on this bug that this could be a > simple missing dependency, albeit a very poor and troubling dependency. I > installed opensc-pkcs11 on my arm64 machine, but I got this error: > src/dyn_unix.c:34:SYS_dyn_LoadLibrary() > /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so: cannot open shared object file: > No such file or directory > 10-02-25 02:41:07 | WARNING | Could not load pkcs11 library: Load > (/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so) > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/gsecrets/provider/pkcs11_provider.py", > line 158, in pkcs11_refresh > self._pkcs11.load(const.PKCS11_LIB) > ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/PyKCS11/__init__.py", line 481, in load > raise PyKCS11Error(rv, pkcs11dll_filename) > PyKCS11.PyKCS11Error: Load (/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so) > > Therefore this functionality has probably not worked for very many, > especially not on a system with multiarch filesystem paths like Debian. As a > short-term fix, maybe this line can be patched downstream to find OpenSC for > the native dpkg architecture and an appropriate Suggests added: > https://gitlab.gnome.org/World/secrets/-/blob/master/gsecrets/provider/pkcs11_provider.py#L158
I wonder if we are allowed to fix this issue by switching Secrets from Architecture: all to Architecture: any In addition to what you wrote, this file /usr/lib/python3/dist-packages/gsecrets/const.py contains this line: PKCS11_LIB = "/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so" Thank you, Jeremy Bícha
