9 ms·

Debian has a strange approach to security these days. There are over 100 unpatched vurnurabilities in their version of Chromium for example: https://security-

Debian has a strange approach to security these days. There are over 100 unpatched vurnurabilities in their version of Chromium for example: https://security-tracker.debian.org/tracker/status/release/stable https://security-tracker.debian.org/tracker/status/release/s... Because of this, I don't see debian as an option for the Desktop anymore. I hope they still fix the server software in their repos.

hjek 5y ago
Looks like all the CVEs are fixed in Debian Sid at least. Edit: Not all, apparently. The whole bottom of that Chromium CVE list is still unfixed in Bookworm/Sid.
- beermonster 5y ago
  Which makes a good case for rolling release distros. Not that Sid is released but things tend to get fixed upstream quickly and there’s less lag than both testing and stable. The flip side is stuff breaks more regularly of course.
beermonster 5y ago
Check how many vulnerable packages they have against their stable release across all packages and how long until they’re fixed. It’s an eye opener.
- IshKebab 5y ago
  I guess a few volunteers can't backport security fixes to all software in the world after all.
  - beermonster 5y ago
    Indeed they can’t. So don’t depend on that.
- beermonster 5y ago
  See https://security-tracker.debian.org/tracker/status/release/stable https://security-tracker.debian.org/tracker/status/release/s...
Scarbutt 5y ago
Is this a 'chromium is not a priority because google' ? Or maybe lack of resources and the maintainer needs help.
- bluGill 5y ago
  Probably google. Chromium has made the decision to bundle all their dependencies instead of play nice with system libraries. Which means you either need to re-roll all of chromium when something is found, or you need to undo google's efforts. I don't blame distributions for refusing to give chromium poor support - it is intentionally not playing nice.
  - IshKebab 5y ago
    Yeah because when your software is at the scale of Chrome, "playing nice" with system libraries as you put it means your software is unreliable, difficult to debug and reason about. You want as few unbundled dependencies as possible.
    - bluGill 5y ago
      That is their excuse, but I don't buy it. Plenty of other projects manage just fine.
  - matja 5y ago
    Is that the case for all distros? For Arch I see only libEGL/libGLESv2 are bundled, every other library is an external dependancy: https://archlinux.org/packages/extra/x86_64/chromium/ https://archlinux.org/packages/extra/x86_64/chromium/
    - bluGill 5y ago
      All is far too strong to apply when there are as many different distributions as their are. Arch must have done the work to separate out all those dependencies, Debian has also stated their position is dependencies must be separated out as well.
NGRhodes 5y ago
How many of those vulnerabilities have patches available ?
- jeroenhd 5y ago
  From what I can tell, the problem with these packages is that the security fixes need to be backported into earlier versions of packages because upstream fixed them in major version releases. Chromium 90 does not contain all security fixes found in Chromium 93 so there are tons of CVEs open on Debian systems still rocking Chromium 90. Most packages have fixes available but Debian doesn't have the manpower to backport every single security fix for every single package. This is a result of the way their project is structured: they guarantee that no major software updates happen within Debian releases, helping you get a completely stable system, but that comes at the cost of an incredible amount of work for the Debian maintainers. Debian chooses to modify or repackage upstream versions for compatibility or branding purposes (to the ire of many open source developers, like notably that guy that made XScreenSaver. I'd link to his rant about it, but his website shows some angry rant when HN is in the referer header...) That means that maintainers still need to do manual work even when upstream has already provided them with a fix for the latest version supported in Debian. This is why I prefer to run packages from repositories maintained by the developers themselves rather than relying on Debian's maintainers. The risk of needing to update config or check for breaking changes is much higher, but the security risk and patch cycle length is much lower. Even for browsers that release actively-abused 0day patches it can take up to a day or longer for some distributions to update their packages.
  - robocat 5y ago
    > XScreenSaver. I'd link to his rant about it, but his website shows some angry rant when HN is in the referer header. Here’s the link I think: https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/ https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop...
