The solution is to include a relative path in your installed module config files. This way p11-kit will load the so file from the appropriate /usr/lib/pkcs11 or /usr/lib64/pkcs11 directory. Please see: --with-module-path

We tried several ways to solve this in 2011, and eventually this solution was suggested by Debian and Fedora guys:

http://lists.freedesktop.org/archives/p11-glue/2011-September/000056.html

Essentially we expect distros to install architecture independent module config files.

This solution not only works for installed module config files (in /usr/share/p11-kit/modules) but for admin provided module config files (in /etc/pkcs11/modules) and user configured module config files (in ~/.config/pkcs11/modules). As you can see we need a multilib solution that works for all of the above locations.

The only recent change was the separation of admin provided module config files (in /etc/pkcs11/modules) from distro installed module config files (in /usr/share/p11-kit-modules). This did not change the fact that the best practice is to use architecture independent module configs.

More documentation of 'module:' here:

http://p11-glue.freedesktop.org/doc/p11-kit/pkcs11.conf.html

If Arch really does have special needs here, I would also accept a patch that allows you to pass a --with-default-config, which would allow you to use a different path for distro installed module configs.

(In reply to comment #0)
> Git commit 85751aa21dd9b93d8eb51e36767b5564ce6ce005 

As noted above this does not change the status quo, it separates the uses of  /usr/share and /etc. Module configs generally shouldn't be architecture dependent. If Arch has a good reason to be different here and make module configs be architecture dependent, I would accept a patch for --with-default-config as noted above. Please reopen this bug if you wish to take this approach.

> (and probably commit
> a9790a21302f47016a88ba9a2c904bed11efb388 as well) violate this principle

Indeed. This was remedied in commit 3e5916530b995bda1a5deea7ecf9c185a402d463

We already use module config files with relative paths on Archlinux (on x86_64, the regular 64bit modules get put into /usr/lib/pkcs11/ and their lib32counterparts get put into /usr/lib32/p11-kit/). Yet, that doesn't solve the problem that the configuration files are architecture dependent (even if they contain relative paths), because they control the loading of architecture dependent module binaries. We essentially have one package for the 64bit version and one package for the 32bit version of a packge - yet they use the same module configuration files because you put them into /usr/share/p11-kit/modules/ (where they don't belong IMHO as they *are* platform dependent).

If you have installed p11-kit (64bit), gnome-keyring (64bit), lib32-p11-kit (32 bit), but *not* lib32-gnome-keyring (32bit), 32bit applications using lib32-p11-kit will work, but throw errors nonetheless because p11-kit complains about missing module files (lib32-p11-kit reads the module configuration file of the 64bit gnome-keyring package but doesn't find the corresponding 32bit module binary in /usr/lib32/pkcs11/ because you don't have installed the lib32-gnome-keyring package).

IMHO the best way would be to have said module configuration files not in /usr/share/ but in /usr/lib/, with an option in the configure script to put them into /usr/lib32/ for lib32-packages. That way, p11-kit wouldn't throw any errors, and package maintainers could create different p11-kit packages for multilib systems where the single packages would be mutually independent, and would not have to rely on the module configuration files of the "main architecture" packages. So in my case, lib32-p11-kit would have it's own module configuration directory/files and would not have to rely onto the 64bit p11-kit package's module configuration.

This is obviously not solved by using --with-module-path as it exists today. Would you accept a patch making not only the location of the module binaries but also of these modules' configuration files dependent on the location specifies by --with-module-path ?

I imagine something like

./configure --prefix=/usr --libdir=/usr/lib --sysconfdir=/etc --with-module-path=/usr/lib/pkcs11

with the module binaries ending up in /usr/lib/pkcs11/modules/ and their configuration files ending up in /usr/lib/pkcs11/config/ (for the 64bit package).

For the 32bit lib32-package, it would look like this:

./configure --prefix=/usr --libdir=/usr/lib32 --sysconfdir=/etc --with-module-path=/usr/lib32/pkcs11

with the module binaries in /usr/lib32/pkcs11/modules/ and their config files in /usr/lib32/pkcs11/config/.

I'd be willing to cook up a patch but I have to admit I don't have a lot of experience with writing configure and Makefile scripts, so it might take a few days.

