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.
firefoxPackages.firefox-esr-52 was removed as it's an unsupported ESR
with open security issues. If you need it because you need to run some
plugins not having been ported to WebExtensions API, import it from an
older nixpkgs checkout still containing it.
There's not really a reason to ship an unsupported ESR variant of
firefox, and if one really needs it, it's also possible to just checkout
an older version of nixpkgs.
These are all based on firefox versions with known vulnerabilities
exploited in the wild.
We seriously shouldn't ship this in nixpkgs, especially not for
sensitive applications as the Tor Browser.
`tor-browser-bundle` is just a wrapper around
`firefoxPackages.tor-browser`, so let's remove it too.
`tor-browser-bundle-bin` is the much safer bet, which is individually
downloaded from `dist.torproject.org` and just `patchelf`-ed locally to
work on NixOS.
Co-Authored-By: Alyssa Ross <hi@alyssa.is>
Co-Authored-By: Andreas Rammhold <andreas@rammhold.de>
Co-Authored-By: Graham Christensen <graham@grahamc.com>
While Firefox 68 started messing with our profiles and required new
profiles on binary location changes Firefox 69 now verifies that we
aren't downgrading to an older Firefox even of the same version. If you
switch between two channel versions and/or between nixpkgs releases
Firefox will refuse to start and demand a fresh profile. Disabling the
downgrade protection works around that issue.
This is a follow up of https://github.com/NixOS/nixpkgs/pull/66422
- rename icedtea_web to adoptopenjdk-icedtea-web to reflect the new governance
- add icedtea_web and icedtea8_web to aliases.nix for backwards compatibility
- update the attribute name where icedtea_web is used
By moving the `cfg` variable into the wrapper arguments we are able to
override it for an already wrapped package. For example, with this
change one can have
pkgs.firefox-devedition-bin.override {
cfg.enableBrowserpass = true;
}
which would otherwise be difficult to accomplish for packages having a
complicated wrapped definition in `all-packages.nix`.
Firefox running in wayland mode is unable to find and load
libEGL.so (and says so on stdout). This puts it in "basic"
mode (unaccelerated graphics) and disables WebGL. Fix this by adding
libglvnd to the LD_LIBRARY_PATH.
With a recent change to firefox (that landed in 67) a new profile is
created whenever the install location changes. Since our install
location (the binary path) always changes when we do a new build it is
rather annoying.
Setting the environment variable `SNAP_NAME` to `firefox` is supposed to
workaround the issue.
related to #58923
Woarkound taken from 1ff8b6c3d8
cc @rail
Firefox now requires `llvm-objdump` during the build phase. The aarch64
patches do no longer apply. So far I am guessing that they have been
merged. We should verify that.
You can now optionally invoke update-source-versions with:
* --system flag changing the host platform, to be passed dirrectly to Nix commands.
This is useful for binary packages which have different sources for each platform.
* --file flag allowing to change the file to be modified. This is useful for packages
that offer multiple variants, listed in a different file than the derivation itself;
e.g. packages.nix of Sublime Text 3.
* --version-key, which is now a keyword flag instead of a positional argument.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
The firefox wrapper now supports setting the GDK_BACKEND to wayland
which is useful in cases where firefox would be started from within an
X-Application inside of wayland. GTK/GDK would otherwise default to the
X11 backend in those situations.
The intention is that people that are using wayland primarily pull in
the new `firefox-wayland` top-level attribute into their environments
instead of just `firefox`. Firefox will then always be started with the
correct rendering backend.
This adds support for building firefox with the gtk wayland backend. It
should work on all the flavors that use >=gtk3. Using the wayland
still allows using the X11 backend.
It works, but this state is far from ideal: GNU guys update generated source
tarballs very infrequently. Ideally, src needs to be generated by running
makeicecat over firefox src. Will do later.
There have been some more changes to the source tree which broke the
buildconfig patch. This commit adds another patch that can be used for
the future versions. Once all the flavors are based off a new(ish)
firefox release we can remove the old patch.
Firefox >=65 will depend on icu >=63. All the older firefox versions
(and derived packages) seem to work fine with this change.
Also the system path environment patch will fail to apply since there
was a trivial whitespace change in the source file. By adding `-l` to
patch we can avoid having to track two patches that do basically the
same. Having patchFlags per file without resorting to pre-/postPatch
would be nicer but there doesn't seem to be a facility for that right
now.
To make updating large attribute sets faster, the update scripts
are now run in parallel.
Please note the following changes in semantics:
- The string passed to updateScript needs to be a path to an executable file.
- The updateScript can also be a list: the tail elements will then be passed
to the head as command line arguments.
rust-cbindgen did apply some breaking changes which requires the added
patch in order to compile until a firefox version with the fix gets
released. Firefox 63.0.3 is supposed to carry the required patches. This
should only be required for a short term.
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12392: Crash with nested event loops
When manipulating user events in nested loops while opening a document
through script, it is possible to trigger a potentially exploitable
crash due to poor event handling.
- CVE-2018-12393: Integer overflow during Unicode conversion while loading JavaScript
A potential vulnerability was found in 32-bit builds where an integer
overflow during the conversion of scripts to an internal UTF-16
representation could result in allocating a buffer too small for the
conversion. This leads to a possible out-of-bounds write.
Note: 64-bit builds are not vulnerable to this issue.
- CVE-2018-12395: WebExtension bypass of domain restrictions through header rewriting
By rewriting the Host request headers using the webRequest API, a
WebExtension can bypass domain restrictions through domain fronting.
This would allow access to domains that share a host that are
otherwise restricted.
- CVE-2018-12396: WebExtension content scripts can execute in disallowed contexts
A vulnerability where a WebExtension can run content scripts in
disallowed contexts following navigation or other events. This allows
for potential privilege escalation by the WebExtension on sites where
content scripts should not be run.
- CVE-2018-12397: Missing warning prompt when WebExtension requests local file access
A WebExtension can request access to local files without the warning
prompt stating that the extension will "Access your data for all
websites" being displayed to the user. This allows extensions to run
content scripts in local pages without permission warnings when a
local file is opened.
- CVE-2018-12389: Memory safety bugs fixed in Firefox ESR 60.3
Mozilla developers and community members Daniel Veditz and Philipp
reported memory safety bugs present in Firefox ESR 60.2. Some of these
bugs showed evidence of memory corruption and we presume that with
enough effort that some of these could be exploited to run arbitrary
code.
- CVE-2018-12390: Memory safety bugs fixed in Firefox 63 and Firefox ESR 60.3
Mozilla developers and community members Christian Holler, Bob Owen,
Boris Zbarsky, Calixte Denizet, Jason Kratzer, Jed Davis, Taegeon Lee,
Philipp, Ronald Crane, Raul Gurzau, Gary Kwong, Tyson Smith, Raymond
Forbes, and Bogdan Tara reported memory safety bugs present in Firefox
62 and Firefox ESR 60.2. Some of these bugs showed evidence of memory
corruption and we presume that with enough effort that some of these
could be exploited to run arbitrary code.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-27/
