Co-authored-by: Robin Gloster <mail@glob.in>
stdenv: print message if structuredAttrs is enabled
stdenv: add _append
reduces the chance of a user doing it wrong
fix nix develop issue
output hooks don't work yet in nix develop though
making $outputs be the same on non-structuredAttrs and structuredAttrs
is too much trouble.
lets instead make a function that gets the output names
reading environment file '/nix/store/2x7m69a2sm2kh0r6v0q5s9z1dh41m4xf-xz-5.2.5-env-bin'
nix: src/nix/develop.cc:299: std::string Common::makeRcScript(nix::ref<nix::Store>, const BuildEnvironment&, const Path&): Assertion `outputs != buildEnvironment.vars.end()' failed.
use a function to get all output names instead of using $outputs
copy env functionality from https://github.com/NixOS/nixpkgs/pull/76732/commits
carlito used to call `fetchzip` directly, and the fact that it was a
fixed-output derivation meant nobody noticed that:
1. the derivation no longer built from source (due to changes in
`fetchzip`), and
2. the updated fontconfig xml never got used.
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
