[eatfish]

That is true, but I don't think this invalidates my central point that the rational response to heartbleed is to update your contigency plans. The irrational response is to plan the perfect world.

After 20 years of Java we still don't have our perfect VM. It still sees critical security vulnerabilities. I don't think I'm picking on Java unfairly here. Java is a well written code base, it has plenty of unit tests, a proper code review process, a sound architecture. Pretty much all of these have been put forward as ideas that would 'cure' the OpenSSL project. Yet it doesn't seem to be a perfect cure. At some point no matter what your language, VM, OS is you are going to experience something similar.

[lmm]

> After 20 years of Java we still don't have our perfect VM. It still sees critical security vulnerabilities.

Sure, but how many, and how often? The last advisory for Java's SSL I can find is from 2009, and that was quite a limited flaw (allowed an attacker to inject a prefix into SSL data). Indeed the kind of exposure we see with heartbleed - leaking all of the process's memory including the private key - is more or less impossible by design. At this point maybe using Java for your internet-facing service might do more to improve your security than shaving a day off your response time.

[eatfish]

Sorry, I'm not limiting the discussion to SSL vulnerabilities.

A remote code exploit is as bad as a memory leak.

I posted these two: CVE-2013-1493 and CVE-2013-0809 in another reply. These 2 were memorable to me just because visiting a page (or a compromised page) would allow the exploit to proceed without any password/prompt/warning.

[lmm]

CVE-2013-1493 is more an argument for java - the vulnerability exists because that part of the standard library is implemented as native code rather than in java itself.

[MaxBarraclough]

As others have pointed out above (https://news.ycombinator.com/item?id=7572092), the 'perfect JVM' is missing the point. The JVM aims to provide two things:

1: A high-level development environment which allows well-intentioned developers to avoid, say, buffer-overflow bugs

2: A sandbox, in which untrusted code can be safely run

Java has a truly awful track-record on point 2 (running untrusted applets by default? awful idea), but a much better one on point 1, which is what's actually relevant here.

> At some point no matter what your language, VM, OS is you are going to experience something similar.

No. If all/nearly all of your OS is written in a safe language, it's going to be much safer from, say, buffer-overflow attacks. Unfortunately there aren't any such languages in major production use, so it's hard to point to concrete numbers.

[MaxBarraclough]

s/languages/OSs/