rubyist5eva 5y ago
This is why I run OpenSuse Tumbleweed as my baseos and the software I need to run in containers. https://microos.opensuse.org/ https://microos.opensuse.org/

hjek 5y ago

Looks like all the CVEs are fixed in Debian Sid at least. Edit: Not all, apparently. The whole bottom of that Chromium CVE list is still unfixed in Bookworm/Sid.

beermonster 5y ago
Which makes a good case for rolling release distros. Not that Sid is released but things tend to get fixed upstream quickly and there’s less lag than both testing and stable. The flip side is stuff breaks more regularly of course.

beermonster 5y ago

Check how many vulnerable packages they have against their stable release across all packages and how long until they’re fixed. It’s an eye opener.

IshKebab 5y ago
I guess a few volunteers can't backport security fixes to all software in the world after all.
- beermonster 5y ago
  Indeed they can’t. So don’t depend on that.
beermonster 5y ago
See https://security-tracker.debian.org/tracker/status/release/stable https://security-tracker.debian.org/tracker/status/release/s...

Scarbutt 5y ago

Is this a 'chromium is not a priority because google' ? Or maybe lack of resources and the maintainer needs help.

bluGill 5y ago
Probably google. Chromium has made the decision to bundle all their dependencies instead of play nice with system libraries. Which means you either need to re-roll all of chromium when something is found, or you need to undo google's efforts. I don't blame distributions for refusing to give chromium poor support - it is intentionally not playing nice.
- IshKebab 5y ago
  Yeah because when your software is at the scale of Chrome, "playing nice" with system libraries as you put it means your software is unreliable, difficult to debug and reason about. You want as few unbundled dependencies as possible.
  - bluGill 5y ago
    That is their excuse, but I don't buy it. Plenty of other projects manage just fine.
- matja 5y ago
  Is that the case for all distros? For Arch I see only libEGL/libGLESv2 are bundled, every other library is an external dependancy: https://archlinux.org/packages/extra/x86_64/chromium/ https://archlinux.org/packages/extra/x86_64/chromium/
  - bluGill 5y ago
    All is far too strong to apply when there are as many different distributions as their are. Arch must have done the work to separate out all those dependencies, Debian has also stated their position is dependencies must be separated out as well.

NGRhodes 5y ago

How many of those vulnerabilities have patches available ?

jeroenhd 5y ago
From what I can tell, the problem with these packages is that the security fixes need to be backported into earlier versions of packages because upstream fixed them in major version releases. Chromium 90 does not contain all security fixes found in Chromium 93 so there are tons of CVEs open on Debian systems still rocking Chromium 90. Most packages have fixes available but Debian doesn't have the manpower to backport every single security fix for every single package. This is a result of the way their project is structured: they guarantee that no major software updates happen within Debian releases, helping you get a completely stable system, but that comes at the cost of an incredible amount of work for the Debian maintainers. Debian chooses to modify or repackage upstream versions for compatibility or branding purposes (to the ire of many open source developers, like notably that guy that made XScreenSaver. I'd link to his rant about it, but his website shows some angry rant when HN is in the referer header...) That means that maintainers still need to do manual work even when upstream has already provided them with a fix for the latest version supported in Debian. This is why I prefer to run packages from repositories maintained by the developers themselves rather than relying on Debian's maintainers. The risk of needing to update config or check for breaking changes is much higher, but the security risk and patch cycle length is much lower. Even for browsers that release actively-abused 0day patches it can take up to a day or longer for some distributions to update their packages.
- robocat 5y ago
  > XScreenSaver. I'd link to his rant about it, but his website shows some angry rant when HN is in the referer header. Here’s the link I think: https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/ https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop...

rubyist5eva 5y ago

This is why I run OpenSuse Tumbleweed as my baseos and the software I need to run in containers. https://microos.opensuse.org/ https://microos.opensuse.org/