After the fedora patches for screen sharing using pipewire got updated
for Firefox 83 (pipewire was inlined there), the nixpkgs buildInput
pipewire got stripped from the resulting firefox binary and so firefox
was unable to actually get the shared stream from the running pipewire
service.
Adding pipewire to the firefox binary with `patchelf --add-needed`
makes it atually get the stream from the service.
Fixes: #106812
libcubeb has dlopened libraries for awhile now. In nixpkgs there was
support for the PulseAudio backend doing this, however the ALSA backend
support was missed and caused issue #79310 (no sound with ALSA). This
gives ALSA users the ability to hear sound once again.
As discussed in #101429 firefox 82 started crashing when used with
wayland. A brief investigation showed that this appears to be rooted
within the LTO support that was recently added to the package. For the
time being, until someone figures out where the crashes are coming from,
we can just disable LTO.
This ensures that we aren't applying any of the experiemental pipewire
patches when the dependencies aren't enabled. As of now pipewire only
works with wayland and webrtc. If either of them are not activated we
can't build with pipewireSupport and we should not.
Regression introduced by bce5268a21.
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>
* The 'arm.patch' patch doesn't apply anymore.
* The 'build-arm-libopus.patch' patch isn't required anymore.
* See the mozilla phabricator link for the added patch.
Additionally, we are now *always* undconditionally applying all patches
to all architectures. That is, unless they have undesirable
side-effects, but those might not be fit for inclusion.
By applying all patches all the time, they'll be removed or replaced
when they stop applying.
with firefox 64 being the latest version, and the removal of
"tor-browser/icecat-like" variants, we can greatly simplify the common
firefox derivation.
