Are you aware of any analysis as to the extent that is actually true, ie for distro X or Y which patches really have been backported and which are skipped?

Yes. For most CVEs, the major distributions do backport fixes. They don't however backport all security fixes.

For example, there was a bug in crypt's bcrypt implementation which would cause collisions for certain classes of passwords (specifically those with characters with high bits set). The fix in 5.3.6 was to add a check into the normal $2a$ implementation, and to add $2x$ (legacy) and $2y$ (proper implementation). So when using > 5.3.6, you can enforce proper behavior using $2y prefix to crypt. CentOS backported this into their 5.3.3 version. Debian did not. So from a security standpoint, we now how a divergence between the two.

I wonder how much your "% of installs that are secure" statistic could be inaccurate due to most (I'd hope) sites that care even slightly about security suppressing the Apache header PHP version information.

Absolutely. The analysis is only as good as its data source. There are other people looking at other data sources (httparchive for one) to try to get more data for it. But ultimately I had to go with what I had.

I suppose there are also questions as to what "insecure" means in practice.

Well, perhaps insecure is an extremely misleading term in this context. Vulnerable would be better. Yes, an attack vector may not exist, but the vulnerability does. The reason this is important is that today you may not be using unserialize() on user input, but that doesn't say you won't tomorrow. The hole will exist, the vector would be what's created.

Check out my slight elaboration on this in this comment

The 5.3 branch is end-of-life. Meaning that the latest release (5.3.29) has known vulnerabilities that weren't fixed. Therefore, it's not secure.

5.3.10 is listed as secure by the post because that version is supported by Ubuntu 12.04...

There's a difference between a vulnerability and an attack vector. Even if it's not exploitable, the vulnerability still exists.

However, I would like to make a point. How many of these installs made a conscious decision by investigating the security fixes and balancing that against their codebase to see if it's exploitable or not? I'd wager that the number is so small as to not even register.

Besides, I think a variant of Schneier's law applies:

"any person can invent a security system so clever that she or he can't think of how to break it."

The same thing applies to vulnerabilities: If you can't think of a way to exploit it, that doesn't mean it isn't exploitable.

So yes, it is an over-statement. But it's also showing quite clearly how updates are being dealt with. And that was the precise point of the original post. If it gets people to think about upgrading more, then awesome. If not, nothing lost.

I mean, come on: 82.27% of perl installs are secure? 77.59% of python installs? Get real.

No. 82.27% of all PERL installs have no known vulnerabilities in PERL itself.

This isn't to say the code on top is secure. And it isn't saying that it's exploitable. Just whether known vulnerabilities in the platform itself exist.

The point most people make when you talk about running old versions is that "well, distributions backport security fixes, so 5.3.3 is secure on distro XYZ".

So, to get around that, I looked at the popular distro's versions that they maintain. Then I counted *all* of those point versions as secure (over counting). So 5.3.3 is insecure as distributed by php.net, but as installed by Debian 6 it is secure.

So therefore to get an upper bound (rather than lower bound) on secure versions, you need some way of factoring in for distro support.

So I picked the most popular distros for server usage. Is this hand-waving? Absolutely. But it should give a pretty reasonable upper-bound.

Ummm... No. WordPress was first written in PHP3. Before it was even called "register globals". Back when that was just how you did things.

Thank you for the kind words :-)

Definitely not true:

110

That has 2 1s, which is prime (2 is prime), but 6 definitely is NOT prime...

Likewise,

1001

That has 2 1s, which is prime, but 9 definitely is NOT prime...

Have you actually read the bill? Because I find it REALLY hard to believe that anyone who actually has would say that it does anything about the health care problems the USA has. It's not a health care bill. It's a health insurance bill. One which does nothing to solve the existing problems that health care has (abuse, ridiculous spiraling costs, ridiculous GOVERNMENT regulations - aka Medicare's rules, etc). Not to mention fraud or malpractice abuse (false malpractice cases, which drive up costs significantly)...

Does that make it useless? No, absolutely not. But it does nothing for the healthcare problems that we face. All it does is put a band-aid on a gunshot wound. A band-aid that costs how many billion dollars per year (that we're already over-budget by)?

Actually, this touches on an interesting point.

Everyone thinks that high turnover is a bad sign. And it is. But very few people think of what extremely low turnover means.

If a company has 40% turnover each year, that's a sign that something's wrong in the organization. There's a reason that people are leaving so quickly. If the average tenure is only 14 months, that's not a good sign. But on the flip side, it could be that same 40% that keeps turning over. Imagine that they have a small team, and are trying to grow it. High turnover in the growth area could mean that they just haven't found the right fit. (in this case, the average tenure could be 3 or 4 years, even though the turnover appears so high). That could indicate the quality of applicants, or that their interviewing process sucks. So turnover by itself is hard to understand. But turnover with average tenure tells a more complete picture.

Now, if turnover is under 1%, that could also be a scary sign. It could indicate that employees are never growing. That they are stagnating in their position and can't move on because their skills have gone rusty. That could also be a huge negative.

I personally look for moderate turnover. Somewhere between 5% and 20%. Signs that there's some new blood in the team, keeping complacency in check. It also may indicate that people are actually growing in their positions. Which is an awesome thing to look for.

So turnover by itself is a useless metric. It may indicate towards a good or bad thing. But the more important factor is not what the turnover is, but why it is what it is. Unfortunately, that's not something that's usually going to be easy to understand in an interview. But luckily, it should be pretty clear in the first few weeks of employment...

Yes

Basically, it used one valvebody with two separate chambers (one for each system). However, the main valve cover covered both chambers. So when the cover's seal blew, both were compromised. Granted, it's an edge case. But it did happen to me...

The only common points of failure are the pedal assembly (designed fail-safe, by the way) and the master cylinder

And the ABS valve body assembly. Which I had go on my catastrophically on a 1994 Chevy Blazer. In that has, the only brakes I did have was the parking brake cable assembly.

The more complicated vehicles become, the more failure modes are possible...

This. Very much this.

This article is pure FUD. Plain and simple.

Malware, by its very definition is:

Malware is a general term used to describe any kind of software or code specifically designed to exploit a computer, or the data it contains, without consent.

Android requires that you give consent, since it tells you what permissions the application needs prior to installing it. So by very definition, these data leakages on Android are not malware. The user said it was ok for that application to collect that data.

Exactly. It's called a Power Law.

Actually, that's my definition of a good team player. That's one reason we work as a team (to spot each other's mistakes, and help prevent them in the final product). Have you ever heard of Pair Programming?