But bashing a person for writing that code? Never. I can't say my views on software politics are aligned with Mr. Stallman's, and neither I can say I have given that much thought to them. But I have enormous respect for everyone who has contributed to free software and helped shape the world, even with the smallest contributions... And Mr. Stallman's are one of the biggest. Everyone in this area should have the deepest respect for the enormous amount of work this man has done, and given it all to the community. It's hard, if not impossible, to stumble upon an anticonformist such as Stallman, who honestly does not care about the superficial things we all, unfortunately, do. I guarantee he could've leveraged everything he's done and been a multi-billionare by now. Instead he decided that the benefit the community can get from his work is far greater than the benefit he himself can get, so he did the only moral thing to do: he gave it all for free. And look at the GNU project now, or the FSF. Magnificent stuff.

Mistakes such as this one (and a great majority of developers make dozens of these on a weekly basis), are probably the most idiotic reason to call out a person for incompetence or senility. It's ridiculous. It's completely unacceptable to now demonize a man such as RMS, if not for other reasons, then because none of us will probably ever come close to what he has done to change this world for the better.

I agree that mistakes happen. But someone who deserves respect, in my opinion, owns up to mistakes and tries to get them fixed.

Someone who downplays the mistakes in order to save face deserves nothing from me.

> Perhaps you're putting too high a premium on your gratitude.

