Thanks for bringing attention to Debian, although I wouldn’t classify it as troubling per se, what you are seeing here is the normal Debian processes at work. Let me preface this with that I have been using Debian exclusively for more than ten years.
Debian is a community based distro, it doesn’t have any major corporation backing it and controlling the direction that it goes, it is a mostly a group of unpaid volunteers that do all of the work.
The typical Debian user doesn’t crave new software just for the sake of it being new, someone who does would be better served by using a different distro.
The entire reason that you are not seeing any chatter on Debian, is because for them this is the normal state of affairs, which is roughly this for both Firefox-esr and Thunderbird.
- A new version drops from Mozilla.
- They update all of underlying dependencies that needs to be updated first (rust compiler, etc).
- They compile the new version for stable’s security repo.
- Once that is released then they they back-port to all of the other releases that are still active, old stable, old old stable, etc.
- By the way, they are doing this for all of the architectures, ten if I counted correctly.
All of those steps take time to implement, is it perfect, no, but I am quite surprised at how well it works overall.
So once the above steps have been completed, plus thanks to Firefox’s constant stream of security issues, Debian will have the latest Firefox-esr and Thunderbird in the security repo’s for all of the active releases, which is pretty decent in my book.
As a Debian user and advocate myself I found it a little bit concerning to be honest.
I agree with most of the above comments about how Debian works but a browser is essential and it is a security hole in the operating system to use an outdated version of Firefox! I would even say it is unacceptable.
The state of browsers in Debian is very poor in general. Look at the Chromium package. The project itself discourages its use but still packages it. I will not mention all the other browsers. But you should not use them.
In the last release they needed months and months to offer a recent and patched version of Chromium.
In my opinion there is no excuse for that regardless how the packaging works. I am not sure if there is not enough manpower or the project just fails with the whole amount of packages they offer, one of the largest repos in the Linux ecosystem if not the largest of any.
So it is good to be aware of that.
I wonder what the underlying reason is that the Debian project couldn’t move the browser portion more quickly? Do you think it is due to dependencies? If I were running Debian, I would probably use Flatpak or Snaps as a stop-gap, especially since this does become a security concern.
So I totally did not know about the extensions available for standard notes and now am really happy to find them. I was using simple notes but found out they were not encrypted in any way, so I was looking for something a little more private as well as open source, so my two options seemed to be simple note and Joplin. I first tried standard notes and was really not that impressed because I couldn’t do the simple thing of adding check boxes for grocery list and stuff. So then I tried Joplin next, it has a really awesome desktop app, and you can use your own cloud services to sync it between devices(like Nextcloud and some others) but the mobile app stinks, so I wasn’t happy with it either but stuck with it because of how awesome the desktop app is. Now while watching this show I started playing with the standard note extensions, and I am now much, much happier with it and am now switching back to it.
a better question is why does firefox not build on bullseye, which isn’t all that old. for mesa? a graphics acceleration library? maybe mozilla can take a look at their build requirements.
flatpak and snaps add a messy layer of abstraction and it just kicks the security can down the road to whomever’s maintaining it. At least with traditional packaging maintainers are forced to keep up with new libraries (that often improve security) but with containers you can just party like it’s 1999 forever. It feels like replacing one problem with another.
Something Debian (or any Debian user) can implement right now is packaging the
testing versions of their favorite browser as an AppImage and installing it in
/usr/local/bin. It keeps maintainership/packages within the Debian family and it’s pretty seamless compared to flatsnaps.
Using flatpaks or snaps is against Debian’s strict policy of maintaining packages by its official maintainers and I agree here.
They should just open the gates for newer packages faster when it is needed like in this case, even if it is because of Mesa or Rust, but they are just too conservative about that because the policy only allows patches and security updates and “by no means” any new package to go into stable’s repository. Here you can already see the problem regarding Chromium.
Though sometimes you have to make an exception I would say instead of discussing the problem endlessly why something cannot be packaged.
Now I am not really sure if the missing libraries can be back-ported even to the same version of Mesa or Rust, my point is that I see it as an ideologically issue rather than a technical.
I think a good Christmas geek gadget would be pretty much anything Raspberry Pi (which isn’t already sold out). Or decent-quality accessories (known to be compatible) to go with such boards.
I recently got a CM4 in a small router appliance that I’m quite happy with. I must admit those CM4 boards are really cute and small, when you see them in real life.
- Debian Stable is currently on Firefox ESR 78.15 released 2021-10-05
- Version 91.x came out 2021-10-28 and has had 2 releases so far
Mozilla release calendar: Firefox Release Calendar - MozillaWiki
According to this Mozilla doc, there’s “(at least 12 weeks) overlap between the time of a new release and the end-of-life of the previous release”
So while Mozilla won’t consider Debian’s ESR EOL until ~Jan 05, it’s a pretty major leap behind the current ESR.
There’s also this: “Maintenance of each ESR through point releases is limited to high-risk/high-impact security vulnerabilities” so lagging point releases is lagging behind high-risk/high-impact security vulnerabilities.
As for Chromium… their download page states:
“Google does not offer old builds as they do not have up-to-date security fixes.”
ungoogled-chromium is also version 90.0.4430.212.
The Chrome Release Cycle gets a bit above my head but i’m reading the dev builds as having no more releases after 6 weeks which’d put the Debian version several months behind on support.
Just to emphasize on this, here is Debian’s own recommendation:
As of 2021-10-14 19:19:07, Debian’s Chromium package in buster, bullseye and bookworm repository remains vulnerable to numerous CVEs as outlined in the Chromium Security Tracker. Consider using an alternative browser like Firefox, Brave or ungoogled-chromium.
Edit: As of now Firefox ESR 78.15, regardless of its lifespan, is vulnerable in all Debian branches except sid and testing.
I had question on the Yubikey is there a specific model that is best? That tech is relatively new to me and I collect all things techy. So I would like to know more from your prospective.
FYI, Debian just upgraded to 11.2 point release which upgrades Firefox ESR to 91.4.1.
As a Debian guy here I just wanted to give the perspective that Debian’s release schedule is famously slow and only until relatively recently have we started having multiple released of browsers per month, let alone in a year.
Does no one else remember how FF changed its naming scheme to follow Chromium’s inflated build numbers? Basically, after v38 everything exploded, and we would have multiple versions released per a year. It is a fast moving target, and you have to wonder how anyone who packages it for as many architectures as Debian ever gets it done.