Certain software stacks have no support for OpenSSL non-standard PEM format and will fail to use
our NixOS CA bundle.
For this, it is necessary to fallback on a 'compatibility' bundle which will contain no additional
trust rules.
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Mozilla set "Distrust After" for the three TrustCor Root CAs¹, so new
certificates issued would not be trusted after 2022/11/30, while older
enduser certificates would continue working until they expire. This is a
fine-grained policy option available to consumers of the NSS library,
such as Firefox or Thunderbird.
For Linux systems we generally export the Mozilla trust store into our
own CA bundle that ultimately lacks that metadata, because there is no
standardized way to parse it in the first place.
That means that as long as Mozilla keeps the certificate in their CA
program, even with time-based "Distrust" configured, we would keep
trusting it fully². That is completely unreasonable and that is why we
reject these CAs here for all users of nixpkgs.
The TrustCor CAs were primarily used to sign certificates for dynamic
hosts for domains provided through no-ip.com, so we expect the fallout
from this to be minimal.
[1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ
[2] https://utcc.utoronto.ca/~cks/space/blog/linux/CARootStoreTrustProblem
This allows users to specify custom CAs without needing to download the
entirety of the NSS source code - just certdata.txt, which should end up
in cache.nixos.org.
This introduces the ability to have additional certificates in the trust
store using an override, similar to how the blacklist is done. If the
certificates are provided in OpenSSL TRUSTED CERTIFICATE form, then
those trust bits will be respected.
It also adds a p11-kit compatible trust store output.
Usually, on the stable channel, we have a nss_latest attribute that is
more up to date than the nss attribute (which is usually frozen during
branch-off and only receives security updates). Cacerts are a sensitive
matter and should be updated more frequently than the stable NSS package,
if required. By making the update script aware of the nss_latest
attribute we can prefer that when it exists.
By having this change in the unstable branch of Nixpgks we can carry it
from release to release without requiring more churn from those doing
the stable release maintenance.
This doesn't do anything. Building with includeEmail = true produces
the same set as includeEmail = false, and the substitute rule removes
a random dictionary index operation.
In [#100765] @vcunat pointed out that we could decouple cacert from the
NSS package to make it more rebuild friendly. Just rebuilding packages
that depend on NSS seems to be about ~100. Rebuilding all the packages
that depend on cacert is >9k as of this writing. This makes it much more
feasible to upgrade high-profile packages that are (rightfully) pedantic
on their NSS version like firefox and thunderbird.
[#100765]: https://github.com/NixOS/nixpkgs/pull/100765
Triggering this setupHook for dependencies at targetOffset does not work
in cross-compilation cases where such a dependency is lacking. This
simplified setupHook is more robust.
Some SSL libs don't react to $SSL_CERT_FILE.
That actually makes sense to me, as we add this behavior
as nixpkgs-specific, so it seems "safer" to use $NIX_*.
He prefers to contribute to his own nixpkgs fork triton.
Since he is still marked as maintainer in many packages
this leaves the wrong impression he still maintains those.