I think it's quite the opposite - people demand that he be respected solely because of what he's contributed to the free software movement, including even the lowliest gratitude from the smallest voices (of which I'm at the bottom of the list).

But what really should happen is that each individual action and contribution should stand on its own, unmarred by its relationship (through its author) to any other action or contribution.

People (the high and the low of us) should respect the free software movement and some of the software it has provided to the world, and simultaneously deride the position that this serious security problem should be shrugged off or downplayed, despite the fact that the same person or people are responsible for both.

In my experience it's the exact opposite. I've been hearing a lot of explanations for the bash debacle in the last couple of days and they all amaze me to a certain degree. Let me share a couple of them with you.

1. Total breakdown - "No software is ever safe, so what the hell do you want from me." Yeah, well ... don't write software then.

2. It's not my fault - "Bash is written in C. C is unsafe." Quite a lot of people write safe, well tested, maybe even formally verified C code. So, yeah ... don't hack in C maybe.

3. Linux is still fine - "Bash is just a tiny part of Linux. The rest is still good to go." Turns out the bash codebase looks a lot like the rest of the GNU/Linux universe. Old, untested C code that's hard to read and even harder to understand. That's why nobody dares to touch it in the first place.

4. It's FOSS - "You can't expect anything to work. Cause, you know, it's free." If that were true, using FOSS would be a terrible idea.

5. You're using it wrong. ... just wow.

Can't we just all agree that this kind of thing is an endemic problem in most of the code bases we use (including my beloved FreeBSD) and we have to figure it out over the next couple of years. There are loads of tools that should have never been implemented in C/C++ in the first place (SSH, Make, APT, etc.). I'd say the best idea is to port a lot of these code bases to languages like Go or Rust maybe, but if that's not feasible for some reason, at least write some unit tests and do static code analysis. And, this is probably the most important point, if you don't want to do any of this, please don't make lame excuses when it all falls apart eventually.

This is the exact problem with everything today. Languages do not make bugs, people do. If that weren't the case, there wouldn't be bugs is python/ruby/shell/etc.

Rewriting something is only guaranteeing that more bugs be created initially. And all the time and effort gets you..what? The same thing that was just patching in a different language. Awesome...

You should be familiar with "bikeshed" being a freebsd user..

Right. That's why it's a good idea to use languages that help people to avoid common mistakes.

> Rewriting something is only guaranteeing that more bugs be created initially.

Neither of us has empirical evidence for that (or maybe you do, I don't know), but let's say your right. A rewrite would at least give us a sane way to move forward (see the first item on my list).

> You should be familiar with "bikeshed" being a freebsd user..

I'm voting blue.

---

Given that you're a Linux user, you should be familiar with Einstein's definition of insanity. :P

lol

> Given that you're a Linux user, you should be familiar with Einstein's definition of insanity. :P

+1 - I just don't see any real solution to the problem. I do think that because Linux is more widely used it is running into the same issues Microsoft has/had where the vulnerabilities are more widely exploitable.

Diversity definitely has it's benefits.

So your answer to to the criticism of "this code is ancient" for core utils is "let's port them to languages that haven't finished maturing yet"? Rust in particular is only two years old, and the recommended version is "the nightly build". That sounds super-stable for core utils...

That said, that Rust looks almost nothing like today's Rust, and you're totally correct about stability.

"Everybody knows" this, but I'm pretty sure this hasn't been true since the 90s.

Today, it's super popular and somehow accepted behavior to bash and make fun of people who buy Apple products. I see it all the time. The excuse always given is that they're simply returning what Apple fans give out, but I can't remember the last time I saw an "Apple fan" bash a PC or Android user.

I don't know when this changed, but I don't like it.

The problem is the same as with openssl's flaws - when we accept all the contributions without detailed code-review we often incorporate code written by over-enthusiastic amateurs (and sometimes even over-confident idiots).

Lots of problem of really open open-source projects (sorry for this tautology) are from the fact that they are open for everyone.

Imagine everyone could commit (without code review) in Haskell compiler tree, Linux kernel or, say, OpenBSD. But in early times of GNU movements this was a very common case.

So, the problem is in the lack of code-reviews, not in GNU movement, let alone Stallman himself.

It is quite easy for ignorant to under-emphasize the importance of GNU tools to what we now call the Internet. It is not just bash, which is very important tool, but in the first place Emacs, GCC, Binutils, GNU make, flex, bison - all the development tools which made possible the raise of early BSD and Linux systems. It is impossible to imagine the world of free, open source software without GNU toolchan.

Nowadays I very much like the example of nginx - it has bigger market share than IIS, while originally was a solo effort, compared to millions of dollars and man-hours which have been spent on development and marketing of IIS. This is how open source model works. Another good example is Erlan/OTP.

The thing is, code review is a necessary thing where the audience is large, the tool is critical, and the tooling (here, the compiler) doesn't give any warranty in term of code correctness.

Code review are important, but it's an human process, which have its own flows and inconsistence. That's no silver bullet, no more than static checking, strong typing, and test suites. If you want to warrant, you'll have to prove. If you want to prove, you'll have to take time and do it mathematically. This process would have killed any OSS project, that's simply not feasible.

Shit happens, man. That's no reason for protectionism, elitism, and OSS aristocracy. OSS is open and should stay open whatever it cost, period.

Moreover, even if this hole is big, environment has always been a real security hole in Unix. ksh, anyone ? Or worst: csh ? The situation has greatly improved since, and we have all rights to be disappointed to lost a security we all took for granted. That shouldn't make us forget the road we already crossed.

The same ideas works with crucial projects such as openssh. No one could count how many eyes was on the code to find a flaw in the code or a way to exploit.

btw, Erlang/OTP is so good, that nowadays when you are using your mobile, your data most probably at least once is going through an Ericsson hardware and an Erlang VM within it.

As for code review, almost every major project does it nowadays, you like it or not.

You want a good OSS project ? Take Gnome, take VLC, take Qt, take the libc^W^W^W, well not the libc. ;-)

You got the idea.

About code review, I persist in my point: it's a good practice, but we need this only because a code that pass the checks (compilation, analysis, tests) doesn't mean that this code works. There was an article about "security by being careful" but I don't find the url anymore. Shame.

Anyway, I'm a Ocaml believer and be assured that when your compiler can give you that level of assurance, you don't review the same: you know you're not half as good as the compiler to catch errors, and that's a damn good feeling.

The point made in the G by an interviewee (not the author) about the Bash codebase and undermining "all bugs are shallow" is actually quite good in the face of two giant counterexamples, and I would have liked to have seen Stallman counter that. He didn't, and instead took another opportunistic shot at proprietary software, just like the FSF's tone-deaf statement.

That weev would get The World vs. Stallman from that, then invest his time into a defense of poor Stallman and shame the world for not giving him money (when his politics and ideals create an economic scenario where he is unlikely to ever receive money from those who benefit most, and ostensibly he accepted this decades ago), is just bananas. I will continue to criticize whatever I like, bash's codebase and GNU process potentially being on the list, and I do not need weev's permission or acceptance to do so.

Maybe if we on HN and in Silicon Valley culture found his racial epithet organization amusing, he wouldn't have to talk about us like a lower class.

I think that if code is bad, it should be pointed out. Some will take it as bashing. Doesn't matter. We all want to run well written, secure software. When you're getting exploited, it doesn't matter if the code was written by a saint.

Shellshock is not a critical failure in bash. It is a critical failure in thousands of people who knew a tool so useful that they decided to deploy it far beyond its scope. A tool so resilient that it it did not fall over when everyone deployed against best practices. Everyone knew in the nineties that when you execute a UNIX command with untrusted input, you clear away the environment variables first. Anyone that has untrusted input embedded within a shell script does not know what they are doing. The fact that there is a way to get bash to execute untrusted code is unsurprising. The thing that surprises me is the sheer number of developers who thought it would be otherwise in complete contrast to UNIX parables and common sense.

FTFA.

CGI was standardised in 1997 to use environment variables to pass information into the CGI program. I'm sure software existed before that that does the same - procmail, perhaps?

No software that's been touched in the past two decades should assume that the environment variable is safe. Especially not a shell, which gets used for all sorts of network-processing-related things.

People pointed out that OpenSSL had a miniscule budget and provided tons of value to the world. Once again, all you can say is mea culpa.

Either that or they should be creating alternatives and moving away from poorly written software.

The point is, when FOSS software has a bug, there's no small set of developers who are responsible. It's, in some small way, collectively all our faults. Like in the case of Bash - apparently for 20 years, we never actually checked if environment variables were executable.

All software gets compromised, all the time. Compromise rate has a lot more to do with the number of users than whether that software is open or proprietary.

I do agree that code should be able to be critiqued, but criticism is generally taken poorly by an individual when your critique is hyperbolic.

Anyone who has the ability to critique it should have spent the time it took to write an outraged blogpost and try to contribute back to the project, it would both make you feel better and look better.

You are absolutely right that contributing (even in a minor way) to OSS is difficult.

However, compared to a few "me too!" comments on your blog, and a few minutes of feeling superior to someone who actually did something, the feeling of actually contributing something real to a project (even of small value) is incomparable.

The author is (IMO, rightly) getting pissed about "technology journalists" at places like Forbes, or bankers at JP Morgan, who will smugly say stuff like, "Oh, there was a really horrible vulnerability in this software, and there's nothing we can do until those incompetent programmers get out a patch" (even if this is not explicitly said, it is often implied in these articles). They completely overlook the fact that

a) The source it right there. You think you can do a better job, please fix it and submit a patch upstream. Or post on the bugtracker.