(In reply to comment #2)
> We already use module config files with relative paths on Archlinux (on
> x86_64, the regular 64bit modules get put into /usr/lib/pkcs11/ and their
> lib32counterparts get put into /usr/lib32/p11-kit/). Yet, that doesn't solve
> the problem that the configuration files are architecture dependent (even if
> they contain relative paths), because they control the loading of
> architecture dependent module binaries. We essentially have one package for
> the 64bit version and one package for the 32bit version of a packge - yet
> they use the same module configuration files because you put them into
> /usr/share/p11-kit/modules/ (where they don't belong IMHO as they *are*
> platform dependent).

What makes them platform dependent. Are they different for different architectures? Or is this a problem where, even though they're identical, your packaging system won't allow them to be installed by multiple packages in the same place?

> If you have installed p11-kit (64bit), gnome-keyring (64bit), lib32-p11-kit
> (32 bit), but *not* lib32-gnome-keyring (32bit), 32bit applications using
> lib32-p11-kit will work, but throw errors nonetheless because p11-kit
> complains about missing module files (lib32-p11-kit reads the module
> configuration file of the 64bit gnome-keyring package but doesn't find the
> corresponding 32bit module binary in /usr/lib32/pkcs11/ because you don't
> have installed the lib32-gnome-keyring package).

For what it's worth, libgnome-keyring has nothing to do with pkcs11. But I'm not familiar with your package names, so maybe you mean something else here.

But I think I understand: p11-kit complains (on stderr) for 32-bit apps where the equivalent 32bit pkcs11 module is not installed.

> IMHO the best way would be to have said module configuration files not in
> /usr/share/ but in /usr/lib/, with an option in the configure script to put
> them into /usr/lib32/ for lib32-packages. That way, p11-kit wouldn't throw
> any errors, and package maintainers could create different p11-kit packages
> for multilib systems where the single packages would be mutually
> independent, and would not have to rely on the module configuration files of
> the "main architecture" packages. So in my case, lib32-p11-kit would have
> it's own module configuration directory/files and would not have to rely
> onto the 64bit p11-kit package's module configuration.
> 
> This is obviously not solved by using --with-module-path as it exists today.
> Would you accept a patch making not only the location of the module binaries
> but also of these modules' configuration files dependent on the location
> specifies by --with-module-path ?

No, this breaks compatibility. The path /usr/lib/pkcs11 is not only used by p11-kit, but also by other solutions:

http://wiki.cacert.org/Pkcs11TaskForce

I'm really not keen on going through the trouble of moving the modules or the configs. But if you want to handle this in Arch, I'm not going to stop you, and see below for a configure argument to facilitate you.

Such a solution also only works for distro installed binaries, and does not solve the same issue for admin installed pkcs11 modules, or user installed pkcs11 modules. The exact same issue remains:

It is a common theme that 32-bit programs need equivalent packages installed as their 64-bit cousins in order to behave similarly. I do not see this as a big surprise. But if you insist on solving it, at the price of Arch distro complexity, that's fine with me.

I've already outlined a similar solution, for which I will accept a patch, although if you want to suggest a better option name you can. Let me explain it better:

We already have two configure options:

--with-system-config: this controls the location of admin provided p11-kit
       configuration and defaults to: /etc/pkcs11
--with-user-config: this controls the location of user provided p11-kit
       configuration and defaults to: ~/.config/pkcs11

So by adding a third similar configure option we can allow Arch to have a per build location for *distro* provided config. The option might be called:

--with-module-config: this controls the location of installed (by distro or
       system builder) module configuration and defaults
       to: /usr/share/p11-kit/modules

Hope that makes sense. And I hope that such a patch should be simple to implement.

FYI: In general the theme with p11-kit is to help disparate libraries and applications share the same set of pkcs11 modules. Thus it is not a surprise that module config is designed to be arch independent. In an ideal world 32-bit and 64-bit modules would be installed together to accomplish this. However I realize that the way distros are currently setup doesn't cater to this.

Created attachment 84099 [details] [review]
add --with-module-config parameter to the configure script

> What makes them platform dependent. Are they different for different
> architectures? Or is this a problem where, even though they're
> identical, your packaging system won't allow them to be installed by
> multiple packages in the same place?

Our packaging system won't allow us to have a file installed by multiple packages in the same place, but that doesn't have much to do with the problem here.

Yet I think that it would still make sense to treat each installed package version of p11-kit as an "atomic entity" with its own configuration file and without having simultanously installed packages of different architectures share the same configuration files. If you want to share the config, you still can easily do that by using (for example) symlinks.

I've hacked together a patch (see attachment), but please double-check it because I'm not very familiar with writing configure scripts.

My patch just contains the changes for configure and configure.ac, but not the subsequent changes caused by running aclocal and automake. Please tell me if you want to have those in the patch as well.

Created attachment 84139 [details] [review]
Add --with-module-config parameter to the configure script

Tweaked patch to fix bug when --with-module-config isn't specified.

Attachment 84139 [details] pushed as 2978f8f - Add --with-module-config parameter to the configure script