Live data from Hacker News

Google Chromium drops support for Linux 3.16 and earlier

lists.debian.org

111–120 of 139 posts

Re: Google Chromium drops support for Linux 3.16 and earlier

#111
post #69

Earlier quoted context omitted.

Without defending Chrome team here; when a distro provides long time support (say > 1 year) I don't think is upstream responsibility to support the packages for that period of time. If the distro is upgrading the browser package I think that may break the API/ABI stability that a long time support distribution should provide, so I can't see why this is a Chrome problem. Also it sounds wrong that a web browser depends…

Well put. Although someone makes a LTS distribution, it really does not mean 3rd parties would be compelled or required to support that steadily aging platform. When you combine the fact that not even Ubuntu developers really support the LTS (9/10 of the developers flock to the newest release, and the bug reports towards LTS get generally ignored - the LTS tagged bug queues are graveyards), I can not see the whole po…

Well it's tricky, MSFT actually ties certain vendors to support their OS as long as it's under support. For example if you want to participate in the WHQL program you have to have a version for each supported MSFT OS.

Chrome is still supported on Windows XP, so is FF, on Windows vendors not only do not seem to drop support but actually extend beyond MSFT's requirements.

While canonical is surely not MSFT but when you make an LTS program you either have to get 3rd party vendors on board, or manage and update the packages yourself to make sure they will be compatible with your own software, or to make updates to your LTS distro to keep it compatible with the newer packages.

While the OS is quite important, it's usually not the piece of software neither end users nor corporate users care about, for them it's just a platform to run the software they actually use. And if the platform loses support for a major piece of software after less than a year you can't blame anyone besides the maintainer of that platform.

The Linux community really needs to get their shit together, with every step forward these past few years they've seen to be taking 2 steps back. With PAAS becoming more and more popular, it really should only take Apple to release a general server OS (no OSX Server doesn't count) to push it back completely into the realm of BBS hobbyists these days.

Re: Google Chromium drops support for Linux 3.16 and earlier

#113
post #20

Earlier quoted context omitted.

Chrome isn't your average application, though - it pioneered the modern use of tight process sandboxes in general (in client-side applications, anyway), and in particular was the biggest motivating client for (and Kees Cook on Chrome OS Security wrote some of the code for) seccomp-bpf, the ~3-year-old sandboxing mechanism that allows precise control of permitted syscalls and syscall arguments. The incompatibility her…

Google invented sandboxing in client apps? I don't know who's more arrogant - Google or their fawning fanboys.

Google created seccomp-bpf which is crucial to a meaningful sandbox and has no equivalent on other platforms. It was not an obvious innovation or it would have been done years earlier. It exists because someone paid by Google to improve Chromium security had the epiphany that BPF would be a good way to filter system calls.

Re: Google Chromium drops support for Linux 3.16 and earlier

#114
post #45

Earlier quoted context omitted.

Calling comex a "fawning fanboy"? That's ballsy for a throwaway account.

Claiming that Chrome pioneered sandboxing doesn't pass the smell test, irrespective of how many Google employees (according to your profile) are backing you up.

No one is claiming that Google invented sandboxing. You should stop lying to push your bias because it only makes you look foolish.

Re: Google Chromium drops support for Linux 3.16 and earlier

#115
post #29
post #26

Earlier quoted context omitted.

On the flip side, chrome is also one of the tools used to convince people that web should somehow be equivalent to native. Which, really, just doesn't make any bloody sense. If web pages were content to showing web sites, the vast majority of the motivation for heavy sandboxing, Chrome style, would be irrelevant.

You have code running on your computer for rendering the content. Historically, pictures (GDI+ buffer overflow, and others) and .pdf files has been used for exploiting bugs in that code. Sandboxing would have made that a non-issue, or at least less severe of an issue.

It's still a serious issue even with a sandbox, both because of the endless stream of kernel vulnerabilities and similar issues in userspace processes the sandboxed processes communicate with to get work done.

Chromium's use of seccomp-bpf is solely to crack down on kernel vulnerabilities, as it's an additional layer over a sandbox already providing all of the security boundaries they need. It moves things along pretty far, but there are still at least 1-2 holes found every year.

It's definitely an improvement over browsers like Firefox where there are at least 3-4 unmitigated remote code execution vulnerabilities fixed every six week cycle...

Re: Google Chromium drops support for Linux 3.16 and earlier

#117

Earlier quoted context omitted.

That seems like an exceedingly childish exchange.

