I'm glad that people are learning about this problem. Sadly, it's not new, it's been known for decades. CERT’s “Secure Coding” item MSC09-C (Character Encoding — Use Subset of ASCII for Safety) specifically discusses the vulnerabilities due to filenames. The Common Weakness Enumeration (CWE) includes 3 weaknesses related to filenames (CWE 78, CWE 73, and CWE 116), all of which are in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors. My freely-available book on writing secure software has a whole section about filenames. And so on.

We need to fix the problems with Unix/Linux filenames, not just keep rediscovering them. In particular, ensuring that filenames had no control characters, no leading dashes, and used UTF-8 encoding would simplify developing correct programs. Most people writing software already follow these rules. We don't need to make it easy for attackers.

To be fair, the article itself does state that the 7.1B figure does not represent unique users or handsets in use. Instead, it says that "The number of unique users is now 4.5 Billion or 63% of all humans alive are actually users of mobile phones. The remaining 2.6 Billion accounts are second or third accounts for the same user... So 20% of us, one in five who has a mobile subscription or account, actually walks around with two phones (and at least two accounts)."

Lots of people I know have at least two phones. Heck, I personally have a "work phone" and a "personal phone". My company is a lot less worried about their data mixing with other stuff, especially when combined with additional sandboxing mechanisms like GOOD. It helps me, too. If some organizational data gets out, my employer can erase the phone without me worrying that they'll erase my stuff. Also, I'm a lot freer to install apps than I would be if my company controlled what could be installed on the device that also housed my company's data.

This isn't even unusual. Phones are small and cheap enough to have two. Software-based security mechanisms leak all the time; making things physically separate is far more effective if protecting data actually matters. Not everyone needs to do this, but it's fairly common when data confidentiality really matters.

OpenSSL was actually examined by a lot of tools, but they all missed Heartbleed. My article How to Prevent the next Heartbleed lists approaches that could have found it. We need to improve how we examine this software so problems like this don't happen again.

But that's the point, we can and should take measures to prevent it. Even if we never eliminate all vulnerabilities, we can prevent many more vulnerabilities than we currently do.

Agreed, but not in C. You need to change C (and modify the code to use the functionality) or change programming language. The article does discuss switching languages.

The LLVM static analyzer finds this bug. So would warning about dead code, since the code past the point of the second goto...

Um, no. You're talking about the Apple "goto fail; goto fail;" vulnerability. That's a different vulnerability in a different program. They're both vulnerabilities in TLS/SSL implementations, but they are different programs.

Profiling w/ 100% code coverage would have caught this bug. - No, code coverage would not have worked in this case. Since the problem was that code was missing, you can run every line or branch without triggering the vulnerability. For more, see: http://www.dwheeler.com/essays...

Input fuzzing in the unit tests under memtest could have located this bug even faster. - No, not in this case. Fuzzers were countered because OpenSSL had its own set of memory allocators. When fuzzing you often are looking for crashes; to force buffer over-reads into a crash, the usual way to do that is to override memory allocation. Since OpenSSL managed its memory separately, the override had little useful effect. For more, see: http://www.dwheeler.com/essays...

I'm really glad you're trying to think of alternatives. However, when you say: 1). Initialize all allocated memory. Routinely and automatically.... They did. But the Heartbleed bug let you see currently-active memory. In particular, you have to have the private key available somewhere so you can use it.

Some of the weirdness was due to the spec itself (RFC 6520). I agree that error avoidance is better than parameter-checking, but it's not clear that parameter-checking could have been avoided in this case. But that's certainly worth checking out.

This referenced article is rediculous. First of all, the title says "Downfall of the Roman Empire", but Caesar FOUNDED the Roman Empire, so clearly it did not cause the empire's fall. I suspect they meant the fall of the Roman REPUBLIC, which preceded the empire. But it's still garbage. What most emperors wanted was power, not concrete buildings. The article doesn't even begin to make a connection between the two. If you want more about the history of the (Western) Roman republic and empire, listen to AWESOME "The History of Rome" podcast: http://thehistoryofrome.typepa... It's fantastic.

There's no "app" for screenshots because it's built into Android itself, and has been since 4.0 (which was released many years ago). It's volume down + power button. Just Google for "Android screenshot".

This makes no sense. If you want to search for code, the obvious way to do it today is use Google or some other search engine. Tomorrow, the obvious way to do it... will be to use Google or some other search engine. You don't need a "federated search", you just need a good search engine. There are a number of code-specific search engines that already work today too, again, there's no need for one system to rule them all.

I think there's great advantage in having an OSS management system for managing OSS projects.

One big improvement would be to make organ donation the *default* when obtaining a driver's license in the US. That way, people could opt out, but most people just "accept the default"... and then far more organs would be available to save the living.

I've had better luck with Chromebooks. Cloud printers are now very common, and in many cases buying a new printer costs little and is a big improvement anyway. For a list of printers that can work this way, see: http://www.google.com/cloudpri... I hate trackpads anyway, and I've had excellent success with normal mice on a Chromebook. Apple components often don't like working with non-Apple components, that may be the problem there. And all built-in laptop speakers are bad; if it matters, get speakers, they're cheap.