Bug#1090077: GNOME Secrets (arch: all) hard-codes the use of OpenSC's shared object for the build arch (amd64) as the PKCS11 module to use

John Scott jscott at posteo.net
Mon Feb 10 07:52:08 GMT 2025


Control: retitle -1 Secrets hard-codes OpenSC's PKCS11 module wrongly (cross-arch) and crashes trying to use it
Control: found -1 10.4-1
Control: severity -1 important
Justification: buildd architecture adversely affects artifacts in arch: all package

Hello,

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20250210/ea91461a/attachment-0001.sig>


More information about the pkg-gnome-maintainers mailing list