(cherry picked from commit ad1e2500efd0aa49b0dc7427bf69d4879f3b0ff5)
(cherry picked from commit aec730a0af4c977513ce28236cbecaca72af6901)

Upstream changes:

* Fix ordering between systemd socket file descriptor names and rules.
* Fix usage of C library path as discovered by Meson.

Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit 8b7f8e2e6970f21d9f180887b91c979b41450fe8)

doc: rename guide to 'Nixpkgs Manual'

For consistency with 'NixOS Manual' and 'Nix Manual', to better match what it's
often called in practice, and to match its URL and HTML title.

[19.09] libexif: 0.6.21 -> 0.6.22 for security fixes

Also:
- build from git
- enable cross compilation

(cherry picked from commit e761cfe50ac6a9204af703e2bb91e89ba521db02)

Fixes CVE-2020-13777 [1].

Changes: https://lists.gnupg.org/pipermail/gnutls-help/2020-June/004648.html

[1] https://nvd.nist.gov/vuln/detail/CVE-2020-13777

(cherry picked from commit 1dba11754189f8, PR #89884)
19.09 isn't really supported anymore, but this CVE seems very important.

wire-desktop: linux 3.17.2924 -> 3.18.2925, mac 3.17.3666 -> 3.18.3728

(cherry picked from commit 5a8cdcc278ee032b15b9ef415995131d2fae543c)

(cherry picked from commit 9535a4370b08175947ea06871c3f548dbb6aa94b)

(cherry picked from commit 3e2b6b99bff59aac7e2c961802583d350106192e)

Upstream fixes:

- Pass linker version script to the linker instead of the compiler.
- Compile with `-fPIC` again (regression from version 2.1.2).
- Out of bounds array access in `globpath`.
- Handling of `epoll_ctl` calls (they're now replayed after replacing
socket).
- GCC 10 build errors and Clang warnings.

While most of these fixes are more relevant for other distros, the
linker script fix is actually a regression existing since a long time
(version 1.x) and caused libip2unix to expose way too many symbols.

Built and tested on i686-linux and x86_64-linux.

Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit 67325b12c641378d622051b73ada8ae808ba318d)

This fixes the issues with glibc 2.30, which were caused because glibc
no longer allows to dlopen/LD_PRELOAD a PIE executable.

So this release is essentially just a hotfix release which addresses
this issue by splitting the executable and library.

Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @zimbatm
(cherry picked from commit b51d39fbe44fc5c7c6fdb934c6e7de82127adfdf)

(cherry picked from commit cfaa8035d721dc526d4d719a506de15771add05d)

(cherry picked from commit f7c914e96e2f356110c99199e23590b9315cacf3)

(cherry picked from commit 0e384147f97fb4d7058dd9029dcec3dc79e6a0cb)

https://blog.powerdns.com/2020/05/19/powerdns-recursor-4-3-1-4-2-2-and-4-1-16-released/
$ nix build -f nixos/release.nix tests.pdns-recursor.x86_64-linux
NixPkgs master is on 4.3.x already; /cc that PR #88159

(cherry picked from commit 1a029774275d24991d161a68678c758a0d80452e)

https://www.isc.org/blogs/bind9-vulnerabilities-2020-05/
$ nix build -f nixos/release.nix tests.bind.x86_64-linux

(cherry picked from commit 13c485d63da8c7fa6a705dc0f4bbd42313beee6c)
In BIND case these are quite severe DoS risks, so let me backport to 19.09.

Fixes: CVE-2020-10957, CVE-2020-10958, CVE-2020-10967
(cherry picked from commit 6cf48856d23260e34d7c9b278ad6a2ea7ddeb318)

(cherry picked from commit 8d08f4536828387c6a2ba03cb4a0c23637e83774)

[19.09] chromium: Mark as insecure

Since M81 won't receive any updates anymore and there are known
vulnerabilities we should mark it as insecure so that users are aware of
the risks.
Updating Chromium to M83 is unfortunately too challenging for
19.09, but as of today we've already covered the one month period of
security updates for "oldstable" and both 20.03 and nixos-unstable
contain recent versions (i.e. users should either update to the current
stable release or install Chromium from a different channel).

nixos-unstable PR for M83: #88206

[19.09] firefox: Add patch to fix AES GCM IV bit size

(cherry picked from commit b70435e43c540527e7650b652a5ec2690b2fc89b)

