Fixes https://nvd.nist.gov/vuln/detail/CVE-2021-33896.
The current 9acb54df9254609f2fe4de83c9047d408412de28 patch landed in
dino as 4592b72dfa324d8a4b9f8c25b359110889b2206c. Removing it from the
patch list.
In order to make the man pages accessible, the previous code used
nix-support/propagated-user-env-packages. However this file is also used to set
the PATH when the application is executed with `nix run`, thus including the
wrapped and the wrappee in the environment.
Having the wrappee enumerated first in the environment caused `firefox` to
default to the wrappee, and as such not being able to find a proper GTK. This
was a source of failures while opening a file-picker.
This change removes the code to propagate the wrappe in the environment, as the
man pages are already linked in the wrapper output.
Rambox hasn't had a stable release in a while and an increasing number
of issues which is why I don't intend to use this anymore.
While taking a closer look at the source I also realized that it uses
Electron 7.2.4[1]. This is not only EOLed[2], it also contains a few
security vulnerabilities which is why I decided to mark it as insecure.
A few (most likely not all) vulnerabilities can be found by looking at
the Electron 7 changelog[3]: after 7.2.4 there were a few more releases
with security backports - mostly from Chromium. Security issues that
were found later on (and are probably exploitable on the dependency
chain of rambox) aren't listed here. I only added two issues that seemed
applicable to `rambox`, but I haven't researched enough to check the
other ones.
[1] https://github.com/ramboxapp/community-edition/blob/0.7.7/package.json#L70
[2] https://www.electronjs.org/docs/tutorial/support#currently-supported-versions
[3] https://www.electronjs.org/releases/stable?version=7
ChangeLog: 1886c8abed/CHANGELOG.md (560-beta6-2021-05-31)
Even though this isn't explicitly noted in the Changelog, this seems to
have fixed the Element integration for me.
Additionally, I added a (hacky) `xdg-open` wrapper which removes the
`GDK_BACKEND` variable to fix the XWayland integration[1]. The problem
is that if a Firefox is running with Wayland (`ferdi` is running under
X11) and `GDK_BACKEND=x11` is passed to the `xdg-open` (and thus
`firefox`) process, Firefox refuses to start since another instance of
it is running under Wayland (but attempts to start in X11 mode because of
`GDK_BACKEND=x11`).
[1] https://github.com/electron/electron/issues/28436
