Fix NSS library not finding root CA certificates.#112
Conversation
So to begin with fixing NSS let's get to the latest upstream release and start fixing, so we won't carry around historic crap we then will throw away anyway.
Let's use system SQLite library, which makes sense anyway. More importantly because it conflicts with the sqlite package, as NSS is building this as a shared library aswell.
This is a compatibility module which adds suport for PEM certificates used by OpenSSL and compatible libraries. The module gets built but isn't used at the moment, so we're going to work on integration of it later.
First of all, let's remove that redundant BUILD_OPT variable. This variable already is in makeFlags, so we really don't want it to be lurking around in the attribute set of the derivation, and it annoys me for being there for days. We now state build targets explicitly rather than relying on "nss_build_all". This makes NSPR_CONFIG_STATUS and the touch of build_nspr stamp obsolete, as only nss_build_all includes build_nspr. In addition, we don't need the -lz hack anymore, as this has been fixed in recent NSS versions, so we can completly remove the postBuild hook. And while we're at it, we're removing those outdated build instructions as well, especially because we don't and can't follow official building guidelines anymore, as those are difficult to apply to Nix.
Running NSS in FIPS mode is only possible if the libraries are signed correctly, so we're doing this in the postFixup hook, to insure nothing gets altered after that phase. For more information about FIPS mode, please see: https://developer.mozilla.org/en-US/docs/NSS/FIPS_Mode_-_an_explanation
This adds a patch from Debian, as they're already have security modules from NSS
in it's own library directory rather than /usr/lib{,64}/ and patch in loading of
libsoftokn as well.
The patch and our own fix of the patch (well, they hardcode Debian specific
stuff in there) ensures that SECMOD_AddNewModule() will find the right module
from the derivation's output path, so the built-in CA root certificates are
recognized and verified correctly.
This file is already contained in nss-3.12.5-gentoo-fixups.diff, so we don't need to do all that cruft twice.
Before, the entire directory was deleted and recreated, which fails if we want to sign libraries (shlibsign is obviously deleted in that step as well), so we delete everything but "nss-config" on postFixup.
Hurray! This is the first time chromium is working with NSS _and_ is able to verify certificates using the root certificates built in into NSS. Optimally it would use certs from OPENSSL_X509_CERT_FILE, but at least it's working, so let's add that at some later point.
So, now even Firefox can be built with our shiny new fixed up NSS derivation, and as this is desired (especially if we want to support certificates from the CA bundle), let's make it the default.
|
I've been waiting for some time to get my ssl client certificates working in chromium (and shared with firefox). |
|
@bluescreen303 Ah, you've tested with ff? That was the one worry I had to merging this, great. |
Fix NSS library not finding root CA certificates. This now uses more or less hardcoded CA certificates from Mozilla, which is the case on Debian and Gentoo aswell. And it fixes the root CA loading issue, as i discovered that firefox builds with the bundled version of NSS. With this branch this is no longer the case. My long-term plans are to integrate an automatic chainloader for OPENSSL_X509_CERT_FILE, but I'm not sure if this is really a good idea (hence not included in this branch), as the nss-pem module is still somewhat experimental. Regardless of it's experimental nature i'm still including it in order to make it possible for users to load custom PEM encoded certificates into the NSS database. This fixups also makes it possible to enable FIPS mode, in case someone might be interested in that. And finally, we have a Chromium without quirky bugs from the experimental OpenSSL integration, which was my original motivation to do this. See NixOS#112 for further comments.
|
yes, and I followed https://wiki.mozilla.org/NSS_Shared_DB_Howto to have On Wed, Aug 22, 2012 at 12:22 PM, Shea Levy [email protected]:
|
|
Any chance you can add a pointer to those instructions (with any On 08/22/2012 06:27 AM, Mathijs Kwik wrote:
|
|
I will do that. |
Specify a correct unit description
RFC NixOS#112 raised the question of what the source of truth is about the platforms supported in Nixpkgs. RFC NixOS#46 specified the authoritative source would be the Nixpkgs manual but this hasn't happened yet. When it comes to Nixpkgs the tier list is currently only important to determine what platforms Hydra should evaluate for. This information is currently in `lib/systems/flake-systems.nix`. However, a manual section as described in RFC NixOS#46 would be a second consumer, so a separate file is warranted. We re-introduce `lib/systems/supported.nix` as a suitable authoritative source. A Nixpkgs manual section could be auto-generated based on this file.
whitelist wire-desktop
This now uses more or less hardcoded CA certificates from Mozilla, which is the case on Debian and Gentoo aswell. And it fixes the root CA loading issue, as i discovered that firefox builds with the bundled version of NSS. With this branch this is no longer the case.
My long-term plans are to integrate an automatic chainloader for OPENSSL_X509_CERT_FILE, but I'm not sure if this is really a good idea (hence not included in this branch), as the nss-pem module is still somewhat experimental. Regardless of it's experimental nature i'm still including it in order to make it possible for users to load custom PEM encoded certificates into the NSS database.
This fixups also makes it possible to enable FIPS mode, in case someone might be interested in that.
And finally, we have a Chromium without quirky bugs from the experimental OpenSSL integration, which was my original motivation to do this.