Regression introduced by bce5268a216924820a486d09bc3aec7e8d6b8fa7.

The bit size of the initialisation vector for AES GCM has been
introduced in NSS version 3.52 in the CK_GCM_PARMS struct via the
ulIvBits field.

Unfortunately, Firefox 68.8.0 and 76.0 do not set this field and thus it
gets initialised to zero, which in turn causes IV generation to fail.

I found out about this because WebRTC stopped working after updating to
NSS 3.52 and so I started bisecting.

Since there wasn't an obvious error in Firefox hinting towards NSS but
instead just the video stream ended up as a "null" stream, I didn't
suspect the NSS update to be the culprit at first. So I verified a few
times and then also started bisecting the actual commit in NSS that
caused the issue.

This turned out to be the problematic change:

https://phabricator.services.mozilla.com/D63241

> One notable change was caused by an inconsistancy between the spec and
> the released headers in PKCS#11 v2.40. CK_GCM_PARAMS had an extra
> field in the header that was not in the spec. OASIS considers the
> header file to be normative, so PKCS#11 v3.0 resolved the issue in
> favor of the header file definition.

Since the test I've used[1] was a bit flaky, I still didn't believe the
result of the bisect to be accurate, but after running the test several
times leading same results I dug through the above change line by line
to get more clues.

It fortunately didn't take that long to stumble upon the ulIvBits change
(which is actually documented in the NSS 3.52 release notes[4], but I
managed to blatantly ignore it for some reason) and started checking the
Firefox source tree for changes regarding that field.

Initialisation of that new field has been introduced[2] in preparation
for the 76 release, but subsequently got reverted[3] prior to the
release, because Firefox 76 is expected to be shipped with NSS 3.51,
which didn't have the ulIvBits field.

The patch I'm adding here is just a reintroduction of that change,
because we're using NSS 3.52. Not initialising that field will break
WebRTC and WebCrypto, which I think the former seems to gain in
popularity these days ;-)

Tested the change against the mentioned VM test[1] and also by testing
manually using Jitsi Meet and Nextcloud Talk.

[1]: https://github.com/aszlig/avonc/tree/884315838b6f0ebb32b/tests/talk
[2]: https://hg.mozilla.org/mozilla-central/rev/3ed30e6b6de1
[3]: https://hg.mozilla.org/mozilla-central/rev/665137da70ee
[4]: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.52_release_notes

Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit 8fb49973ce4b5d8555d10ade3c27ea35fb5bdb4c & moved to packages.nix)

According to https://monerodocs.org/interacting/monerod-reference/#node-rpc-api
the correct option is restricted-rpc, not restrict-rpc.

(cherry picked from commit e7ab236cab9dd6e74526bee282caa001a3374c37)

https://www.thunderbird.net/en-US/thunderbird/68.8.0/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2020-18/
(cherry picked from commit 10134fc30160b0459e1e5043bed6ca671188fd4a)
Re-tested both briefly on 19.09.

chromium: 81.0.4044.129 -> 81.0.4044.138

https://chromereleases.googleblog.com/2020/05/stable-channel-update-for-desktop.html

This update includes 3 security fixes.

CVEs: CVE-2020-6831 CVE-2020-6464
(cherry picked from commit dec3d5f39f67dbb6254d139521005a0d5d306605)

[19.09] firefox: 75.0 -> 76.0

(cherry picked from commit f3cc8dc6fa253c585c24410ef4bb3f13fe13802c)

(cherry picked from commit 3911336cc64828e1d2638c4e3fa437b888b0d238)

(cherry picked from commit 324e40f0f4a80f63d9c84e117f2dbb3ce2113f26)

[19.09] salt: 2019.2.0 -> 2019.2.4

Fixes CVE-2020-11651 and CVE-2020-11652

[19.09] gitlab: 12.8.9 -> 12.8.10

(cherry picked from commit fdd0d0de1f0cc35937296ccee4bc6c99f63f657b)

(cherry picked from commit 9eb6dc762f67d09e4598ee2e35070821590e68dc)

[19.09] chromium: 81.0.4044.122 -> 81.0.4044.129 (backport)

https://github.com/roundcube/roundcubemail/releases/tag/1.3.11

This contains some important security fixes, hence the package-bump.

monotone: openssl in botan is not needed, so drop to avoid old openssl

(cherry picked from commit 4644776b2e95027eba4a7f3c4e1a9fd08a12e2f6)

[19.09] coturn: apply patch for CVE-2020-6061/6062

