- 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
Previously, the "out" output of openssl would contain would contain a
couple of tiny libraries in etc/, and the big OpenSSL libraries in
lib/. This bloated closures when building things against OpenSSL with
pkgsStatic. To fix this, introduce a lib output, so only the config
files are left in out.
Additionally, we have to disable support for dynamic engines in static
builds to avoid a reference to the engines directory in $lib. I don't
think it's likely that this would ever have worked anyway.
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
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
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)
Jörg Thalheim