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.
See comment #47: "Ok, while it sounds like this is technically a regression, I'm going to mark this as Wontfix because there is a reasonable workaround of updating your kernel."
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 on the kernel version; so I'm with you that there are other browsers supporting Linux.
I'm sorry, but we ARE talking about arguably the most important piece of software running on an end-user device not being supported on a less than ONE YEAR old distribution. Not 5 years, not 15 years. Less than a year.
The result of your argument is basically returning to dark ages of having to support old broken IE6 because the vendor couldn't be arsed to support an older platform. When did dropping support for a less than a year old product become something to be applauded?
My argument is that open source is what it is. Read the license and you'll find that there's nothing about free support; and if for some reason it breaks... you keep both pieces.
I know this puts distributions in a bad situation, but unless the users can force the upstream project to be more user friendly, I think the only option is to switch to a different software (hint: Firefox).
You seem to think I endorse Chrome team's behaviour on this, and I don't. That doesn't change reality though.
Open source is what it is, but not all open source is equal.
I often see versions of this argument more or less opposing complaints against open source products. It has some merit, depending on circumstances. Circumstances are important.
Chrome isn't some guy's spare time project, or something done by a team of corporate and personal volunteers. Chrome is a product. Looking for Google's valuation comes up with an analysis that it will likely be the first or second company to be valued at a trillion dollars. Chrome enjoys nearly a 50% browser market share. Google has one of the strongest hands in shaping technology today, and it seems they aren't always making the best decisions; not that one would expect such a large company to always make the best decisions (or that there would be a consensus on _what_ is the best decision).
I've never paid for anything made by Google, but I am a customer regardless; so are you. Money hasn't changed hands but they have certainly profited from the relationship, and so have I.
---
"If you don't like it, submit a pull request" -- that response always rubs me the wrong way. To be clear, some of the loudest complainers about open source projects are entirely too entitled, but those that aren't do have a point sometimes. I believe that whether you are a guy with a hobby making $0 or a company valued at $3.8 * 10^11, you owe it to yourself and your users to maintain a certain level of quality if you create a popular product. More of a personal philosophy than the expectation of a legal obligation of course, but I think just as valid.
I always have mixed feelings when Google has a project with two versions: the open source one and the binary only based on that one. Chrome and Chromium are not quite the same thing after all.
I don't know for sure, but for Google Chrome may be the product and Chromium just a convenient way to make it happen.
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 point of making LTS version available in the first place.
That being said, 7 months is a bit small window of support for a specific platform component. I would understand not supporting 1-2 years old kernel/glibc/whatever, but 7 months is really not enough.
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.
What about XP? It's old, unsupported and littered with security holes. It has 50% penetration in China because it's the last version of Windows with easily circumvented piracy countermeasures and because it runs better on 10-year-old hardware. I don't think it's any guide to how long long-term support should be.
Well, it's a bit more subtle than that. Because it were the Chromimum developers which created the feature in the first place.
seccomp was introduced in the Linux kernel because the Chromium developers wanted a good way to reduce the harm Chromium browser processes could do if they got compromised.
Chromium is pretty much the only user of seccomp right now.
(although for example Docker also has support for it, but I don't think it's widely used)
Now Kees Cook who implemented TSYNC for seccomp in the Linux kernel works for Google. The kernel commit even lists his @chromium.org email address.
No, user software should not dictate kernel versions, unless there is no alternative (e.g. security issues). Maybe I'm unique in this, but I don't have a single-purpose workstation. My computer does not exist to run Google Chrome; I have lots of applications I like to use.
Consider a workplace setting where someone may have other software which is much more conservative about using new features. A newer kernel may cause that software to stop working entirely; upgrading a kernel rarely introduces just the feature Google Chrome wants to use. You could tell those people to just use a different browser, but there are a lot of workplace users - is this new feature right now really worth losing those users?
For all the effort the Linux community has put into keeping Linux distributions secure and making them easier to use, now Google is saying Linux users have to either know how to update their kernel outside the provided package manager to use Chrome, or use whatever older version of Chrome still supports their kernel. This is going to frustrate or alienate most new Linux users as well as veteran users who like stability and package management. Is using this new feature right now really worth losing those users as well?
Chrome is arguably the most popular browser on the Internet. They ought to be more conservative about things like this; the right way to handle a new kernel feature is to either delay its use until supported by the majority of your users, or to detect it at runtime and use it if available. IMO, what they have done here is lazy and arrogant. A very poor decision.
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.
First, I'll note that plenty of people use Chrome without extensions. This issue wasn't a showstopper for any of them.
Second, you cut out the rest of the comment:
"If that causes great hardship for anyone and you want to do the work to figure out what's going on submit patches to fix it, I can provide pointers for where to start looking and code reviews for the patch."
Since that comment has anyone done anything other than updating their kernel and/or complaining? If not, why would the Chromium team think this issue was important?
I don't think the other half of that comment affects my point: that the Chrome team is declining to fix bugs that only manifest on older kernels, and hence it's reasonable to call those kernels "unsupported".
I agree that it's the Chrome team's prerogative to decide that supporting those kernels is unimportant.
So you only care about problems if the user is a skilled developer, and then only if they're actively solving the bug (because skilled programmers are never involved in other projects eating their time...)?
This seems like a colossal mess waiting to happen. I'm glad that I read their plan, so that I can completely avoid it.
The allure of Ubuntu LTS releases (currently 12.04 and 14.04) is the extended support cycle -- practically speaking the kernel is the biggest component of this for a lot of people.
If you use the 3.16 kernel (from Ubuntu 14.10) on 14.04, you are now on a 6 month support cycle [1]. One which doesn't even have defined dates (they're all still TBD). Now you have to keep running on the kernel upgrade treadmill to maintain support, moving to backported kernels from progressively newer Ubuntu releases every 6 months.
> practically speaking the kernel is the biggest component of this for a lot of people.
Really? I mean, step back from your initial gut reaction and ask yourself how many software developers could even name which version of the kernel their code runs on without checking. Most developers never make a syscall directly and, increasingly, aren't even calling something like libc directly because they use higher-level libraries.
Sure, some people really care cause they recently hit an issue with specific drivers and a few people are using a really new feature, but that's a much smaller group than the number of people running code which doesn't even depend on Linux, much less a specific point release.
Looking at the release notes, I'd say there are a LOT more people affected by real bugs which are fixed in 14.04.2 than will be affected by hypothetical bugs nobody seems to have noticed yet:
Overreacting much? The shortened support is limited to the packages you upgrade. It's a 9 month cycle with a new version available every in 6 months. Most importantly, these are just packages, they can be uninstalled of they don't work and you fall back to LTS versions. And this is all the same for 12.04.
For some reason, Chrome seems to work fine with extensions on my Ubuntu 14.04, kernel 3.13.
I agree with those saying this is completely stupid. In corporate environments, there are a lot of Ubuntu LTS, RHEL, and CentOS desktops. They won't be upgraded to >= 3.16 for years.
Really, a browser is now dependent on a particular Linux kernel?
For example RHEL/CentOS 7 which was released just last year with at least a 10 year support ahead of it is now obsolete according to them because it has a kernel version 3.10...
Not that many people are on desktop versions of those OSes, and those that are will not use Chrome (for example, US govt loves them some Desktop RHEL systems, but Chrome is usually not allowed there anyway), but just highlighting how still seems a bit crazy.
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 here is related to a new seccomp feature. I don't know whether it's reasonable to drop support for older kernels, but it's no surprise that Chrome is using the latest and greatest in kernel sandboxing support.
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 a longer while. In non-Linux kernels in fact, there are FAR more secure mechanisms (but also, they don't run Linux binaries..)
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.".
if you give enough details you'll always find a way to work around words.
For example if i ship a copy of webkit with my ui on top with a sandbox I'll pioneer that. Or a shell. Or a text editor. Or whatever you want. A blue wheel of 29.0349in on a bike. etc.
> Of course, seccomp-nonbpf, selinux and quite a few other mechanisms have been around for a longer while. In non-Linux kernels in fact, there are FAR more secure mechanisms (but also, they don't run Linux binaries..)
You're quite confused. SELinux, AppArmor, SMACK, etc. do not overlap with seccomp-bpf which exists to protect the kernel itself. Chromium has a working sandbox with or without seccomp-bpf based on a chroot, namespaces and IPC protocols. It needs seccomp to mitigate kernel vulnerabilities, which are not at all uncommon.
they actually do the control in a very similar way. its the model of how the control is decided that differs.
in other words, they're all blocking syscalls depending on the arguments/syscall name/etc. LSMs and seccomp-bpf alike.
There is no Windows sandbox (including the Chromium one) that's comparable to the quality of Chromium's Linux implementation.
Note that seccomp is a layer on top of the layer-1 sandbox implementation based on a chroot and namespaces. There is no equivalent to the layer-2 sandbox used to protect against kernel vulnerabilities on other platforms.
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.
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.
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...
When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things.
Google's being aggressive about taking advantage of a kernel-level security feature that they developed to solve a real problem. This seems like a good thing overall.
> When you commit to a 10-year support cycle, you'd better be prepared to backport quite a few things.
OTOH, when you make a break-the-world release every six weeks, you can expect lots of breakage when dealing with the rest of the world. From what I can tell, Google pushed a feature they wanted into Linux, then didn't bother to think about backward compatibility. This would be fine if Chrome weren't force-updating software -- people on older kernels could just wait and update when they updated their kernels -- but alas that is not the case.
"Google's being aggressive about taking advantage of a kernel-level security feature that they developed to solve a real problem. This seems like a good thing overall."
Yes, it is a good thing for the people who 1) use desktop linux and 2) use a rolling distribution or a distribution that was released within the last year. I suspect that might be a rather small percentage of the Desktop users in the world.
It simply means that people who 1) use a desktop Linux and 2) use a stable distribution can't run Chrome (which I imagine solves the security problem in another way). This fraction of a fraction may be larger (corporate desktops, e.g. RHEL, CentOS, Scientific Linux, Debian stable, Ubuntu LTS &c)
Google does a lot of Linux kernel work, a lot of gcc work, a lot of clang work, open-sources monumental amounts of code, pays several hundred students to work on open-source during summer.
If that's not enough to "generate a ton of good will" then doing one more minor thing won't change anything.
If they start giving out hundred dollar bills, you'll be complaining that it's not two hundred dollar bills.
I'm aware of the work they do. A couple of stupid decisions can cancel out a lot of good will. Not back-porting key pieces of tech and sunsetting products without open-sourcing them is going to counteract the good will they generate. I actually don't dislike Google, and appreciate that they've been a decent open-source player.
This is not so minor.
If they start handing out hundred dollar bills I would think they'd gone nuts.
I don't think the Chrome dev team would want to drop earlier kernels that easily, but this option must help development a lot. From looking, it seems to be something regarding synchronising SECCOMP filters between different threads (SECCOMP is a security sandbox). I imagine this removes quite a bit of code, or fixes some serious corner cases.
It's common way to see things now, although I guess it's pretty normal. I always viewed distro as something people do primarily for themselves, if you want something from particular distro — you join the community. If your wishes are drastically different from what this community accepts — you go to another community or build your own. I'm not saying people should be rude and talk nonsense, but it seems that too many people tend to forget: Debian mailing list (or lkml, or what else people complain about) is not Starbucks or McDonalds where people are paid to smile and do what's requested.
That's been said, I find question about TSYNC completely appropriate, and its support to be expected, but answer about "Google spyware" was funny and enjoyable anyway. So, yeah, maybe childish, but not "exceedingly childish".
Could you explain what you mean by "unprofessional" here? Personally Google's business model seems to be the unprofessional thing in this conversation.
But it's not a business and that person wasn't a customer. Debian is a community, bound partially by common technical ideas about packaging, stability and security, and partially by philosophical ideas about Free software.
Their goal is not to satisfy everyone who comes to their mailing list, that would be insanity.
Sure, but most people would consider the original poster's request as quite reasonable.
Instead of considering it in a balanced way and producing a polite & considered response, the response was idealistic rhetoric. For better or worse, I think that does qualify the attitude of response as "unprofessional", as stingraycharles pointed out.
I think Google is more or less "in the wrong" too, but a less snippy, snarky response would probably do more to convince people of that. "You catch more flies with honey than with vinegar", as they say.
I don't really think this is a particularly childish exchange. But either way, it struck me that when you consider the reason for the exchange: a unilateral decision made by Google -- that kind of reminds me of how Google handles support: they don't.
On another note - does chrome/chromium build on freebsd? Is there an equivalent api there?
I certainly sympathize with the chrome/chormium team: they're of course free to abandon users on old kernels/os'. It is a bit odd to demand a new kernel (newer than most Android installs uses) for a browser. We've come to learn to live with not having stable and secure browsers (choose either - usually choosing the updated, secure browser makes more sense). It's a bit more hairy when you need a new kernel. But I suppose newer hardware can just run Chrome (or chrome os) in a kvm vm anyway...
The questioner is using Chrome and already made his mind up that it is an acceptable trade-off. He is asking for a simple yes or no, but instead gets useless Chrome bashing.
Of course, no one can expect free support. But if you want to have/keep users as well, this is perhaps not the way to treat them ;).
Even if you wanted to sneak in the Chrome bashing, it would be better to answer the question first.
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.
While typing, the omnibar directly searches on Google and in your web history for the text you typed, may it be a search term, an URL, or content of a page you had visited in the past.
I don't think Chromium has dropped support for kernels <= 3.16. ChromiumOS uses 3.4, 3.8, 3.10, and 3.14 depending on device. All of those are less than 3.16, but as far as I know, ChromiumOS is not going away.
It appears a patch needs to be cherry-picked back; a pretty common task for people that maintain older kernels. It's very common to backport patches to drivers you care about (because new kernel versions always introduce bugs in your obscure hardware, you only backport stuff that doesn't already work). There is even a system for doing it in an automated manner: http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backport...
seccomp ("secure computing") is an application sandboxing mechanism in the Linux kernel (since 2.6.12, 2005-03-08). seccomp allows a process to make a one-way transition into a "secure" state where it cannot make any system calls except exit(), sigreturn(), read() and write() to already-open file descriptors.
It is the seccomp type 2 mechanism, where you choose the system calls and arguments to allow, not the early seccomp type 1 that only allowed exit, read. That one would not really need to sync, as you cannot even create threads afterwards.
it synchronize all the process's threads to use the same seccomp filter (seccomp being a sandbox mechanism - a bit like a firewall for system calls).
Threads on Linux are very close to an equivalent of "separate process" except they share memory. Up to until seccomp tsync, only the thread calling seccomp and it's children would get the seccomp filter.
If you wanted to have seccomp in previously started threads you'd have to handle a broadcast in userspace and ensure all threads actually apply the same seccomp filter.
I bet they ran into issues with that (it's easy to forget a thread or have a new thread someone elses coded that will fail to apply the filter).
tsync is kernel side and explicitly fails/succeeds so its both simpler and safer.
This is not the first time that Chromium team doesn't care about even slightly older distros. Apart from the infamous RHEL 6 case, there is also the recent wheezy case.
Back in September, there was a plan for requiring at least GCC 4.9 for building Chromium, which made building new releases for Debian wheezy in a pure Debian wheezy environment impossible. [0]
Debian lacks the manpower of RedHat for backporting and supporting new software (which is GCC 4.9 for this case), so Stable Release Team and Security Team are not the most liberal teams when it comes to approving new packages into a stable release, and as a result, Chromium is not supported in Wheezy as of last month. [1]
Do you trust package maintainers at Redhat/Debian/etc to properly backport security fixes to ancient branches? They don't exactly have a clean track record.
Look at the terribly old / EOL software in RHEL4 that is on "extended support" until 2017:
edit: I stumbled upon some ELSA advisories a few weeks ago where additional security updates needed to be released for Apache because the CVE for which they intended to backport a fix was not adequately patched.
That is terrifying. There's a reason why upstream doesn't release fixes for those old releases.
The answer seems to be "yes", as Jessie has a 3.16 kernel.
Lots of speculation though - there's no official announcement, as far as I'm aware, and the OP on the mailing list did not identify as a Google employee.
Most people update the kernel when their distro does. Ubuntu 12.04 LTS is currently at a .5 version with kernel 3.13. There seem to be no plans for a 12.04.6 with a newer kernel but we'll see.
Maybe TSYNC can be backported to 3.13 (I'm unsure about who has to do it) or Chromium can be compiled without TSYNC (distro's choice). If nothing happens this is going to cost Google some users but obviously it's their browser and their choice of how to implement it and where it can run.
So, is this a feature that will also appear in Chrome for Android? Is there even an overlap in codebase? [I honestly have no idea]
Given that a lot of handsets run ridiculously old Kernels, I assume that this feature will not be usable for the next few generations of handsets (or will have to be backported, obviously).
It's supremely arrogant to tell your users to change the kernel they are using because you couldn't be bothered to fix a regression in your code. The problem with that approach is self-evident.
I'm not sure I would say its supremely arrogant to tell them to upgrade their kernels. I'm sure if they realized that they were breaking sub 3.16 kernels they would of announced it before hand, but they fudged that. So instead of fixing it to not use a kernel feature they wanted to use, they just said "well this sucks"
Perhaps it is a good things. Many kernel devs aparently don't like the method of back porting fixes for ages the way Debian does. They say the Arch way is fine and one should not be too afraid to upgrade in between. Perhaps Debian could start trying this? In other words, is the Debian stable method still needed in this day and age? Perhaps a good start for a discussion.
Debian has had the "Arch way" before Arch, it's called Unstable :) Personally, I like running that on my laptop and Stable on my server, since I like being able to fix security issues without suddenly having some component replaced or new functionality introduced that breaks the system and requires my intervention. Add unattended-upgrades, and I can essentially leave it running alone for months, if not years.
Google never gave a single fuck about older distros. It took a few days after Debian 7 going stable that they stopped supporting Debian 6 (by requiring newer libc).
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 because there is a reasonable workaround of updating your kernel."