Hydra run tests are failing with SIGILL, see [1] , import the upstream
patch to fix the issue. Presumably not all hydra runners have the same
instruction extensions, this should fix the tests on those without AVX2.
[1]: https://hydra.nixos.org/build/117012754
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.
This is less brittle and breaks loud if the code changes.
Also remove the /usr/bin/file patch. It is not really required
for the build to work, the generated warning is harmless.
* Replace LD_LIBRARY_PATH with OS-specific name (e.g. DYLD_LIBRARY_PATH
on macOS).
* Disable Python tests on macOS, because they use gpg, which fails due
to a very long socket path (https://github.com/NixOS/nix/pull/1085).
The former should be fixed upstream. The latter is a Nix-specific issue,
but it can be worked-around upstream by making Python tests respect
--disable-gpg-test.
This is a better name since we have multiple 64-bit things that could
be referred to.
LP64 : integer=32, long=64, pointer=64
ILP64 : integer=64, long=64, pointer=64
Context: discussion in https://github.com/NixOS/nixpkgs/pull/82630
Mesa has been supporting S3TC natively without requiring these libraries
since the S3TC patent expired in December 2017.
This partially reverts commit cc03fb4210.
The libtorrentRasterbar update broke deluge 1.x, the hash was not
updated and obsolete dependencies and flags were not removed.
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
This is based on previous work for switching between BLAS and LAPACK
implementation in Debian[1] and Gentoo[2]. The goal is to have one way
to depend on the BLAS/LAPACK libraries that all packages must use. The
attrs “blas” and “lapack” are used to represent a wrapped BLAS/LAPACK
provider. Derivations that don’t care how BLAS and LAPACK are
implemented can just use blas and lapack directly. If you do care what
you get (perhaps for some CPP), you should verify that blas and lapack
match what you expect with an assertion.
The “blas” package collides with the old “blas” reference
implementation. This has been renamed to “blas-reference”. In
addition, “lapack-reference” is also included, corresponding to
“liblapack” from Netlib.org.
Currently, there are 3 providers of the BLAS and LAPACK interfaces:
- lapack-reference: the BLAS/LAPACK implementation maintained by netlib.org
- OpenBLAS: an optimized version of BLAS and LAPACK
- MKL: Intel’s unfree but highly optimized BLAS/LAPACK implementation
By default, the above implementations all use the “LP64” BLAS and
LAPACK ABI. This corresponds to “openblasCompat” and is the safest way
to use BLAS/LAPACK. You may received some benefits from “ILP64” or
8-byte integer BLAS at the expense of breaking compatibility with some
packages.
This can be switched at build time with an override like:
import <nixpkgs> {
config.allowUnfree = true;
overlays = [(self: super: {
lapack = super.lapack.override {
lapackProvider = super.lapack-reference;
};
blas = super.blas.override {
blasProvider = super.lapack-reference;
};
})];
}
or, switched at runtime via LD_LIBRARY_PATH like:
$ LD_LIBRARY_PATH=$(nix-build -E '(with import <nixpkgs> {}).lapack.override { lapackProvider = pkgs.mkl; is64bit = true; })')/lib:$(nix-build -E '(with import <nixpkgs> {}).blas.override { blasProvider = pkgs.mkl; is64bit = true; })')/lib ./your-blas-linked-binary
By default, we use OpenBLAS LP64 also known in Nixpkgs as
openblasCompat.
[1]: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
[2]: https://wiki.gentoo.org/wiki/Blas-lapack-switch
Boost generates its installed cmake configuration using custom logic
in its own build system; while this logic *knows* where it should be
installed, the generated config overrides the correct information with
new paths based on the location of the cmake configuration file in an
attempt to let the package be relocated after installation.
This patch simply undoes that.
AWS's SDK by default tries to prepend its install root to each of the
library paths; this obviously fails with the absolute paths that Nix
gives it. Worse, it computes the installation root by walking up the
filesystem from its cmake file, so even if the AWSSDK_ROOT_DIR is
explicitly set to the root directory, it gets replaced with the path
to the derivation's dev output.
This is all fixed with a patch to the cmake files that generate the
installed configuration.
Once this is fixed, it *still* doesn't work because the export
generator built into cmake insists on adding `$out/include` to the
header search path; when importing this configuration in another
package, cmake will fail because `$out/include` doesn't exist (After
all, it was relocated by a fixup hook). A small postFixupHook will
recreate the directory and make cmake happy.
libgit2 has bundled pcre (not pcre2) in
https://github.com/libgit2/libgit2/pull/4935
Before this change configure printed "regex, using bundled PCRE",
after this change it prints "regex, using system PCRE".
gst-plugins-bad by default used to pull in gtk3 and qtbase and qtx11extras because of the default dependency on zbar.
As zbar is a rarely needed gstreamer plugin, this unnecessarily
increased the closure size.
I am only aware of gnome-keysign actually using the zbar plugin, so that
uses a zbar-enabled gst-plugins-bad.
closes#84845
On Linux this adds two dependencies to the closure, libjack2 and celt, which
increases its size from 163.5 MB to 164.4 MB.
This should not cause any issues on macOS since jack supports it.
