256: Linux Geek Buying Guide for Christmas

2 Likes

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.

  1. A new version drops from Mozilla.
  2. They update all of underlying dependencies that needs to be updated first (rust compiler, etc).
  3. They compile the new version for stable’s security repo.
  4. 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.
  5. 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.

2 Likes

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.

2 Likes

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.

2 Likes

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.

1 Like

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 sid or 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.

1 Like

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.

1 Like

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.

1 Like

image

  • 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.

1 Like

image

As for Chromium… their download page states:

“Google does not offer old builds as they do not have up-to-date security fixes.”

The Debian Stable version is 90.0.4430.212 which was released May 8th, 2021 and there’s been several releases since then.

Worth noting… 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:

https://wiki.debian.org/Chromium#Installation

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.

https://security-tracker.debian.org/tracker/source-package/firefox-esr

1 Like

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.
Thank you.

FYI, Debian just upgraded to 11.2 point release which upgrades Firefox ESR to 91.4.1.

1 Like

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.

2 Likes

Thanks, everyone! Some great ideas for pressies from back in the festive season for many :slight_smile:

Sorry I’m so far behind on podcasts, but just my reflections on browser updates, particularly with Debian Stable, as it’s been my workhorse for 8-9 years now, can’t even remember(!)

As far as I know Firefox ESR (default browser under Debian Stable) tracks normal Firefox but then “freezes” in a sense for several months during which only security updates are backported, not feature updates. I think this works fine for organisations, especially given that even a few years back feature updates on browsers sometimes broke things, though that’s not heard about much these days. Every several months or-so, Firefox ESR gets a large jump in version numbers when it moves forward several months on the normal Firefox numbering, so although numbering can look “very behind” that’s actually by design, and Debian inherits the same.

The issue of timely updates to browsers, especially nowadays with financial transactions, especially, is of course crucial, I agree; and they, like all security updates, really should be implemented as fast as possible. I generally find security updates on Debian Stable to be very fast. With the larger Firefox-ESR “jump” every few months, I am guessing because of the size of the job, there may well be a lag of some days, during which I definitely think use of Flatpak Firefox is preferable. That being said, once the normal repo FIrefox-ESR has reached the same latest version-point, I trust its security more than Flatpak.

I think an important question is, besides the browser, are other security problems with underlying libraries slow to fix on Debian too? I’ve never noticed this myself, though reflections from community members would be very welcome of course :slight_smile:

As a side-note, I also think that users of LibreWolf need to keep an eye on security patches, because although it tracks normal Firefox updates, there can sometimes be a lag of a day or so (I seem to notice) before updated LibreWolf builds become available.

2 Likes

It is true, Debian applies security updates quickly. They have a default repo called ‘security’ just for that.

However, even with firefox-esr it does not pin to one version and upgrades point releases all the time. Here is my list over the last few months.

Preparing to unpack .../19-firefox-esr_78.9.0esr-1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (78.9.0esr-1) over (78.9.0esr-1~deb10u1) ...
Setting up firefox-esr (78.9.0esr-1) ...
Preparing to unpack .../1-firefox-esr_78.10.0esr-1~deb10u1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (78.10.0esr-1~deb10u1) over (78.9.0esr-1) ...
Setting up firefox-esr (78.10.0esr-1~deb10u1) ...
Preparing to unpack .../2-firefox-esr_78.10.0esr-1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (78.10.0esr-1) over (78.10.0esr-1~deb10u1) ...
Setting up firefox-esr (78.10.0esr-1) ...
Preparing to unpack .../042-firefox-esr_78.8.0esr-1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (78.8.0esr-1) over (78.8.0esr-1~deb10u1) ...
Setting up firefox-esr (78.8.0esr-1) ...
Preparing to unpack .../01-firefox-esr_78.9.0esr-1~deb10u1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (78.9.0esr-1~deb10u1) over (78.8.0esr-1) ...
Setting up firefox-esr (78.9.0esr-1~deb10u1) ...
Selecting previously unselected package firefox-esr.
Preparing to unpack .../0428-firefox-esr_78.7.0esr-1~deb10u1_amd64.deb ...
Adding 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (78.7.0esr-1~deb10u1) ...
Setting up firefox-esr (78.7.0esr-1~deb10u1) ...
update-alternatives: using /usr/bin/firefox-esr to provide /usr/bin/x-www-browser (x-www-browser) in auto mode
update-alternatives: using /usr/bin/firefox-esr to provide /usr/bin/gnome-www-browser (gnome-www-browser) in auto mode
Preparing to unpack .../02-firefox-esr_78.7.0esr-1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (78.7.0esr-1) over (78.7.0esr-1~deb10u1) ...
Setting up firefox-esr (78.7.0esr-1) ...
Preparing to unpack .../04-firefox-esr_78.8.0esr-1~deb10u1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (78.8.0esr-1~deb10u1) over (78.7.0esr-1) ...
Setting up firefox-esr (78.8.0esr-1~deb10u1) ...
Preparing to unpack .../042-firefox-esr_91.5.0esr-1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (91.5.0esr-1) over (91.4.0esr-1) ...
Setting up firefox-esr (91.5.0esr-1) ...
Preparing to unpack .../05-firefox-esr_91.4.0esr-1_amd64.deb ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
Unpacking firefox-esr (91.4.0esr-1) over (78.15.0esr-1~deb10u1) ...
Setting up firefox-esr (91.4.0esr-1) ...

So while firefox-esr is not the ‘latest version’ it does release versions with security updates. This is explained on Mozilla’s versions page. To quote:

Extended Support Release (ESR) receives major updates on average every 42 weeks with minor updates such as crash fixes, security fixes and policy updates as needed, but at least every four weeks.

1 Like

The problem wasn’t the regularity of security updates. It was how long it took from the point Mozilla released them to when they’d show up on Debian Stable.

Sort of like shipping 2 people a package every 10 days but one person lives in the same city and the other lives internationally. Both would receive packages regularly but 1 person would have old contents.

I did a quick Debian Stable VM test w/ fresh install of Firefox-ESR just now and it’s running version 91.5.0 (latest ESR) which was released 2022-01-11 by Mozilla so if you’re running Firefox ESR on Stable today you have the latest ESR version and security from Mozilla.

When I last posted above it was Dec 21st, same test, the ESR version was 78.15.0 which was ~2 months beyond the point Mozilla dropped security for 78.x so if you were running Firefox ESR on Stable in Dec you were no longer supported whether you were getting security updates or not.

Firefox-ESR on Debian Stable today:
image

So with that huge improvement, well done Debian! Well done DL!

2 Likes

Indeed Firefox-ESR on Debian Stable does update very regularly. I wonder if perhaps it was at the “big jump” a delay of a few days was (understandably) noticed by some users, prompting this concern. It was a few months ago now, so I guess my lag even on viewing the podcast is a little funny :wink:

Extra:

v91.6 is scheduled to release today which is the latest security update for Debian’s Firefox ESR (ESR point releases are the security updates). It’ll be interesting to see how soon it hits Stable.

Some house cleaning…

Back when I posted this I made an estimate of 78.x support till Jan 05 but I got it a bit muddled, support ends 3 cycles after a new “whole” version upgrade so Firefox 78.x left security support 2021-10-05 despite Debian Stable still shipping it in 2021-12-17 when I posted.

image

Strictly comparing my screenshots, Debian Stable missed over 2 months worth of security updates and had 3 months prior to make the jump to 91.

2 Likes