GnuTLS certificate verification vulnerability announced (CVE-2014-0092)

A similar thing happened around 20 years ago, with a program called RIPEM. RIPEM was an implementation of S/MIME. It was distributed in source form, and to build it you needed two libraries (well, you probably needed more than two, but only two are relevant for this discussion).

1. You needed a library that implemented RSA cryptographic algorithms. RIPEM used the RSAREF library for this. RSAREF was a library distributed by RSA (the company) that was free to use, but was not free software. I believe that a copy of RSAREF was distributed with RIPEM, although I don't recall for sure.

2. You needed an arbitrary precision integer arithmetic library. No such library was included with RIPEM. You were expected to supply your own (or build RIPEM on a system that included one as part of the system).

The two most common arbitrary precision integer arithmetic libraries on Unix and Unix-like systems at the time were the Berkeley MP library and GNU MP. I'll call these BMP and GMP.

RIPEM could be compiled to work with with BMP or GMP. There were #ifdef statements in the code that selected the appropriate code for the library you wanted to compile for.

RSAREF was not under a GPL compatible license, so if you built a binary of RIPEM linked with GMP, you ended up with a binary that you could not distribute. RIPEM, however, was distributed in source form, not binary form, and did not include GMP in the distribution.

RMS, and someone else from the FSF, objected and told the RIPEM people that they were violating GPL. Their argument was that when you ship source code that uses an interface provided by GMP (even if that is only on option), some people will download GMP in order to build the program, and so your distribution of your source has induced the distribution of GPLed code. That induced distribution, they believe, made your source subject to GPL [1].

What finally happened was that to put an end to this nonsense the RIPEM people wrote a new arbitrary precision integer arithmetic library that had the same interface as GMP but was actually just a wrapper for BMP. That satisfied RMS/FSF, since now there was a non-GPL implementation of the GMP interface, and so now those who downloaded the RIPEM source and built with the "use GMP" option could be linking with either GMP or the new library, so this no longer counted as an induced GMP distribution.

[1] It is actually possible for one party to be liable for the copyright infringement of another party, and so if that infringement involved GPL code, then the first party could be subject to GPL. There are a couple ways this can happen.

One way is called "induced infringement", which happens when a party that is under your control infringes under your direction. This would not apply here because there is not a sufficient control relationship.

The other way is called "contributory infringement", and happens when one party helps another party infringe. This would not apply here because in order for party A to be a contributory infringer to party B's infringement, there has to be a direct infringement by party B. Since it does NOT violate the GPL for me to download GPL code and link it with non-GPL code to produce a binary that I run on my computer (it only becomes a violation if I distribute that binary to others), nothing you do to aid me in this can be contributory infringement.

Same underlying machine model => same mitigation techniques apply as in C.

> surface area of the C++ runtime itself

No RTTI and no exceptions => no runtime. (By "runtime" I mean code necessary to support language features, not the C++ standard library. E.g., without RTTI and exceptions C++ is as suitable for building an OS as C is.)

Still, RTTI and exceptions are table-driven and I'd worry about their integrity if somebody manages to change the RTII and exception tables embedded in the executable. Largely prevented by signing executables. (Oh, the irony :-))

> How do you find auditors for C++ code [..cut]

More than half of the standard text is dedicated to standard library. I've heard it been said (I've not checked myself) that the description of the core language is only slightly longer than that of Java or C#.

But standard size is not that relevant. Reasonable C++ code is easy to write (for an experienced developer), easy to understand, and auditors can always "fail" the code if they don't know what's going on.

Auditing is expensive, so you have a lot of incentives to write reasonable code from the start.

This is a straw-man. A bug in the destructor would lead to resource leaks and to eventual program failure. "Slightly" different from a complete and silent failure to perform a critical security task.

> Bugs happen, in any language.

Another straw-man. Some languages are more conducive to certain types of bugs. See PHP for example.

> You could rewrite it in prolog for all I care, it doesn't address this core issue.

The core issue is bad software engineering. If you look at the code more closely, it doesn't even use a consistent convention for signaling failure. The code looks something like

    if (ret < 0) { ... goto fail; }

The bug wouldn't be there either if they just settled on using the POSIX convention of negative return value meaning failure. But no.., they have to translate it to a pseudo-boolean stored in an int.