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

[Jeremy Bícha]

Control: severity -1 serious

On Mon, Feb 10, 2025 at 2:57 AM John Scott <jscott at 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