Comparing changes
Open a pull request
base repository: NixOS/nixpkgs-channels
base: 7829e5791ba1
head repository: NixOS/nixpkgs-channels
compare: a7c70f2e10bc
- 13 commits
- 9 files changed
- 11 contributors
Commits on May 7, 2020
-
Johan Thomsen committed
May 7, 2020
Commits on May 13, 2020
-
-
firefox: Add patch to fix AES GCM IV bit size
Regression introduced by bce5268. 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 8fb4997 & moved to packages.nix)
Commits on May 14, 2020
-
Merge pull request #87746 from zaninime/sane-update-20.03
backport: sane-airscan: 0.9.17 -> 0.99.0
-
Merge #87773: firefox: patch AES GCM IV bit size
...into release-20.03
-
(cherry picked from commit 2c9cc36)
-
(cherry picked from commit c339130) This update should fix several bugs introduced in R48.
-
mkl: fix expectation of MKLROOT being set in pkg-config files
The Intel MKL pkg-config files did not work, because they expect that the MKLROOT environment variable is set. This change replaces occurences by the actual path of MKL in the Nix store. Since the pkg-config files seem to break quite frequently after upgrades, add a post-install check to validate the pkg-config files. (cherry picked from commit e88673a)
-
Merge pull request #87749 from johanot/kubernetes-1.17.5
kubernetes: 1.17.3 -> 1.17.5
-
Merge pull request #87836 from danieldk/mkl-pkgconfig-20.03
[20.03] mkl: fix expectation of MKLROOT being set in pkg-config files
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 7829e5791ba1...a7c70f2e10bc