commits
[Backport release-20.09] firefox-esr: 78.10.1esr -> 78.11.0esr
https://www.mozilla.org/en-US/firefox/78.11.0/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2021-24/
(cherry picked from commit f42ea75dec8fff9becbdf2094044485ec103dcd1)
[20.09] python3Packages.websockets: add patch for CVE-2018-1000518-redux
this is a reintroduction of CVE-2018-1000518 which doesn't appear to
have its own CVE assigned (yet?)
[Backport release-20.09] ungoogled-chromium: 90.0.4430.212 -> 91.0.4472.77
(cherry picked from commit 6c638ee6b10e7b9f567601068a195f45740805fc)
no upstream release yet
(cherry picked from commit edcde75b989c69d566b8da67db2fa7351ca3c191)
[Backport release-20.09] keycloak: 13.0.0 -> 13.0.1
(cherry picked from commit 153eed52048365b0c91be1346dd566a41710eb69)
[20.09] yara: 4.0.1 -> 4.0.5
[Backport release-20.09] nixos/wordpress: regenerate secret keys if misspelled key name is found
A secret key generated by the nixos module was misspelled, which could
possibly impact the security of session cookies.
To recover from this situation we will wipe all security keys that were
previously generated by the NixOS module, when the misspelled one is
found. This will result in all session cookies being invalidated. This
is confirmed by the wordpress documentation:
> You can change these at any point in time to invalidate all existing
> cookies. This does mean that all users will have to login again.
https://wordpress.org/support/article/editing-wp-config-php/#security-keys
Meanwhile this issue shouldn't be too grave, since the salting function
of wordpress will rely on the concatenation of both the user-provided
and automatically generated values, that are stored in the database.
> Secret keys are located in two places: in the database and in the
> wp-config.php file. The secret key in the database is randomly
> generated and will be appended to the secret keys in wp-config.php.
https://developer.wordpress.org/reference/functions/wp_salt/
Fixes: 2adb03fdaea6186299c6ff578bb6814d8f3bb30b ("nixos/wordpress:
generate secrets locally")
Reported-by: Moritz Hedtke <Moritz.Hedtke@t-online.de>
(cherry picked from commit 724ed08df02546fea2ab38613d615dd47461528c)
(cherry picked from commit e7b4f9b91e6c93b67f681471f5fa68ab672d9dad)
[20.09] Backport Fetch pffft from upstream project website instead of bitbucket
Starting from this commit
https://github.com/VCVRack/Rack/commit/2db08f15a00f6792bb3a45db31dd13f94966beed
the upstream project does not expect to use bitbucket anymore. The title
mentions that “BitBucket deleted all Mercurial repos”. Instead, an archive of
the pffft source is hosted on vcvrack.com directly. The unziped sha256 is the
same as before this change.
(cherry picked from commit 7964c9827f7ade5bc0a76e60fb364dfb72b5468e)
https://github.com/electron/electron/releases/tag/v10.4.6
https://github.com/electron/electron/releases/tag/v10.4.7
(cherry picked from commit f8fbfa538bcb8a8c187f4d60946cf8f0dc9dc6a7)
https://github.com/electron/electron/releases/tag/v11.4.7
(cherry picked from commit 505298f812a263244c2189549933c02d810965a7)
https://github.com/electron/electron/releases/tag/v12.0.8
https://github.com/electron/electron/releases/tag/v12.0.9
(cherry picked from commit a0426609c8cbf16e8ef1bbae34faa060fec6fe05)
[20.09] wordpress: 5.6.2 -> 5.6.4
[20.09] slurm: 20.02.6.1 -> 20.02.7.1
Fixes CVE-2020-15078.
https://community.openvpn.net/openvpn/wiki/CVE-2020-15078
fixes https://www.samba.org/samba/security/CVE-2021-20254.html
mutt: patch for CVE-2021-32055
[20.09] sssd: 1.16.4 -> 1.16.5
Fixes #120373 - [CVE-2020-36314](https://nvd.nist.gov/vuln/detail/CVE-2020-36314)
[20.09] chromium: 90.0.4430.212 -> 91.0.4472.77
Fixes CVE-2018-16838.
https://sssd.io/release-notes/sssd-1.16.5.html
(cherry picked from commit affda4029fdc80149c0f30c8cc6021cf4efda0e7)
[20.09] nginx: Fix off-by-one in DNS resolver heap write
Quoting from oss-security:
An off-by-one error in ngx_resolver_copy() while processing DNS
responses allows a network attacker to write a dot character ('.', 0x2E)
out of bounds in a heap allocated buffer. The vulnerability can be
triggered by a DNS response in reply to a DNS request from nginx when
the resolver primitive is configured. A specially crafted packet allows
overwriting the least significant byte of next heap chunk metadata with
0x2E. A network attacker capable of providing DNS responses to a nginx
server can achieve Denial-of-Service and likely remote code execution.
Due to the lack of DNS spoofing mitigations in nginx and the fact that
the vulnerable function is called before checking the DNS Transaction
ID, remote attackers might be able to exploit this vulnerability by
flooding the victim server with poisoned DNS responses in a feasible
amount of time.
https://www.openwall.com/lists/oss-security/2021/05/25/5
https://mailman.nginx.org/pipermail/nginx-announce/2021/000300.html
Fixes: CVE-2021-23017
[20.09] vault: 1.6.4 -> 1.6.5
https://chromereleases.googleblog.com/2021/05/stable-channel-update-for-desktop_25.html
This update includes 32 security fixes.
CVEs:
CVE-2021-30521 CVE-2021-30522 CVE-2021-30523 CVE-2021-30524
CVE-2021-30525 CVE-2021-30526 CVE-2021-30527 CVE-2021-30528
CVE-2021-30529 CVE-2021-30530 CVE-2021-30531 CVE-2021-30532
CVE-2021-30533 CVE-2021-30534 CVE-2021-30535 CVE-2021-21212
CVE-2021-30536 CVE-2021-30537 CVE-2021-30538 CVE-2021-30539
CVE-2021-30540
(cherry picked from commit e522464f9afb7b1fda4c02117e6fa27ef1ade396)
element: 1.7.28 -> 1.7.29 (backport to 20.09)
Discord prevents you from using the application if a new version is out.
(cherry picked from commit 501e54080dfc82c41011d371677a7390eab61586)
Fixes CVE-2021-29477 and CVE-2021-29478.
https://github.com/redis/redis/blob/6.0.13/00-RELEASENOTES
[20.09] chromiumBeta: Backport patches to fix the build
The sixth patch release for containerd 1.4 is a security release to
update runc for CVE-2021-30465
Signed-off-by: Christian Simon <simon@swine.de>
[20.09] php74.extensions.iconv: fix error signalling
(cherry picked from commit c2521a6b3604dfab0acc19cf630050079a0e9abd)
The configure script checks whether iconv supports errno. Unfortunately, on PHP < 8, the test program includes $PHP_ICONV_H_PATH, which defaults to FHS path so it fails to build:
conftest.c:13:10: fatal error: /usr/include/iconv.h: No such file or directory
13 | #include </usr/include/iconv.h>
| ^~~~~~~~~~~~~~~~~~~~~~
That causes the feature check to report a false negative, leading PHP to use a degraded code that returns PHP_ICONV_ERR_UNKNOWN when error occurs, breaking granular error handling in applications.
To prevent this, let’s just include <iconv.h>.
PHP 8 just uses include path so the detection works there: https://github.com/php/php-src/commit/7bd1d703411e1e4b1f663f0cb06af619eea04b42
(cherry picked from commit 024243bac4612c62ef5be676818ed2465edae27f)
(cherry picked from commit 6581cd7f5c20c681c5c0f71ce73dbc204f597f86)
(cherry picked from commit 57983646b1761edb014fa96349c0e7137ee3bb07)
(cherry picked from commit 63ff7e430b0de7b5649de49f47a8d7fdc4584477)
python.withPackages avoids the problem with mixed Python 2 and Python 3
dependencies.
(cherry picked from commit e2adee682725044ddc24ad731a54d6f84e314066)
(cherry picked from commit ee727dfdb73bc1cf56eb2c15bb8333ccd163a740)
This fixes the following build error:
[14969/46739] CXX obj/third_party/crashpad/crashpad/util/util/http_transport_libcurl.o[KK[K.o[KKy_reader.or.od.ooor_linux.mojom-shared.o
FAILED: obj/third_party/crashpad/crashpad/util/util/http_transport_libcurl.o
clang++ [...]
../../third_party/crashpad/crashpad/util/net/http_transport_libcurl.cc:17:10: fatal error: 'curl/curl.h' file not found
#include <curl/curl.h>
^~~~~~~~~~~~~
1 error generated.
(cherry picked from commit c0ead3d0c4ae8762be2fdbb0e191c285876dd904)
(cherry picked from commit 6f6ec9e6f008e86b769f29023ed0d0e618fb3ea6)
(cherry picked from commit ac681c966ad850b955d3f6df9c568c76bc9362f1)
(cherry picked from commit 0d7f9f8ac38e6f1c01a6e4bfb774e9b761cf1bde)
(cherry picked from commit 716d176974034d6bf52c1418f9e35fc2a5474f78)
(cherry picked from commit eb335f697eb7fd4e8f10e6d3ec1467a2e7dc0ead)
[Backport release-20.09] firefox-esr: 78.10.1esr -> 78.11.0esr
A secret key generated by the nixos module was misspelled, which could
possibly impact the security of session cookies.
To recover from this situation we will wipe all security keys that were
previously generated by the NixOS module, when the misspelled one is
found. This will result in all session cookies being invalidated. This
is confirmed by the wordpress documentation:
> You can change these at any point in time to invalidate all existing
> cookies. This does mean that all users will have to login again.
https://wordpress.org/support/article/editing-wp-config-php/#security-keys
Meanwhile this issue shouldn't be too grave, since the salting function
of wordpress will rely on the concatenation of both the user-provided
and automatically generated values, that are stored in the database.
> Secret keys are located in two places: in the database and in the
> wp-config.php file. The secret key in the database is randomly
> generated and will be appended to the secret keys in wp-config.php.
https://developer.wordpress.org/reference/functions/wp_salt/
Fixes: 2adb03fdaea6186299c6ff578bb6814d8f3bb30b ("nixos/wordpress:
generate secrets locally")
Reported-by: Moritz Hedtke <Moritz.Hedtke@t-online.de>
(cherry picked from commit 724ed08df02546fea2ab38613d615dd47461528c)
Starting from this commit
https://github.com/VCVRack/Rack/commit/2db08f15a00f6792bb3a45db31dd13f94966beed
the upstream project does not expect to use bitbucket anymore. The title
mentions that “BitBucket deleted all Mercurial repos”. Instead, an archive of
the pffft source is hosted on vcvrack.com directly. The unziped sha256 is the
same as before this change.
(cherry picked from commit 7964c9827f7ade5bc0a76e60fb364dfb72b5468e)
Quoting from oss-security:
An off-by-one error in ngx_resolver_copy() while processing DNS
responses allows a network attacker to write a dot character ('.', 0x2E)
out of bounds in a heap allocated buffer. The vulnerability can be
triggered by a DNS response in reply to a DNS request from nginx when
the resolver primitive is configured. A specially crafted packet allows
overwriting the least significant byte of next heap chunk metadata with
0x2E. A network attacker capable of providing DNS responses to a nginx
server can achieve Denial-of-Service and likely remote code execution.
Due to the lack of DNS spoofing mitigations in nginx and the fact that
the vulnerable function is called before checking the DNS Transaction
ID, remote attackers might be able to exploit this vulnerability by
flooding the victim server with poisoned DNS responses in a feasible
amount of time.
https://www.openwall.com/lists/oss-security/2021/05/25/5
https://mailman.nginx.org/pipermail/nginx-announce/2021/000300.html
Fixes: CVE-2021-23017
https://chromereleases.googleblog.com/2021/05/stable-channel-update-for-desktop_25.html
This update includes 32 security fixes.
CVEs:
CVE-2021-30521 CVE-2021-30522 CVE-2021-30523 CVE-2021-30524
CVE-2021-30525 CVE-2021-30526 CVE-2021-30527 CVE-2021-30528
CVE-2021-30529 CVE-2021-30530 CVE-2021-30531 CVE-2021-30532
CVE-2021-30533 CVE-2021-30534 CVE-2021-30535 CVE-2021-21212
CVE-2021-30536 CVE-2021-30537 CVE-2021-30538 CVE-2021-30539
CVE-2021-30540
(cherry picked from commit e522464f9afb7b1fda4c02117e6fa27ef1ade396)
The configure script checks whether iconv supports errno. Unfortunately, on PHP < 8, the test program includes $PHP_ICONV_H_PATH, which defaults to FHS path so it fails to build:
conftest.c:13:10: fatal error: /usr/include/iconv.h: No such file or directory
13 | #include </usr/include/iconv.h>
| ^~~~~~~~~~~~~~~~~~~~~~
That causes the feature check to report a false negative, leading PHP to use a degraded code that returns PHP_ICONV_ERR_UNKNOWN when error occurs, breaking granular error handling in applications.
To prevent this, let’s just include <iconv.h>.
PHP 8 just uses include path so the detection works there: https://github.com/php/php-src/commit/7bd1d703411e1e4b1f663f0cb06af619eea04b42
(cherry picked from commit 024243bac4612c62ef5be676818ed2465edae27f)
This fixes the following build error:
[14969/46739] CXX obj/third_party/crashpad/crashpad/util/util/http_transport_libcurl.o[KK[K.o[KKy_reader.or.od.ooor_linux.mojom-shared.o
FAILED: obj/third_party/crashpad/crashpad/util/util/http_transport_libcurl.o
clang++ [...]
../../third_party/crashpad/crashpad/util/net/http_transport_libcurl.cc:17:10: fatal error: 'curl/curl.h' file not found
#include <curl/curl.h>
^~~~~~~~~~~~~
1 error generated.
(cherry picked from commit c0ead3d0c4ae8762be2fdbb0e191c285876dd904)