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.

Debian doesn't. Ubuntu doesn't. Anything embedded doesn't. OSX does. There's nothing to "laugh at Linux" for, because even leaving aside the fact, as huge as a house, that this is not a bug of Linux, we must take into account that Bash isn't used on all Linux distributions, is used on many non-Linux unices, and can be installed on non-Unix systems where it'll see environment variables too. I also register with amusement the fact that OSX gets pulled by the coat into the BSD family when it's time to calculate market share, but is carefully set aside now that the distinction is convenient.

I'm correct. Linux has no concept of a "default shell", being an operating system kernel, and its security wrt this bug is the same as FreeBSD or OSX. That is, it's completely orthogonal, contrary to what the post I was responding to was implying.

FreeBSD is vulnerable to this attack as much as Linux, or Windows. It's a bug in an application, not in the OS.