This has to be the biggest piece of Apple adulation that I've ever seen. A practice of flattery over everything Apple do is always superabundant in most of the output of the American tech press: we're used, for instance, to the reviewers' pirouettes when they first dismiss some bad choice by Apple as irrelevant, and then they have to praise the reversal of that choice as the best thing after sliced bread in some later version of an Apple product.

But in this case, well, Apple does something wrong (not even remotely comparable to the trainwreck that Microsoft did with Metro, I'll concede) that devalues the largest part of its already expensive product line, with the exception of the most expensive products, and without adding any value to those either, but Apple fan are happy nonetheless because... it's good to be shown how Apple does not care about who doesn't spend the most?

What is this, an exercise of asceticism in the path of the true Apple worship?

A dev announced that extFS support had been removed in beta. To people protesting, they replied that the feature was going away full stop. They even modified the ChromeOS feature page stating that ChromeOS had ext support.

Because of FUD. Stating that supporting the ext file system poses a security issue is FUD: it is FUD by definition, and it is FUD in particular because ext is massively used in security-critical contexts including Google's servers and Google's Android operating system. Why, ext4's key developer is a Google employee IIRC!

Because they didn't want to implement the few lines of code supposed to invoke the already existing facilities that set the file system label. A thing that, for tricky that it may be, was done right by the Commodore 64's 1541 floppy drive OS, by MS-DOS, by all versions of Windows, by all Linux-based desktops, by AmigaDOS, by OSX, and probably most existing operating system.

After the slashdot story was published, after my comment was written, when more and more people started stating, most of them politely, that removing ext support would make ChromeOS unsuitable for their work, and that they were upset because there was no credible explanation for the removal of the feature, only after that developers stopped ignoring their discontent and decided to leave ext support in for the time being, but still without writing the code required to alter the filesystem label.

And when did I say otherwise? I even said the same thing in another comment.

Open Source != GPLv3. People can write all the code that they like but unless Google want to, their chances of actually seeing that code running on Chromebooks is zero. In this case, Google have already decided that the feature (which is already there) has to go, because simplicity.

Buy a real laptop if you want to do whatever you want with it. If you buy (?) a locked-down device, which is controlled by a remote commercial entity and not by you, then don't act surprised when they don't support some use case of yours which doesn't help them make money.

DRM in HTML will “break the internet” too, and you pushed for it. Surveillance sucks whether the data is gathered by a hostile government or by a friendly commercial entity.

Even if this is true, and no I haven't checked it, it has no relevance over the reality of how many people are effectively using Bash together with the Linux kernel, which is a matter of which distributions people effectively use. I do aknowledge that RedHat-derived distributions are probably more common on servers, but I'm just guessing that out of prejudice.

If you really had a server of any kind which spawned a *real user login shell* as a result of a remote client request of any kind, then you would already have a huge security problem. Moreover, I expect lots of people will use Bash as their persoanl shell even on BSDs as it's so much better than Tcsh.

Then they are as broken on FreeBSD (or any other OS) as well as they are on Linux distributions that haven't Bash as the system shell.

How so? The bug is triggered when you start a buggy Bash shell having a malicious environment variable set up by the parent. Having Bash itself as a parent isn't a problem, because the bug is triggered when the environment is parsed at Bash's startup time (the shell might even crash afterwards).

The karma bonus is there as a measure to let *you* moderate your own comments. If you consider 2,000 characters of condescendension as something that is worth promoting, good for you, but don't expect other readers to share your conviction.

Now you just have to find some server package which allows an unnprivileged remote client to trigger the execution of a Zimbra init script.

The funny thing is that, should you find it, such package would be vulnerable on FreeBSD in the exactly same way as it were on Linux, nullifying the argument that you are trying to make, about the Bash bug being a "Linux bug" that FreeBSD users shouldn't worry about.

Look at the comments of every slashdot story about some BSD, when the topic of market share comes out.

I won't post links to individual comments here, because I would find it both rude and pedantic.

It depends on wether /bin/sh points to bash on OSX.

Not to mention the fact that if people are connecting their machines to rogue DHCP servers, they're compromised anyway.

It's not that the typical Linux distribution opens telnet to the world by default, either.

In the meantime I've told you how many Linux-based systems don't use bash as their default shell. The reality being opposite to your arbitrary statement that "the vast majority" of them do.

You should. Its purpose is to override other people's posts when you have something important to say.

Plonk.

Did he laugh about Debian/kFreeBSD? Did he laugh about OSX? Did he laugh about Cygwin or SUA? No, but he laughed about a minority subset of Linux distributions, and called them "Linux", having an uninformed reader believe that the bug is in Linux (it isn't) or that all Linux distributions are affected (many aren't). He was so aware of this fact, that he posted anonymously.

Which is not to say that this bug isn't serious, because it's huge. It's to say that this is not a "Linux bug", in any possible meaning of the phrase, strict or lax.

Certainly not in a distribution which does not have bash as the system shell. You can uninstall bash in such a distribution, and the system is expected to continue running.

ls -l /bin/sh , that's what your scripts are going to use. It should be dash.

You fail to appreciate the difference between Linux and Bash (there's Linux with no Bash, there's Bash with no Linux). You fail to appreciate the fact that no, the most popular Linux distributions don't ship with Bash as the default shell. And yet you invest almost two thousand letters, and the Karma Bonus, doing the condescendent and attacking me personally. If you were trying to appear funny, in my opinion, you aren't. If you were trying to appear smart, then you had better get your facts right before attempting to.