Red Hat Bugzilla – Bug 915818
Preparing NSS for SharedSystemCertificates
Last modified: 2013-05-03 15:36:32 EDT
This is a preparation task for
For Fedora 19, we want to introduce a drop-in replacement for libnssckbi.so
The drop in replacement will likely be contained in the p11-kit.rpm package.
- NSS continues to ship a libnssckbi.so file,
however under a new name
- the drop-in replacement shipped by p11-kit is also shipped
under a new name
- use the http://fedoraproject.org/wiki/Packaging:Alternatives
approach that uses symbolic link to select one or the other.
- use a low priority number for libnssckbi.so shipped by NSS
- use a high priority number for the replacement shipped by p11-kit
In order to prepare for that new world, we should prepare the NSS package
as soon as possible to make use of the alternatives system.
This means, we need an update to NSS that:
- ships libnssckbi.so under a different name,
I propose: libnssckbi.so
- setup symbolic links using the alternatives system.
I suspect this will be the only NSS-related change necessary for the new system feature.
I would like to ensure that things don't break when upgrading/downgrading between packages that ship libnssckbi.so as a full file, and those newer packages that ship it as a symbolic link.
For that reason, I already made experiments, and I have example .spec files including post/pre scripts, that seem to solve the problem for me.
In case you are interested, I would like you to be able to experiment with the proposed upgrade/downgrade solution, and to review the scripts. I'm therefore attaching the "dummy" packages I used for testing.
Created attachment 702958 [details]
a dummy.src.rpm, using NSS existing approach - regular lib.so
Created attachment 702959 [details]
a dummy.src.rpm, new proposed approach - lib.so as alternative symbolic link
Created attachment 705495 [details]
Patch for nss.spec
Comment on attachment 705495 [details]
Patch for nss.spec
Created attachment 705665 [details]
Using this patch, we get the following files on a multiarch system:
[root@localhost ~]# ls -ld /usr/lib*/libnssckbi.so* /etc/alternatives/*nssckbi* /usr/lib*/nss/*.so
lrwxrwxrwx. 1 root root 26 Mar 5 15:28 /etc/alternatives/libnssckbi.so -> /usr/lib/nss/libnssckbi.so
lrwxrwxrwx. 1 root root 28 Mar 5 15:28 /etc/alternatives/libnssckbi.so.x86_64 -> /usr/lib64/nss/libnssckbi.so
lrwxrwxrwx. 1 root root 38 Mar 5 15:28 /usr/lib64/libnssckbi.so -> /etc/alternatives/libnssckbi.so.x86_64
-rwxr-xr-x. 1 root root 616568 Mar 5 15:13 /usr/lib64/nss/libnssckbi.so
lrwxrwxrwx. 1 root root 31 Mar 5 15:28 /usr/lib/libnssckbi.so -> /etc/alternatives/libnssckbi.so
-rwxr-xr-x. 1 root root 467308 Mar 5 15:13 /usr/lib/nss/libnssckbi.so
Scratch build with the patch:
FYI, of course, the %check exit 0 isn't meant to get included.
I use it for quicker turnaround while working on the package scripts.
Ready for testing in rawhide.
Some apps such as EVolution
Oops. Some apps such as Evolution are already updated to use the NSS shared system database, finding certs and keys in /etc/pki/nssdb and then ~/.pki/nssdb.
Are we limiting our focus *only* to certs, for now? It would have been good to move all apps to the shared system database, and the new p11-kit modules could have been loaded from /etc/pki/nssdb/pkcs11.txt rather than needing a hacked nssckbi.so.
What *should* NSS-using applications be doing, ideally?
(In reply to comment #11)
> Oops. Some apps such as Evolution are already updated to use the NSS shared
> system database, finding certs and keys in /etc/pki/nssdb and then
> Are we limiting our focus *only* to certs, for now?
Yes for now.
> It would have been good
> to move all apps to the shared system database, and the new p11-kit modules
> could have been loaded from /etc/pki/nssdb/pkcs11.txt rather than needing a
> hacked nssckbi.so.
Perhaps. And we can still do that in the future. But realistically we weren't able to pull that off that as part of this first step.
> What *should* NSS-using applications be doing, ideally?
I would indeed like to see NSS use p11-kit to load the configured modules. In addition, you may be aware that libsoftoken usage of /etc/pki/nssdb is pretty broken, due to file locking DOSing from unprivileged users on the sqlite database.
(In reply to comment #11)>
> Are we limiting our focus *only* to certs, for now? It would have been good
> to move all apps to the shared system database,
That's nontrivial, because applications decide which path they use, and we don't have migration code that works in all scenarios (in particular, if different passwords are set on app specific and shared location).
Solving the pkcs#11 config and obsoleting the old /etc/pki/nssdb is a separate task, we cannot do everything at once.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
Kai, I believe this is complete right?
(In reply to comment #16)
> Kai, I believe this is complete right?
Yes, I think so, nss-3.14.3-10