To be fair Google's whole business model is based on spying on people to gather data for ad placement. If we're being entirely honest a browser which sends every url you visit to Google by default is spyware.

Stop lying to push your biases please. People are smart enough to see through it.

Chromium is an open-source project and no one has ever identified any spying code. If you think Google is capable of sneaking it in, then you should be worried about other projects they contribute to like GCC, LLVM and above all else the Linux kernel.

Google has no business interest in putting backdoors into software that they've open-source for goodwill in the first place... they're certainly not open-sourcing this with the expectation that the FOSS community will help. Just look at the issue that was linked here: they offered to accept and even help people develop patches, but no one was interested - not one developer from a distribution using Chromium with an old kernel contributed. I think it's quite reasonable to drop support for old kernels when clearly no one is interested in it.

Re: Google Chromium drops support for Linux 3.16 and earlier

#118
post #44
post #20

Earlier quoted context omitted.

Chrome isn't your average application, though - it pioneered the modern use of tight process sandboxes in general (in client-side applications, anyway), and in particular was the biggest motivating client for (and Kees Cook on Chrome OS Security wrote some of the code for) seccomp-bpf, the ~3-year-old sandboxing mechanism that allows precise control of permitted syscalls and syscall arguments. The incompatibility her…

Chrome certainly didn't pioneer anything. Google devs brought seccomp-bpf to the kernel, which is a simpler alternative (but also not always as useable) to many other mechanisms. Chrome is one of the first products on linux with a large amount of users to support a reasonably strong sandbox. But that's not what pioneering means. Of course, seccomp-nonbpf, selinux and quite a few other mechanisms have been around for…

There is no stable sandboxed browser protecting against kernel vulnerabilities on any platform that I know of prior to Chrome. That's the very definition of pioneering. Do you have an example of prior art? There may be sandboxing mechanisms in various kernels, but that's not what browser users care about.

As for the other points:

* "seccomp-nonbpf" is a vastly more limited mechanism than seccomp-bfp, and inappropriate for Chrome use-case. http://en.wikipedia.org/wiki/Seccomp. seccomp-bfp is pioneering in Linux kernel space, even if, ironically, the team might not have wanted to spend their time there. See below.

* Popular consumer distribution of Linux doesn't have SELinux enabled by default. https://wiki.ubuntu.com/SELinux. "SELinux can be enabled in Ubuntu by installing the "selinux" meta-package". In my bubble we everyone uses Ubuntu on desktop, apologies to other distributions vying for the title of "popular consumer Linux distribution".

* Not sure why we are talking about security mechanisms on non-Linux kernels. Chrome is a browser, the team's job is not to innovate in the kernel space. http://www.chromium.org/developers/design-documents/sandbox. "Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't.".

Re: Google Chromium drops support for Linux 3.16 and earlier

#119
post #69

Earlier quoted context omitted.

7 months. Linux 3.16 is 7 months old. The attitude of the Chrome team is extremely obnoxious. Some distributions support versions 10 years and beyond and there are plenty of reasonable reasons to want to use them as such. Requiring a 7 month old kernel is absurd. I keep getting the feeling that Chrome isn't the browser for me.

Without defending Chrome team here; when a distro provides long time support (say > 1 year) I don't think is upstream responsibility to support the packages for that period of time. If the distro is upgrading the browser package I think that may break the API/ABI stability that a long time support distribution should provide, so I can't see why this is a Chrome problem. Also it sounds wrong that a web browser depends…

A year is not along time 10-20 years is a long time

Re: Google Chromium drops support for Linux 3.16 and earlier

#120
post #30

Chrome "unofficially" dropped support for pre-3.16 kernels, such as the kernel in Ubuntu 14.04 LTS, about half a year ago. More precisely, they introduced a bug that caused installing extensions to fail with that kernel, and then declined to fix it. https://code.google.com/p/chromium/issues/detail?id=401655 See comment #47: "Ok, while it sounds like this is technically a regression, I'm going to mark this as Wontfix…

Happily there's an even more reasonable workaround of upgrading to a browser that doesn't dictate kernel versions.

Agreed, though I doubt this is going to be a popular opinion. I've been steadily divesting myself of pretty much all Google products because of these sort of arrogant and obnoxious decisions.

First it was the won't fix VPN + countless other Android bugs, then repeatedly breaking Canvas in Chrome (why do I care about this? well Chrome auto-updates for 99% of users, so when they break canvas they're breaking sites) and not least the numerous platforms and products they introduced and then dropped despite vibrant & loyal user bases.

Post reply on HN