b) The reason this is a problem is usually because of lack of sanitization of user input before passing it to bash. So that is your problem, not really bash itself. Use one of the patches out there that disable the "feature" that leads to the bug.

How many articles state stuff like "Thousands of organizations over the world use bash, yet no one has discovered this for 22 years. This means a lot of companies are not taking security seriously enough to audit the (open) source of the code they ride on."? Until we start seeing articles that address the complex social and economic aspects of the issue, I don't blame FSF supporters for being pissed at them.

If that's happening, I completely agree with you. I was mostly addressing the "bashing bash" part. Because the bashing of bash is what I've seen in the recent discussion. Not the bashing of RMS.

Is the FSF wrong for issuing a statement which says A major security vulnerability has been discovered in the free software shell GNU Bash. The most serious issues have already been fixed, and a complete fix is well underway?

I think you missed the news that there's a bug in bash.

And if you're making the argument that bash should've not been used in the first place because it's an ice cube or fragile or whatever, then you are with those who make the argument that bash is bad code.

Say that a car manufacturer builds a car for city driving and doesn't warrant or recommend it's use for off roading. However it just so happens that the car is tough enough that it makes a good offroader anyway and soon people start to buy the car for the express purpose of offroading even though the manufacturer does not recommend this use.

Some time later it becomes apparent that there is a weakness in the braking system that manifests itself after extensive offroad use but not with regular road use, and this becomes the cause of many accidents. The manufacturer then does a recall and refits the cars with an improved braking system more suitable for offroading even though they never intended (and still do not) for people to use it offroad they are just forced to accept this use case.

Environment variables are text. So long as you control the name of them, and the name doesn't conflict with any other name in the system, there should be absolutely no issue with putting user input into environment variables.

