With removeUnknownConfigureFlags, it's impossible to express a package
that needs --enable-static, but will not accept --disable-shared,
without overriding the result of removeUnknownConfigureFlags _again_
in pkgs/top-level/static.nix.
It would be much better (and more in line with the rest of Nixpkgs) if
we encoded changes needed for static builds in package definitions
themselves, rather than in an ever-expanding list in static.nix. This
is especially true when doing it in static.nix is going to require
multiple overrides to express what could be expressed with stdenv
options.
So as a step in that direction, and to fix the problem described
above, here I replace removeUnknownConfigureFlags with a new stdenv
option, dontAddStaticConfigureFlags. With this mechanism, a package
that needs one but not both of the flags just needs to set
dontAddStaticConfigureFlags and then set up configureFlags manually
based on stdenv.hostPlatform.isStatic.
We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
Fixes: CVE-2020-1967
Segmentation fault in SSL_check_chain (CVE-2020-1967)
=====================================================
Severity: High
Server or client applications that call the SSL_check_chain() function during or
after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a
result of incorrect handling of the "signature_algorithms_cert" TLS extension.
The crash occurs if an invalid or unrecognised signature algorithm is received
from the peer. This could be exploited by a malicious peer in a Denial of
Service attack.
OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This
issue did not affect OpenSSL versions prior to 1.1.1d.
Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g
This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April
2020. It was found using the new static analysis pass being implemented in GCC,
- -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin
Kaduk.
fetchpatch can't be used here and fetchurl from GitHub
like in PR #82928 has the risk of breaking the hash later;
fortunately the patches aren't too large.
(cherry picked from commit 2071e3be28ee0d6ec46056352c88b88f5c0d7f60)
No vulnerabilities are know so far (to me), but still I'd go this way.
Especially for 20.03 it seems better to deprecate it before official
release happens.
Current casualties:
$ ./maintainers/scripts/rebuild-amount.sh --print HEAD HEAD^
Estimating rebuild amount by counting changed Hydra jobs.
87 x86_64-darwin
161 x86_64-linux
It's certainly better to have those two caveats than not evaluate.
Both seem rather niche. Unfortunately I failed to find a better way.
I started testing builds of several cross variants; all seem OK.
