Browsers deserve special attention regarding security because it has a large attack surface and primarily deals with untrusted code downloaded over the internet. As such, they should always be kept up to date.
However, there are multiple factors right now that could prevent Firefox from being updated:
- Updates are tied to this dotfiles
- The Firefox package is currently managed by this dotfiles using Home Manager. Since this dotfiles locks its dependencies using Nix Flakes, updating Firefox would require updating this dotfiles and switching Home Manager over to the new configuration. Normally, this is a good thing because it ensures this dotfiles work the same in the future. But when browsers are involved, the work required to keep them up to date would be too much of a burden because ideally you’d have to check for updates daily.
- Broken Nixpkgs packages can block updates
- If a package used by the Home Manager configuration fails to build, Home Manager (rightfully) refuses to switch to that configuration. This means build failures of packages unrelated to Firefox can block updates of all packages managed by Home Manager including Firefox. This does happen occassionally because this dotfiles uses Nixpkgs unstable for Home Manager. There are, of course, countless ways to get around this but it’s best if no workarounds are required.
- Home Manager rollbacks will downgrade Firefox
- If a new Home Manager configuration breaks and you switch to a previous configuration, it would downgrade Firefox along with it. This is great for reproducibility but bad for software that should always be kept up to date.
- Delays in downstream packaging
- Nixpkgs generally has a good track record of
keeping packages up to date and the
firefox-binpackage, the one currently in use by this dotfiles, is likely to be updated swiftly. Even so, there’s a possibility of some packaging trouble blocking updates for a few days.
Managing Firefox using Flatpak would solve these problems. As an aside it could potentially benefit from the additional sandboxing that Flatpak offers although exceptions made for X11 still leaves a wide open hole in that sandbox.
First, install Firefox using Flatpak:
flatpak install flathub org.mozilla.firefoxThen remove the firefox package from the Home Manager configuration.
A Home Manager equivalent of nix-darwin’s Homebrew module would be nice to have for Flatpak.
This is problematic because this dotfiles relies on it to manage the Firefox configuration.
An upstream issue for this can be found here.
The current configuration sets TERM to screen-256color. Using the default
value of tmux-256color would allow various programs using terminfo to more
accurately detect tmux capabilities.
Remove the following line from tmux.conf:
set -g default-terminal "screen-256color"
ncurses 6.0 or later is required for a smooth experience. Unfortunately, macOS is stuck with version 5.7 from 2008, requiring the use of hacks.
The current configuration makes tmux assume that truecolor support is available
for all terminals that set the TERM environment variable to xterm-256color.
This becomes problematic if the terminal doesn’t support the feature, rendering
the terminal output ineligible. This is currently avoided by not using terminals
lacking truecolor. Those terminals are becoming fewer nowadays, but
unfortunately still includes macOS’s Terminal.app.
By removing the assumption that truecolor is always present, tmux can prevent garbling the terminal output by scaling down 24 bit colors to the approximate 16 bit colors. However, without better detection of truecolor support, this would limit truecolor display on terminals that do support it.
Remove the following line from tmux.conf:
set -ga terminal-overrides ",xterm-256color:Tc"
In the absense of reliable means of terminal feature detection, multiple terminal emulators have added an escape sequence for querying the terminal’s name and version. tmux leverages this information to make use of terminal features it otherwise was unable to know was available.
However, VTE, the most widely useed library for implementing terminal emulators, doesn’t yet support this feature. This leaves tmux unable to automatically assume that truecolor support is present on VTE terminals. Though VTE has in fact implemented the feature, it hasn’t made it to the release yet. Consequently, tmux doesn’t make attempts to detect VTE terminals yet.