Comment 1 for bug 2016439

As I understand it, libnsspem.so is the one in the "wrong" place:

/usr/lib/$ARCH/nss/libnsspem.so

A quick apt-file search on lunar shows that is the only package that puts something in /usr/lib/$ARCH/nss.

I appended this config to my ~/.pki/nssdb/pkcs11.txt file to test search paths:

  library=libnsspem.so
  name=PEM_plugin

And ran this test command with strace:

  certutil -d ~/.pki/nssdb -U

It shows the search path for the library:
  143458 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnsspem.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  143458 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnsspem.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  143458 openat(AT_FDCWD, "/lib/libnsspem.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  143458 openat(AT_FDCWD, "/usr/lib/libnsspem.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

So yes, /usr/lib/$ARCH/nss is not searched for. Which means it's an odd placement choice decision from the src:nss-pem package. Or maybe src:nss should include that nss/ subdirectory in its search path.

In any case, back to the current bug.

It looks like a minimal patch would be to leave libnssckbi.so alone, as that will be found in the standard paths if I define it without an absolute path in pkcs11.txt:

  library=libnssckbi.so
  name=Mozilla Root Certs
  NSS=trustOrder=100

And strace:

  143993 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnssckbi.so", O_RDONLY|O_CLOEXEC) = 7

So how about just patching the libnsspem.so path? And reverting the change to the
`static const char *trust_library` path all the way back so it's just "libnssckbi.so"?

On a second note, has this been tested in other architectures, to be sure the _DEB_HOST_ARCH replacement is correct there as well? I'm thinking ppc64el vs ppc64le, for example, and whether the linux-gnu suffix is always used correctly.