as of 0.17.4, it looks like i can replace
/usr/lib/$ARCH_TRIPLE/nss/libnssckbi.so with
/usr/lib/$ARCH_TRIPLE/pkcs11/p11-kit-trust.so and systems that use
libnssckbi.so (e.g. iceweasel and icedove) will now treat the system
trusted root store as the canonical list of trusted authorities,
rather than using their own built-in.
I did this with something like:
dpkg-divert --divert /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so.orig /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so
mv /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so.orig
ln -s ../pkcs11/p11-kit-trust.so /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so
It would be great to have this available to a system administrator
without having to do this work manually.
Two ways to go about it:
a) the p11-kit binary package could have a postinst script, and based on a
debconf prompt, could decide to make this diversion.
b) we could introduce a new binary package that Depends: on p11-kit
and unconditionally does this diversion in its postinst script.
I prefer (b), because i think it's simpler to say "if you want this
behavior, install p11-kit-nssckbi" than to ask admins to
dpkg-reconfigure or preseed their debconf selections.
If this seems reasonable, i could write a patch to implement it.
please let me know (and let me know if you have preferences for
strategy a or b also).
thanks for keeping p11-kit up-to-date in debian -- this is a big step
forward toward using a well-administered trust store!
Regards,
(setting followup-to: #704180 for this sub-thread) my understanding of ca-certificates is that /etc/ssl/certs is itself a (coarse-grained) trust setting. That is, we have a bunch of certs shipped in /usr/share/ca-certificates, and during the ca-certificates.postinst maintainer script, those certificates selected as "trusted" by the system administrator are symlinked from /etc/ssl/certs. By default, if the admin has low debconf priority: all of them are considered trusted. This isn't the finer-grained trust available in the traditional nssckbi, which lets you break out three different broad areas of reliance: * certify web servers * certify e-mail users * certify code signatures so ca-certificates and /etc/ssl/certs is slightly more clunky. But frankly, even nss-ckbi is clunky by comparison with what anyone who cares about this would sensibly want. For example, i might only want to rely on the CA from example.com's administrators to be able to certify e-mail users *within example.com*. p11-kit has proposed mechanisms (i haven't tested them, but as i understand it, the idea is to associate extra X.509v3 extensions with the certificates in question) to implement this sort of finer-grained permission, even if it is not represented by ca-certificates. So it seems sensible to me to start with the coarse-grained nssckbi override using ca-certificates' coarse "all-or-nothing" approach to demonstrate basic functionality, and then figure out how to adjust the finer-grained nuance within p11-kit itself.
At the risk of being a "me-too", I think there is a real concrete use case for better integrating the p11-kit/nssckbi diversion. Currently, NSS ( http://packages.debian.org/wheezy/libnss3 ) carries a patch to add certificates for SPI and CACert ( http://patch-tracker.debian.org/package/nss/2:3.14.5-1 ). These add two certificate authorities that are not audited nor do they participate in any root store program. While I can understand and respect the ideological reasons for their inclusions, administrators of Debian and Debian-derived systems may have a desire to remove or restrict such certificates, as they open up all NSS-using applications to the risk of MITM or compromise that would not (generally) be detected by root store operators. Using the p11-kit-trust module as a diversion for nssckbi would allow the patches to nssckbi.so removed, and moved into p11-kit. p11-kit-trust would then allow administrators to disable or remove such trust, without having to recompile or repackage either NSS or p11-kit - simply by modifying the trust entries on disk. Fedora and Red Hat have already integrated NSS and p11-kit in this way - see http://pkgs.fedoraproject.org/cgit/p11-kit.git/tree/p11-kit.spec , which on post-inst sets p11-kit to be a diversion for the nssckbi trust module via update-alternatives. On a concrete level, what are the steps we can take to move forward to such a system? Is this something the maintainers could add, is this something patches would be welcome for, or are there fundamental oppositions to allowing administrators full control over their root stores, without requiring a repackaging of NSS to mask out the patches?
On Thu, 28 Mar 2013 20:57:01 -0400 Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > as of 0.17.4, it looks like i can replace > /usr/lib/$ARCH_TRIPLE/nss/libnssckbi.so with > /usr/lib/$ARCH_TRIPLE/pkcs11/p11-kit-trust.so and systems that use > libnssckbi.so (e.g. iceweasel and icedove) will now treat the system > trusted root store as the canonical list of trusted authorities, > rather than using their own built-in. > > I did this with something like: > > dpkg-divert --divert /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so.orig /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so > mv /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so.orig > ln -s ../pkcs11/p11-kit-trust.so /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)/nss/libnssckbi.so > > It would be great to have this available to a system administrator > without having to do this work manually. > > Two ways to go about it: > > a) the p11-kit binary package could have a postinst script, and based on a > debconf prompt, could decide to make this diversion. > > b) we could introduce a new binary package that Depends: on p11-kit > and unconditionally does this diversion in its postinst script. > > I prefer (b), because i think it's simpler to say "if you want this > behavior, install p11-kit-nssckbi" than to ask admins to > dpkg-reconfigure or preseed their debconf selections. > > If this seems reasonable, i could write a patch to implement it. > please let me know (and let me know if you have preferences for > strategy a or b also). > > thanks for keeping p11-kit up-to-date in debian -- this is a big step > forward toward using a well-administered trust store! > > Regards, > > --dkg Note that there is also #741005 opened against NSS package
Hello, So what is the status of this? In RHEL 7 they made the switch to p11-kit and libnssckbi.so is an alternative between the file shipped by nss and p11-kit-trust.so shipped by p11-kit (with p11-kit version being the default). Should we switch debian by default to p11-kit as well?
seems like the maintainers of p11-kit could unilaterally decide to implement the diversion approach mentioned in https://bugs.debian.org/704180 with a new binary package, if the nss folks are reluctant to do it. I'm cc'ing Andreas here to try to get some feedback -- is this something that there's interest in for the p11-kit maintainers?
Le 10/01/19 à 19:03, David Woodhouse a écrit : If I'm searching for a file called libnssckbi.so in the archive, the only other occurrence is in package libapache2-mod-nss. Shouldn't it be better to use an alternative so a local admin can switch back to the libnss3 version? When I discussed with Mike about bug #820437 he didn't looked opposed to use p11-kit, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820437#19
That would seem like an excellent way to do it. However, am I right in thinking that we have multiple packages all shipping their *own* special version of the NSS libraries, instead of using the system one? Each instance of libnssckbi.so (in firefox, thunderbird, etc.) would need to be replaced, wouldn't it?
afaict, that's just a symlink: etc/apache2/nssdb/libnssckbi.so -> /usr/lib/$ARCH_TRIPLET/nss/libnssckbi.so so i don't think that matters for this discussion. We can use /etc/alternatives if folks want to, but i think a simple "if this package is installed, that means the admin wants to use it" rule is easier for people to understand, less fiddly, and clearer when collecting things like bug report information. what's the advantage of using alternatives instead of a package-specific displacement?
None really, as long as you put it in a separate p11-kit-trust package as Fedora/RHEL do. You don't want installation of the p11-kit package itself to trigger the replacement, necessarily. Lots of other things use p11-kit.
Looking back, I see this bug was opened with the comment "With the
recent switch of wheezy-security's iceweasel to using the
embedded copy of nss..."
That was 2014 though. Is it no longer the case?
FWIW my Ubuntu 18.04 box does have separate instances of libnssckbi.so
in /usr/lib/{thunderbird,firefox}/ (along with all the other NSS
libraries, I believe).
Perhaps the answer is that any separate instances of NSS should *not*
ship their own libnssckbi.so and should use the system one. The
interface there is entirely stable as it's PKCS#11, so there won't be
compatibility problems (else p11-kit-trust couldn't work either).
i can confirm that it is no longer the case. I've got firefox and thunderbird on a debian buster/side system and they do not ship libnssckbi.so -- they appear to rely on the one in the libnss3 package. that's interesting; i've got firefox (64.0-1) and firefox-esr (60.4.0esr-1) and thunderbird (1:60.3.1-1) installed and this is dpkg's full scan of the system for libnssckbi.so: 0 dkg@alice:~$ dpkg -S libnssckbi.so libnss3:amd64: /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so 0 dkg@alice:~$ sounds like a bug report to ubuntu is in order.
yes, agreed, it would be a separate and distinct binary package, not p11-kit on its own.
Le 11/01/19 à 17:17, Daniel Kahn Gillmor a écrit : The problem is what/who will decide if this package is installed? If that package is being pulled by on other package for some reason, that means that the local administrator will not be able to revert the decision of the package maintainer who has added this dependency
agreed, a runtime dependency on that for anything but a "preferred system configuration"-style metapackage would be a bad thing. but it'd also be a very visible thing. Hopefully if that happend, the affected user could report a bug on that dependency, and in the meantime work around it with something like equivs.
The coding would be straightforward afaict. https://salsa.debian.org/gnutls-team/p11-kit/commits/tmp-704180-divertnss I have not done any firefox testing apart from "it does not crash", though. ;-) cu Andreas
Le 11/01/19 à 18:28, Daniel Kahn Gillmor a écrit : The problem is that if nothing is pulling the new package in the default installation, nobody will ever use it. And we will create a new difference between debian and the other distributions.
hm, this is true, but it's also likely to be true for a non-default debconf choice as well, right? most people keep their debconf priority at low, and i can't imagine that we'll add this as a high-priority debconf question. David Woodhouse suggests that Fedora ships this configuration choice as a distinct package called p11-kit-trust -- so as long as we name the package the same way, we're actually closing a gap between debian and the other distros.
I like the looks of this, though perhaps we want to name the new package p11-kit-trust to be more in line with the name given by other distros. I will try to build and test it soon -- it'd be good to write an automated test suite too, though i'm not sure how to do that with firefox.
In Fedora it's called p11-kit-trust and it's pulled in by default as a dependency of various other packages including NSS and GnuTLS. In fact I think GnuTLS is built to use it as its default trust store, so not installing it isn't really a possibility. It also provides the standard update-ca-certificates mechanism which manages the CAs used by OpenSSL. They use alternatives so that if the user really wants to disable it for NSS and use the standard libnssckbi.so for NSS, they can.
Hi, Bullseye will be frozen soon. Let's manage to get this sorted out b4 😀️. What is the status here. How can I help to get this feature implemented. BTW: I think #926388 is a duplicate BR DI(FH) Holger Fischer, MSc
Hi, as suggested on #debian-next IRC channel, I prepared an updated version of fix mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704180#80 . The package is renamed now to p11-kit-trust as suggested to be on par with other Linux distributions. The new version can be found here: https://gitlab.com/hoocloud/deb/p11-kit (branch feature-p11-kit-trust) The sources are attached. @Andreas Metzler: Please let me know if this change will make it into Bullseye or if there is something else, which I can do to help. p11-kit-trust should make it into the next release: - it is optional (if you do not install p11-kit-trust, the default behaviour of Debian is ensured) - once it is installed, it is very straightforward to integrate your local certificate authorities (like your local CA and the CA of Proxmox VE f.e.) into your system. Directly after doing update-ca-certificate and installing p11-kit-trust Firefox f.e. trusts all your local authorities without restart (just reload the browser tab, et voila). BR DI(FH) Holger Fischer, MSc
Góðan daginn Okkur var sagt frá frábæru fyrirtæki þínu á skólafundinum okkar: Við, Háskóli Íslands vill bjóða þér að taka þátt í útboðsbeiðni okkar vegna skólaáætlunar fyrir ardiðyl (2021 ariðyl) Gefðu okkur besta verðið þitt. Vinsamlegast sendu besta tilboðið þitt eins fljótt og auðið er fyrir lokadagsetningu tilboðsins 22. February 2021. Sjá meðfylgjandi, láttu okkur vita strax ef þú þarft frekari upplýsingar. hlýjar kveðjur Jón Atli Benediktsson Rektor Háskóli Íslands tölvupóstur: jon.benediktsson@hi.is HÁSKÓLI ÍSLANDS Heimilisfang: Reykjavík, Ísland Sími: (+354) 525 7615 Vefsíða: https://www.hi.is [1] Gættu að jörðinni! Vinsamlegast ekki prenta þennan tölvupóst nema bráðnauðsynlegt I know! Þessi skilaboð (þ.mt öll viðhengi) innihalda trúnaðarupplýsingar sem ætlaðar eru einstaklingi og ákveðnum tilgangi og eru verndaðar með lögum. Ef þú ert ekki ætlaður viðtakandi verður þú að eyða þessum skilaboðum og lata þig vita að öll birting, afritun eða dreifing skilaboðanna eða aðgerðir í þessu sambandi erun stranglega bön stranglega. Links: ------ [1] https://www.hi.is/
Notice of safety certificate Dear user: [RECEIVER ADDRESS] To further enhance the security of the email system Recently, our department has updated the security certificates of each email system. Please move the new certificate in time, All the e-mail accounts that hadn't updated the security certificate in time would be suspended from receiving and sending messages. If they needed to recover, they had to apply for it through OA. [Click to log in]
FYI, the file paths in the original bug report are no longer accurate
for Debian 12 ("bookworm").
Old path: /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
New path: /usr/lib/x86_64-linux-gnu/libnssckbi.so
Commands to divert the original file and replace it with a symlink:
# dpkg-divert --add --rename /usr/lib/x86_64-linux-gnu/libnssckbi.so
# ln -sr /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so /usr/lib/x86_64-linux-gnu/libnssckbi.so
Commands to clean up the old diversion:
# dpkg-divert --rename --remove /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
# dpkg -S /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
... output should show that this is no longer owned by any package
# rm /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
A convenient way to test that the above works (instead of having to
restart your browser) is to use the following tool from the
libnss3-toosl package:
$ vfyserv server.example.com
Connecting to host server.example.com (addr 198.51.100.99) on port 443
Handshake Complete: SERVER CONFIGURED CORRECTLY
bulk cipher AES-256-GCM, 256 secret key bits, 256 key bits, status: 1
subject DN:
CN=server.example.com,O=Example private certificate authority
issuer DN:
CN=Certificate Authority,O=Example private certificate authority
0 cache hits; 0 cache misses, 0 cache not reusable
***** Connection 1 read 488 bytes total.
Unfortunately this no longer works reliably. Since libnssckbi.so is now found in /usr/lib/x86_64-linux-gnu, as soon any library package is installer or upgraded, ldconfig will be run, which will replace the symlink. (This is noted in the dpkg-divert man page).
/usr/lib/x86_64-linux-gnu, like so:
# dpkg-divert --local --rename --divert /usr/lib.x86_64-linux-gnu.libnssckbi.so.diverted --add /usr/lib/x86_64-linux-gnu/libnssckbi.so
Adding 'local diversion of /usr/lib/x86_64-linux-gnu/libnssckbi.so to /usr/lib.x86_64-linux-gnu.libnssckbi.so.diverted'
Ugly, but now ldconfig will not find the original file and create a
symlink to it based on its SONAME.
Gefeliciteerd!!! Er is $3.000.000,00 USD aan u gedoneerd. Mijn naam is Charles Koch, ik ben een filantroop en u behoort tot de weinige gelukkigen wiens e-mailadressen mogelijk uit de database zijn geselecteerd. kom terug voor meer informatie.. contacteer via: charleskochfoundation00@gmail.com
I have a lucratuve proposal for you, reply for more info.
For your attention I hope this message finds you well. I am writing to remind you that we currently have an outstanding invoice that still needs to be settled for our client. Its currently overdue for more 120 days. We kindly request your cooperation to ensure this matter is resolved promptly. If there are any issues or further information needed to expedite the process, please do not hesitate to reach out. Thank you for your attention to this matter. Best regards, Carol Klass Heads of Accounts Arnold & Portter Email: accounts@anorldpotter.com
Good morning, Approved and ready for remittance to you. Kindly acknowledge this email and have your compensation released to you Warm regards, *Gerhard Mirco*
-----Original Message----- From: Robert <rturcinov@dhz.hr> Date: Monday, 30 June 2025 10:34 AM CST Subject: GOOD NEWS Grant of 2M for you, contact ( donation.project00112@hotmail.com ) for quick claims.
Donation to you. Reply ASAP