With their new versioning scheme, OpenSSL have committed[1] to API and
ABI compatibility for the whole 3.x.x release series, so we shouldn't
be overly specific in our attribute name.
[1]: https://www.openssl.org/blog/blog/2018/11/28/version/
- The c_rehash script allows command injection (CVE-2022-1292)
- OCSP_basic_verify may incorrectly verify the response signing
certificate (CVE-2022-1343)
- Incorrect MAC key used in the RC4-MD5 ciphersuite (CVE-2022-1434)
- Resource leakage when decoding certificates and keys (CVE-2022-1473)
https://mta.openssl.org/pipermail/openssl-announce/2022-May/000224.html
Fixes: CVE-2022-1292, CVE-2022-1343, CVE-2022-1434, CVE-2022-1473
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