Fixes: CVE-2020-6061, CVE-2020-6062

An exploitable heap overflow vulnerability exists in the way CoTURN
4.5.1.1 web server parses POST requests. A specially crafted HTTP
POST request can lead to information leaks and other misbehavior.
An attacker needs to send an HTTPS request to trigger this vulnerability.

An exploitable denial-of-service vulnerability exists in the way
CoTURN 4.5.1.1 web server parses POST requests. A specially crafted
HTTP POST request can lead to server crash and denial of service.
An attacker needs to send an HTTP request to trigger this vulnerability.

(cherry picked from commit 704a018aaea16e044c1adf33accce6be2884911d)

https://chromereleases.googleblog.com/2020/04/stable-channel-update-for-desktop_27.html

This update includes 2 security fixes.

CVEs: CVE-2020-6462 CVE-2020-6461
(cherry picked from commit db4aece8849ddd9ea466a7a91cea3c2f875a15f8)

`bundix -l` doesn't work, as it treats bundler's warning about upgrading
the lockfile version as an error, so invoke `bundle lock` manually.

(cherry picked from commit 4c26ab4198b083f0647f1c0e64f985e211beff8f)

(cherry picked from commit c86c77be0cf45023586e7252bfb05238ae6d38db)

(cherry picked from commit f7ddd30bef15238d6d9a12f48408d38571944d85)

While it's already possible to invoke `update-data` with the `--rev`
argument, one still needs to run all later phases manually.

Fix this, by having `update-all` also accept a `--rev` argument, and
pass it down to `update-data`.

Also, make the help text a bit more usable, by suggesting the usual
versioning scheme used these times.

(cherry picked from commit 191c2c67a409ae8cf3d3bee7811a7b10397efe81)

See
https://about.gitlab.com/releases/2020/04/14/critical-security-release-gitlab-12-dot-9-dot-3-released/
for details.

(cherry picked from commit d1902923fae5e0056ef69de5e6cf52b1573de225)

nixos/gitlab: Fix services.gitlab.enableStartTLSAuto

'toString false' results in an empty string, which, in this context,
is a syntax error. Use boolToString instead.

Fixes #86160

(cherry picked from commit c0a838df38c03cb269061905510c33dd071b517a)

Kyndig on IRC noticed that building `ninja` from source would fail due
to a patch 404'ing (because the repo appears to no longer exist). Fetch
from upstream instead.

(cherry picked from commit 91d4e9aa97ab19a1364159a7617336aeb6a864f8)
cc #85742

[19.09] Use qt5's mkDerivation in packages that otherwise crash

[19.09] hostapd: apply patch for CVE-2019-16275

AP mode PMF disconnection protection bypass

Published: September 11, 2019
Identifiers:
- CVE-2019-16275
Latest version available from: https://w1.fi/security/2019-7/

Vulnerability

hostapd (and wpa_supplicant when controlling AP mode) did not perform
sufficient source address validation for some received Management frames
and this could result in ending up sending a frame that caused
associated stations to incorrectly believe they were disconnected from
the network even if management frame protection (also known as PMF) was
negotiated for the association. This could be considered to be a denial
of service vulnerability since PMF is supposed to protect from this type
of issues. It should be noted that if PMF is not enabled, there would be
no protocol level protection against this type of denial service
attacks.

An attacker in radio range of the access point could inject a specially
constructed unauthenticated IEEE 802.11 frame to the access point to
cause associated stations to be disconnected and require a reconnection
to the network.

Vulnerable versions/configurations

All hostapd and wpa_supplicants versions with PMF support
(CONFIG_IEEE80211W=y) and a runtime configuration enabled AP mode with
PMF being enabled (optional or required). In addition, this would be
applicable only when using user space based MLME/SME in AP mode, i.e.,
when hostapd (or wpa_supplicant when controlling AP mode) would process
authentication and association management frames. This condition would
be applicable mainly with drivers that use mac80211.

Possible mitigation steps

- Merge the following commit to wpa_supplicant/hostapd and rebuild:

AP: Silently ignore management frame from unexpected source address

This patch is available from https://w1.fi/security/2019-7/

- Update to wpa_supplicant/hostapd v2.10 or newer, once available

(cherry picked from commit 3e9f3a3ebd8c2925f28efa91cafa56948ecab021)

(cherry picked from commit d0419f9c25625a6c8a8916351077146c764b0e6c)