There is good engineering and engineering a successful product. Edison was much better at understanding the latter, he also understood and played the patents system. He was in the end by far the better capitalist / businessman, hence he won, financially, and winners write the history books.

Before writing Tesla down as always the great engineer who never got successful, it is worth remembering that he did make a fortune (tens of millions in today's money) from his AC patents before he gave up on the royalties, but he died a pauper because he blew his fortune self-funding research into ideas that were much less good - too confident in his own promised results, he sunk all his money into ideas that just didn't work.

Tried that, I had a great proof of this colonization concept, but this margin was too small to contain it...

For some, the ability to run their own code on a server with high bandwidth outward connection to the internet is all the power they need/want.
If the server is an authorised mail source for a domain (e.g. spf) then so much the better.
If the user has access to some writable disk space that can be used to host some interesting files, then there are uses for that.
If the user can read the web site source or config files that may have value in itself or may lead to further penetration - but I'm sure you've never seen DB user/pw in the source for a production website, ever ?

and qmail procmail exim postfix sshd openVPN some inetds... and all the vectors that haven't been found yet.

The easiest thing to do is to fix bash - using rm if necessary

Is selling the evidence off before the trial (which it was seized to be used in) also par for the course ?
What happens to seized evidence after a not-guilty verdict - or do certain people already know that is not a possibility ?

Nothing was stopping the angels either, per Genesis 6-4 "when the sons of God came in unto the daughters of men" and begat the Nephilim (or were the Nephilim depending on your translation). Enoch appears to make clear they are angels, but Enoch is apocryphal so you may or may not believe it enlightens the story in Genesis. It matters not though, because the story _is_ in Genesis which is canon, and whether the "sons of gods" (or Enoch's Watchers) are angels or aliens, they are clearly not-men but are capable of interbreeding with "daughters-of-men" and producing a race of giants (Nephilim).

As regards opening up a whole new mess, all of this is post-Eden and pre-flood, man can always complain to God: "you said I had dominion over everything so what are these more powerful beings doing taking all the good looking girls" , and God will say "yeah and ? Can I remind you that was back in Eden when I also told you not to eat the ****ing apples ?".

There is a flip side to that, which is that too many cooks with no common management may royally spoil the broth, which is what has happened.

When found, this was embargoed and should have been fixed under embargo, properly. Instead, someone pushed out half-baked patches that were proved to be still vulnerable within hours (if not minutes), and by then everything was public. So now we have everyone and his dog patching in panic mode, three, four or more(?) sets of patches now, with each one still proving vulnerable, because collectively we blew our chance to fix it (and test it) properly the first time.

The eventual fix will have to be to stop playing who-finds-the-parser-bugs-first and accept that the whole feature is a security hole and needs to be removed or radically changed - something that could and should have been predicted at the start. There are various patches flying around now that do just that, probably in different incompatible ways. Those changes will, inevitably, break some stuff - and of course we could have looked and tried to figure out the extent of that, and mitigated the effect and been ready with the announcement, if it were still under embargo, but we blew that chance.

I am all for saying that the open source development model is better - but this really is not the best example to use to illustrate it, in fact it's already heading into embarrassing farce territory.

Problem is that in unix the way is for tools to call other tools, and the shell is so pervasive it could be anywhere. How do you actually _know_ if you are calling bash ?

* If you run /bin/sh are you calling bash ? Should you always check first ? Can you even check ?
* same for calling system() etc.
* If you run any other executable should you always check whether it is a script first ? Can you even check always ?

And this applies all the way down the pipeline, parts of which may be user/admin configurable.

Where in the pipeline ? What if you don't _know_ what the data is supposed to be at this point (only some other tool might do, down the pipeline, how then do you prove it is ok ? What does "no meta characters" mean in the context of an HTTP Cookie, or an email subject line ? - it is meaningless, arbitrary text is valid data in either case.

What we learnt was to properly sanitize and/or quote text that was executed as SQL commands. At the point that we knew it was going into a SQL command. Your web server doesn't know what you are going to use each form field for, "Robert'); DROP TABLE Students" is perfectly valid as a subject for a forum post, but as a user name in a SQL command it needs quoting first. The web server can't quote it, the cgi script or whatever down the line needs to quote it - if and when it gets used in SQL. Now, the web server also does not know and should not need to know what language a cgi script is in, but if it is bash, then bash will execute data as code before the script has chance to verify it.

This generalises to the whole pipeline - any caller may not know what the data it is passing down the pipeline in the environment (or otherwise) actually _means_, or what is valid/non-valid/malicious. Such determination can only be made by the callee that understands the data - but bash may execute it before it gets there.

Let's assume you are right and we can compare with SQL Injection. With SQL Injection we learned we had to properly quote data before feeding it into SQL, and fix all the places we do that. So, with bash injection, now that we know about it, to do the same we would need to sanitize / quote all environment variables whenever we call bash. Except we don't know when that is (see above), so you really mean that every program that execs any other program or feeds into any other program in a pipeline where that program might possibly be a shell script, needs to quote environment variables. That is just about every unix program ever written (and, er, where/when are you going to unquote that data ?).

Or we fix bash, the program that is actually blindly executing data as code.

maybe, "How many hackers does it take to change a light bulb ?"

Would be better if you stopped waiting and started checking.

10secs on google finds lists of shellshock attack vectors including:

qmail, procmail, exim, some inetds, ssh, openvpn, dhclient

That is just some of the ones the good guys have found and advertised so far...

Worth listening to sales, sometimes there is value in what they say, and you need them on side - it isn't fun (or good for job security) writing great software that they can't or won't sell. The suggestion is good as far as it goes but I would say it isn't as simple as that.

Unless you are open source, your dev teams bug trackers should be their area and confidential to them, they may not all be commercially aware customer facing people, they may speak their mind in choice terms about some bug reports, and you shouldn't have to be constantly afraid of that turning up in front of the customer. It isn't just dirty laundry, it's the whole cleaning process and every dirty comment you make whilst doing it.

Then, each customer has their own issues which should be confidential to that customer (and you). Some issues may not be bugs but embarrassing customer mistakes, and customers _will_ (sooner or later) put information into an issue that is commercially confidential, personal information (data protection) or security related. Sometimes this is necessary - bugs may only be tripped by certain data, and it isn't the customers job to determine the general case, it's your job when investigating. Support and dev need to understand that issues are private to a customer, but also sales so they can explain it positively to prospects: "can we look at your issue list ?" "we can't show you customer reported issues because we treat them as confidential to that customer - we believe customers should be able to report exactly what happens which may include their data, rsther than be required to create a general test case". Customer issue lists are not a concern of sales but rather account management - the customer account manager may be in sales, but if so it is a different role they are doing.

Then you (maybe) have general issue list(s) that are visible to all customers - effectively a dynamic tracking view of what will be in the release notes (see below). You need to re-create issues here from the customer reports - not just blindly copy customer report - and really these should be general cases not just what the customer reports. E.g. customer reports issue with Web UI display of account named "P&O", you establish it's an issue with ampersand, and what you report to all customers is that there is an issue with ampersand, otherwise you risk reporting too narrow a bug and exposing customer confidential information. Not every issue will make it to this list, only if it is of general concern, and issue that affects a configuration only used by two customers who have already been informed has no relevance here. I still see little value in this list being public beyond customers, but it should be expected that it might become public at some point (possibly via a customer) and information in it should be written accordingly, at very least it is available to all customers. For these reasons sales may sometimes be involved in decisions as to what goes on this list.

For betas and dev builds etc., maintain separate lists and give access only to those customers who are running those versions, make them feel special, but also your SLAs etc. will be different for non-production versions and this helps keep that clear.

Finally, release notes - fixed issues and known outstanding issues. If you provide public downloadable demos, or you provide demo installs to sales prospects, then these need to come with release notes, so these documents go (at least) beyond your customers. For that reason you don't just dump (any of) the lists above into the release notes, each issue needs to be vetted for inclusion (see above for relevance, plus you want to inform not overwhelm) and rewritten to show your customer service in a positive light - this is effectively part of your shop window.

I would recommend trying to get sales (and maybe marketing) involved in reviewing (and editing) release notes, they are technical documents that need to be customer relevant and readable, sensitive to commercial needs and priorities, and hence need some sales/marketing input.

Yes, really, honestly, and my reasons are:

[stated reason]: This needs your (sales) input because we've written it as a technical document and we may not be aware of all the commercial priorities and sensitivities and may not have used the best customer-facing language, you guys are better than us at this
[real reason]: I want to make sure you sales guys have read the ****ing release notes and aren't out there demoing year-old versions and apologising for bugs we fixed months ago

If they don't want to engage with this, then a) you tried and b) they can't complain about it later...

Check your distro. Believe RedHat at least have newer allegedly more complete patches - although there are also posts saying you'll need a support contract for some older versions of RedHat.

My guess is that initially this was embargoed while GNU/FSF guys "fixed" it, but when we find out fact that the fix was no good everything is already public so now everyone downstream is trying to fix it themselves as fast as possible - RedHat etc. may do their own without waiting for upstream. It's now that you find out how good your support is, from whoever you paid for it or from the guys who work for free if you paid no one.

If you want the diy approach, personally I would look at the initial patch for where the offending code is and rip out the entire "feature", I suspect very few scripts will break.

Alternatively, patch bash using rm.

ssh is also vulnerable (often configured to pass TERM and maybe LC_*)
Git repos using locked-down ssh - vulnerable
dhclient - vulnerable
CUPS - vulnerable

Those are just the ones we know so far.

It is different to heartbleed, and it could indeed get bigger. Heartbleed required zero effort to get the data but then needed some luck and some work to find keys or login info within it. Manual work required before you could break into a system.

ShellShocked on the other hand is direct, trivial, remote code execution. Attacks can easily be fully automated - it is wormable, trivially. The question now is not whether or not fully automated worm attacks will happen or when - they already are - it is how many servers they will get.

And that is all before we start looking at all the embedded Linux out there that may have bash, and often have cgi. It may take longer to find exploit vectors for those, but it will also take longer to patch, and some may not be patchable. Add in to the mix that small business / home routers often also run dhcp servers, and that dhclient is vulnerable, and a router compromise can open up any unpatched client machines inside the firewall.

No one knows how big this _will_ get, but it _could_ be bigger then HeartBleed, easily.