When *not* cross-compiling, OpenSSL will not attempt to detect the
host ABI. For mips64, the OpenSSL authors have chosen to assume that
the n32 ABI is used.
Since nixpkgs knows the correct ABI based on stdenv.hostPlatform,
let's pass this information to OpenSSL explicitly.
At the moment (bootstrappable) nixpkgs on mips64 can only be used with
the n64 ABI due to the fact that boost-context (required by nix) does
not support the n32 ABI. Without this commit the openssl expression
can be cross-compiled to a mips64 host, but a mips64 host cannot
self-compile the expression due to OpenSSL's incorrect assumption.
https://github.com/NixOS/nixpkgs/pull/165746#pullrequestreview-924423243
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.