Programs like bash should only be executing things that are explicitly marked as trusted code through a flag that is not contained in the value. Some distros have implemented a patch to this effect already in bash, disallowing bash from treating any environment variable whose name doesn't start with BASH_FUNC_ as anything but text. This resolves every single related vulnerability out there.

I mean, come on, the issue is screaming at you! This is the same basic mistake of using a bunch of string concatenation to build queries for your database.

Bash is the shell I use to control my system with, it's made for convenience of the user. If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.

That executable variables have to start with. This is a perfect fix, because attackers can never choose the names of environment variables, because we know that that's a poor idea (anyone who does it is already vulnerable to people setting LD_PRELOAD and similar things). This is simply marking certain variables as executable, while everything else is not.

The default assumption, like it or not, is that if you set some random environment variable to some random text, nothing's going to happen. It's been like that since 1993, at the latest.

> If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.

Some things end up managing the system - DHCP, for example. It turns out that the shell is really, really good at managing *nix systems. Everyone can understand it, and everyone can figure out how to manage their system with it. The only real alternative would be perl, which nobody wants to code in, and has a greater learning barrier.

As for modern web frameworks - of course they shouldn't use CGI, although more because there's better/more performant alternatives than for security reasons. However, you find me a medium/large business which has absolutely no legacy code anywhere.

Not at all. The string as a query is expected to execute. Environment variables in general are just data and not expected to be executed, even if some of them have special semantics and may indeed be executed.

It wasn't documented and it wasn't expected. It's not part of the expectations people have for a POSIX shell.

In your metaphor, it's more like the ice cube manufacturer has been making brick-shaped ice cubes and selling them through building suppliers, and they've been widely used as a building material for many years and the ice cube maker has never said anything about the slight risk of it melting at room temperature.

What you're arguing is that bash is not and was never a solid POSIX shell.

I am not saying programmers who make free software leave it out like garbage. I am saying people who use free software for their benefit treat it that way, yet act as though they bought it.

>Until around 1998, my office at MIT was also my residence. I was even registered to vote from there. Nowadays I have a separate residence in Cambridge not far from MIT. However, I am rarely there, since I am nearly always travelling out of town.

https://www.stallman.org/rms-lifestyle.html

In general, there is a lot about RMS that runs contrary to societal norms. He marches to the beat of his own drummer.

He needs to grow up.

[1]: https://www.fsf.org/news/free-software-foundation-statement-...

In times of Github and low-entry barrier participation, GNU sticks to the old ways like a dinosaur - petrifying.

It reminds me a little of vim, as bash, it has a really old code base, old-style function headers (not ANSI C). For Vim it took a github-based fork (neovim) to get a big community on board, establish tests and perform the necessary refactoring. All of this is great, just as the work of the founders of these programs. The criticism is not aimed at the work that was done by the "founders" of these landmark programs, but the stagnation of development and refactoring.

GNU is primarily a political project, not a software project.

If you want software that puts code quality ahead of politics then you should look to one of the BSDs.

That's obviously false. To the contrary, I have serious concerns about the judgement of anyone that thinks an interpreter like bash should parse the contents of every environment variable on startup.

His account of his gay hacking incident is interesting. How could he possibly know it was gay people who flagged his posts ? That's either paranoia, ironic trolling, or homophobia. I thought maybe he was just trolling when he says that gay people flagged him, but after reading the Lisa Simpson post above, I think he might actually believe it.

No intelligent person would do drugs like heroin if they did a little research and understood about neurotransmitter receptor downregulation. Basically, doing any drugs (including alcohol, caffeine or nicotine) will downregulate your neurotransmitter receptors for up to 2 weeks after a single dose (depending on the amount), resulting in the exact OPPOSITE effect of the drugs for up to 2 weeks afterwards. (With chronic use, the downregulation can take years to reverse).

In summary, he is one truly fucked up dude due to the drugs.

However weev is completely correct in telling people that shell environment variables were an obviously bad place for arbitrary data set by people on the internet back in the 90s. The shell wasn't designed for that, it's known to be insecure.

HNs defence of Apache doing silly things seems to be more love of Apache and lack of knowledge of Unix fundamentals than hate of free tools.

It seems as if though foss is so reliable that people start to act entitled when shit hits the fan. Software has never been problem free and never will.

I'm just glad I haven't seen a libreBash or some other lame fork instead of just adding more eyes to the existing functioning project.