And the package in Debian Stable (aka bookworm) is too old to be affected by the vulnerabilities in 5.0.0.
I used to hate that Debian always was behind on software versions, but now I use different package sources for the few applications where I really don't want to rely on old software (like browsers), and otherwise doing great with the old stuff :-)
Glacial page bedrock of an OS with optional sandboxed more-up-to-date userspace packages and runtimes that can be layered on top of the host system was the dream of flatpak/snap/appimage, right?
Yes, though that comes with its own headaches since the data those sandboxed applications are supposed to touch are the only actually valuable data on my computer. (How many versions of OpenSSL are currently running on my Silverblue system? I literally couldn't tell you.) My spreadsheet is only vouched for by some random dude on Flathub and it can steal all my financial information. But at least it can't add a printer, or delete a system file that I can freely download from the Internet at any time.
This a decent observation, but I would add that some other Flatpak app that you run might be correctly sandboxed from accessing your financial information, and this is the real benefit of such a system.
If you're running Firefox on Debian please make sure you manually update it since the package repo's been down for a while. I filed a 'support' ticket first ( https://support.mozilla.org/en-US/questions/1510388 ) since it seemed to be the proper place, but no one seems to look at those.
The repo appears to be working for installing/updating packages. Mozilla should allow file listing which should fix the 404s, and make this repo behave as expected when manually browsed (Apparently hosted on a Google webserver; maybe Google forbids this?).
apt-get changelog firefox
Get:1 store: firefox 138.0.3~build1 Changelog
Fetched 129 B in 0s (0 B/s)
firefox (138.0.3~build1) UNRELEASED; urgency=medium
* N/A
-- Mozilla <release@mozilla.com> Mon, 12 May 2025 12:40:33 -0000
date
Tue May 13 08:56:09 AM PDT 2025
Or, to really prove it to yourself, you can re-download the package:
I will have to look into that more tomorrow. My only Debian desktop is a laptop at family's house and currently asleep. It mentioned an error with the repository but my first troubleshooting step was to try to manually verify I could _get_ to the repo in a browser.
This is about Mozilla's builds of Firefox for Debian, not Debian's builds, right? So regular Debian users who run the default Firefox (firefox-esr) would be unaffected.
Correct, but that's firefox-esr not firefox. At one point I found it necessary to switch as there was an issue with security updates, but that might have been an issue in that particular system's configuration that I since resolved.
To be clear for the sake of other readers, Debian's firefox-esr package is Firefox.
It's simply a release from Mozilla's Extended Support Release channel, as distinct from the Rapid Release channel that you are apparently using. Not a different project/product.
If one is in group utmp, one can mess with the login accounting database: the table of currently active logins, the log of log-ons/log-offs, and the table of per-user last logins.
The login accounting system that Linux-based operating systems have inherited from Unix really has never reconciled its initial real-terminal-login-only superuser-managed design with the fact that non-superuser programs that allocate pseudo-terminals (e.g. any local terminal emulator, NeoVIM, tmux, screen) want to (over)write entries for those pseudo-terminals in the login accounting database to make the output of the "who" command (and its ilk) more complete.
The best approach I've seen was to re-think the idea; have the pseudo-terminal-using programs run entirely unprivileged and use a client-server model where only the server actually has access to the database files.
Laurent Bercot did this. It fixes many holes, including that the log of log-ons/log-offs is made truly append-only (modulo superuser access to the underlying files). But it has the same architectural problem that any client in the group can overwrite any currently active login record if it knows the record ID, which by design (and the Single Unix Specification) there's an API for enumerating.
