
 Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping - Morgawr
http://arstechnica.com/security/2014/03/critical-crypto-bug-leaves-linux-hundreds-of-apps-open-to-eavesdropping/
======
tptacek
The vulnerability means that there is an ASN.1 certificate format you can use
that will validate against any unpatched GnuTLS-using application, regardless
of how you configure ciphersuites and negotiation. The bug isn't
cryptographic. It's much simpler and more basic than that. My guess is that
it's also been embedded in GnuTLS for longer than the SecureTransport bug had
been.

For connoisseurs of bogus conspiracy theories, it's worth noting that the
coding flaw that produced the bug is much more subtle than "goto fail", but
the bug is equally simplistic. Where "goto fail" required a duplicate line,
GnuTLS required only a single switched token; not only that, but the bug comes
from a mismatch between two common C error checking regimes (a zero-return
error and a negative-return error).

I think what I like least about the bug is that it was found by the GnuTLS
maintainer, long after the code shipped. That's a signal of how much attention
GnuTLS gets.

~~~
SimHacker
This is yet another nail in the coffin of Eric Raymond's irresponsible and
fallacious "many eyes make all bugs shallow" theory.

[https://en.wikipedia.org/wiki/Linus's_Law](https://en.wikipedia.org/wiki/Linus's_Law)

Linus's Law as described by Raymond is a claim about software development,
named in honor of Linus Torvalds and formulated by Raymond in his essay and
book "The Cathedral and the Bazaar" (1999). The law states that "given enough
eyeballs, all bugs are shallow"; or more formally: "Given a large enough beta-
tester and co-developer base, almost every problem will be characterized
quickly and the fix will be obvious to someone." Presenting the code to
multiple developers with the purpose of reaching consensus about its
acceptance is a simple form of software reviewing. Researchers and
practitioners have repeatedly shown the effectiveness of various types of
reviewing process in finding bugs and security issues, and also that reviews
may be more efficient than testing.

In Facts and Fallacies about Software Engineering, Robert Glass refers to the
law as a "mantra" of the open source movement, but calls it a fallacy due to
the lack of supporting evidence and because research has indicated that the
rate at which additional bugs are uncovered does not scale linearly with the
number of reviewers; rather, there is a small maximum number of useful
reviewers, between two and four, and additional reviewers above this number
uncover bugs at a much lower rate. While closed-source practitioners also
promote stringent, independent code analysis during a software project's
development, they focus on in-depth review by a few and not primarily the
number of "eyeballs".

~~~
ori_b
To quote Theo De Raadt:

    
    
        My favorite part of the "many eyes" argument is how few bugs 
        were found by the two eyes of Eric (the originator of the 
        statement).  All the many eyes are apparently attached to a 
        lot of hands that type lots of words about many eyes, and 
        never actually audit code.

~~~
Crito
What a pointless and content-less rebuttal.

I mean shit, I don't need to be an aeronautical engineer or work in the FAA to
say that several people investigating an airliner crash will be more effective
than one single dude sifting through a literal field of debris.

ESR's quote _isn 't_ wrong (perhaps hyperbolic, but in spirit it isn't wrong).
It's just an uninteresting observation. What do you do when something has you
stumped at work? You ask the guy across the hall to look over your shoulder
for a second... It's just common sense.

People simultaneously revere and hate the quote only because ESR said it. If
Joe Shmoe had said it all those years ago, it would have just been met with
"no shit" and never given second thought.

~~~
smsm42
I think there's a point here. The point being much more people talk about many
eyes than actually audit existing code. The fact is, there are quite a number
of bugs that stayed in the code for a long time despite being not that deep.
Maybe that says we don't have enough eyeballs, but most of people quoting that
sentence quietly assume we do, equating number of participants in FOSS
communities with number of people actually auditing the code. Unfortunately,
the former is much bigger than the latter. We pretty much have the same
situation as we have in science publications where a lot of results are not
reproducible and a lot nobody even bothers to check for reproducibility,
despite reproducibility being the basic tenet of open publication and peer
review and being necessary to validate the result. Unless there's a reason to
- e.g. an identifiable bug - not many bother to go back to existing code and
check it for correctness.

~~~
Crito
The quote is hyperbolic for the "all", and should probably use the word
"shallow _er_ ", but otherwise I don't see anything wrong with it.

 _" much more people talk about many eyes than actually audit existing code"_
is true of free software, but is also true of just about everything. More
people think _" I feel comfortable crossing this bridge because plenty of
engineers have looked at it"_ than there are engineers actually looking at
bridges. I haven't read the quote in it's original context for several years,
but I don't remember it conflating software users with software developers.

~~~
Perseids
The difference is that engineers actually know how to build safe bridges. I
feel (and am actually) safe living in a house designed by a single competent
architect, but I am not secure using a TLS implementation written by a single
competent programmer. The only way we have found to end up with reasonable
secure code is to have it reviewed by a _lot_ of competent people.

------
afhsfsfdsss88
Can we all finally accept the fact that what is most needed now is not a new
whizbang but a comprehensive review of all of the core pieces of software that
we depend on as a base for making new whizbangs?

How many critical and ancient bugs still remain undiscovered?

Everyday there is a new Telegram, Cryptocat, etc. all presumably being
constructed on top of insecure libraries. What progress can we make with such
shaky foundations?

There has been word that the Linux kernel devs are considering slowing new
feature adoption for a time while focusing on bug discovery and elimination.

PLEASE, EVERYONE ELSE CONSIDER DOING THE SAME.

~~~
newman314
At a minimum, commonly used security packages should be reviewed and OS
distribution maintainers commit to updating to latest versions of said
packages regardless of the age of the OS.

For example, Ubuntu 12.04 LTS uses an older version of OpenSSH and OpenSSL.
There should be no reason why Ubuntu (and others) can't commit to updating to
the latest versions so that features in say OpenSSH 6.5p1 are avail. BTW,
saying that you can compile and install this yourself is noted beforehand but
honestly, how many people do that on a regular basis?

What I'm getting at is that security software can and should be held to a
higher and current standard precisely because it affects so many other pieces
of software in fundamental ways. It's not a big deal if the latest version of
bc is not installed but it sure is if GnuTLS or OpenSSL is broken.

------
acc00
Commit introducing the bug:

[https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d...](https://www.gitorious.org/gnutls/gnutls/commit/0fba2d908da6d0df821991ea5fdbeeda0f4ff089)

~~~
acqq
Commit: #0fba2d9

"Improved the certificate generation stuff."

~~~
snarfy
On one hand this makes me wary of the quality of GnuTLS source in general, and
on the other I know I am guilty of similar commit messages.

------
JshWright
Disclaimer: My understanding of the goto fail bug is based on agl's writeup,
and my understanding of the GnuTLS bug is limited to this article.

In both of these cases, it seems the code starts with the assumption that the
cert is valid and then tries to find various conditions to invalidate it.
Isn't that backwards? Why not start with an assumption that the cert is
untrusted until you've proven otherwise?

~~~
guscost
This is an interesting question. I agree that invalid-by-default makes sense
when reasoning about the higher-level system, but regarding the actual Boolean
logic it seems that if a critical condition is broken the particular
formulation will not make much of a difference.

Additionally, it seems that in certain situations having several plain-if
conditionals set the valid state to `1` would be _less_ robust than having
several conditionals set it to `0`. In the first case if any one of the
conditions have bugs the false valid state can happen, whereas in the second
case the last conditional to execute would have to contain the bug.

Can anyone else comment on this? Are there relevant theories and/or best
practices which have been discussed in the security community?

~~~
JshWright
What about several conditionals that set various elements of a struct to 1,
and the cert is valid iff all elements are 1. At least that way a skipped
check (i.e. goto fail;) wouldn't result in a false positive...

~~~
guscost
So basically abstract the details of each sub-condition from the final check
that all sub-conditions are met?

That does sound like a good idea as long as the meaning of `1` and `0` do not
get confused, and as long as we're not talking about some niche context where
extra overhead for the sake of code maintainability would be a problem.

------
Geee
Is it that they just now started actually testing these implementations, for
the first time? Even if you wouldn't follow TDD practices, it's obvious that
anything that implements a protocol of some sort (particularly a security
protocol), should be tested to actually follow that protocol. Isn't that
common sense? What is going on?

~~~
tptacek
TLS stacks aren't built with TDD practices for the same reason that the kernel
TCP/IP stack isn't built with TDD: the things that go wrong in TLS involve the
state machines of a distributed protocol and somewhat elaborate mathematical
operations.

Read Schneier and Ferguson describing in _Cryptographic Engineering_ the steps
required to validate a bignum arithmetic library. That's one of the smaller
problems in getting a TLS stack right, and it's complicated.

If you demand that your browser implement protocols the same way ActiveRecord
implements SQL join generation, you should just stop using browsers; _none_ of
them are built the way you'd want them to be.

I have a hard time not being dismissive about TDD's role in improving systems
software security. If you're going to propose a radical change in the way
systems code is written (or, worse, hold systems developers to a nonexistent
standard), be intellectually coherent about it: demand that security-critical
code be implemented in a rigorous language, like idiomatic Haskell. Don't
propose monumental changes that promise only that the resulting code will be
asymptotically secure as Ruby on Rails.

~~~
jsmthrowaway
That's not what he said at all and your comment dips into "the elite few know
more than you do" territory, particularly with the unnecessary dig at Web
development. His only mention of TDD was "even if you don't," yet you jumped
on the acronym TDD and took him to task for it.

What I read him as saying (and agree with) is that he's surprised that GnuTLS
isn't tested against known-bad certificates in a simple integration test that
doesn't require a Ph.D. to set up, as you imply.

~~~
cube13
>What I read him as saying (and agree with) is that he's surprised that GnuTLS
isn't tested against known-bad certificates in a simple integration test that
doesn't require a Ph.D. to set up, as you imply.

Define "known-bad" in a general enough way that a specific test can be created
to cover the entire range of "bad" certs. That's quite difficult, and,
probably isn't realistically possible to go through all the "known-bad" if you
want your tests to run quickly.

Realistically, all you can do is have regression tests to make sure that the
found bugs aren't repeated in future releases.

~~~
jsmthrowaway
My thoughts on this are more about the previous TLS disclosure, not this one,
where an integration test that says "this invalid certificate should fail
validation" probably would have caught it. But, this isn't my argument to make
as I don't know enough about it, I just want to see the actual coherent
argument made instead of a side tangent as we're seeing here.

~~~
tptacek
What integration test? Writing that integration test implies that you know the
bug is a possibility. Once you consider that possibility, a glance at the code
tells you if it's there or not. It's not like this bug is likely to regress,
either.

~~~
jsmthrowaway
Again, I'm talking about the "goto fail" one, not this one, in which a simple
test of the library against an invalid certificate would have caught at least
one case that I recall. And I think it's pretty obvious that "you might
erroneously validate a bad certificate" is a bug that's, you know, a given.

~~~
tptacek

        Feature: *Certificate Validation*
          In order to *keep NSA from reading my emai*
          As a *TLS X.509 validation library*
          I want *to never erroneously validate a certificate*
    

What are the "Scenarios"?

    
    
          Given: *???*
          And: *???*
          When: *???*
          Then: *the certificate should be rejected*
    

Remember, if we're switching topics to the "goto fail" bug: that bug didn't
affect every instance of certificate validation. You had to be in a particular
set of ciphersuites.

~~~
jsmthrowaway
I spent a few minutes replying to your original comment, then you ninja edited
in the closing paragraph and invalidated mine, so this is where I end the
conversation. I can't reply to an ever-shifting comment with someone who reads
what they want to read out of my comments and invokes the NSA for no reason
whatsoever.

~~~
tptacek
You'd be a happier person if you didn't assume people were editing their
comments just to make you look bad. You can be assured that if I had seen you
respond to something I'd written, I'd have noted where I added to my original
comment.

But I agree that you & I are better off not discussing things.

~~~
jsmthrowaway
I'm quite a happy person and thanks for the irrelevant concern trolling, based
on a comment thread that's calling you out (do you always assume people that
think you're wrong are unhappy or otherwise defective?). And no, I didn't
assume those words you've placed in my fingers. I was, rather, annoyed that I
invested a few minutes into a playing field that you'd already moved while I
worked.

If you'd permit me a brief bit of my own concern trolling: I remember when I
looked forward to reading your comments, several years ago. Now I see your
nickname and say "bah, again?" What changed? Was it me or you?

------
kenferry
Patch fixing the bug:

[https://www.gitorious.org/gnutls/gnutls/commit/855127da290a2...](https://www.gitorious.org/gnutls/gnutls/commit/855127da290a280df839038671ae6aba01957736)

Basically, the code said

    
    
        bool isOk() {
            result = someCheckReturningNegativeOnFailure()
            if (result < 0) goto cleanup;
    
            cleanup:
                ...
                return result; 
        }
    

The issue is that failure is communicated with a negative number in one case
and 0 in another, and the wires got crossed.

~~~
QSIITurbo
Yeah. While they're at it, why not change every function to return "int". Then
just cast to proper type at usage. /s (And no, bool is not the proper way to
go either.)

But seriously, I'm amazed that code this critical uses sloppy typing. I mean,
they might as well use Python ffs. Maybe it's historical burden?

------
stonogo
This is not a bug that leaves "linux" open to anything. It's a GnuTLS bug, and
you should be using openssl anyway.

~~~
michh
Why should I be using OpenSSL other than this bug?

~~~
stonogo
GnuTLS exists as a project almost exclusively due to ideology concerns --
people who prefer GPL do not like OpenSSL's license. That's not to say that
technically-capable people are not behind it, but there are not as many as
involved with OpenSSL. There are very few technical advantages to GnuTLS, and
almost all of them have been transient (as in, certain protocols and ciphers
have been supported in GnuTLS before other libraries). I do not have the time
to go over _why_ other libraries occasionally lag behind GnuTLS, but I can
specify, for instance, that OpenSSL code goes through a more thorough and
lengthy review process before it gets 'shipped' (inasmuch as that term applies
to not-for-profit software).

Code that supports GnuTLS can easily be made to support OpenSSL (or several
other such libraries). It really is a matter of which license you prefer, and
licensing should never be a consideration in security.

------
zabcik
Archlinux pushed the upgrade just 9 hours after the bug was fixed. Damn I love
this OS.

~~~
keithpeter

        root@teacup:/home/keith# apt-get upgrade
        The following packages will be upgraded:
          libgnutls26
    

Not quite 9 hours but fairly quick on gNewSense 3 as well, no doubt pushed
through from Debian Squeeze.

------
bbanyc
So which projects actually use GnuTLS as opposed to OpenSSL (Apache, lighttpd,
nginx) or NSS (Firefox, Chrome)? I'm aware of Debian linking some packages
against GnuTLS to avoid the supposed GPL incompatibility issue with OpenSSL,
but the only thing I've seen that explicitly uses GnuTLS is Emacs 24.

~~~
aroch
Apache can (and maybe should) use gnuTLS

~~~
josh-wrale
Please expound on why you believe Apache 'maybe should' use gnuTLS.

~~~
aroch
Back when I still used Apache it didn't have support for TLS 1.1/1.2 due to
the dep on OpenSSL and thus none of the better FS ciphers. So compiling
against gnuTLS allowed for those. That's now been rectified.

------
flurpitude
Coming so soon after the Apple bug, it does make one wonder whether some or
all of these are deliberate backdoors. Relevant musings by Bruce Schneier:

[https://www.schneier.com/blog/archives/2014/02/was_the_ios_s...](https://www.schneier.com/blog/archives/2014/02/was_the_ios_ssl.html)

~~~
rmc
Or the attention is now on "does your SSL cert handlying code have any
shortcuts? Let's everyone double and triple check"

------
josteink
Just checked my Ubuntu boxes. Update has been pushed and is ready to apt-get.

~~~
shavenwarthog2
Yes. For others:

1) consider installing the "unattended-upgrades" tool, to install security
updates via cron.
[https://help.ubuntu.com/community/AutomaticSecurityUpdates](https://help.ubuntu.com/community/AutomaticSecurityUpdates)

2) specific Ubuntu Security Notice on GnuTLS:
[http://www.ubuntu.com/usn/usn-2121-1/](http://www.ubuntu.com/usn/usn-2121-1/)

3) List specific package affected:

dpkg-query -W libgnutls*

libgnutls-openssl27:amd64 2.12.23-1ubuntu4 libgnutls26:amd64 2.12.23-1ubuntu4

I'm on Linux Mint, and the above seem to show that I'm protected. Yay!

~~~
wreegab
For Saucy, the fix is in:

.../ubuntu/+source/gnutls26/2.12.23-1ubuntu4.2

Yours is:

.../ubuntu/+source/gnutls26/2.12.23-1ubuntu4

See:

[https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-1ubunt...](https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-1ubuntu4.2">https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-1ubuntu4.2)

------
rdl
SSL fuzzing seems like it could be a really profitable area of research. I
wonder why there aren't better conformance testing tools for SSL (other than
SSL being kind of hideously baroque).

------
computer
Are all programs dynamically linked with GnuTLS, or are there packages that
have to be recompiled separately? (On Debian/Arch)

~~~
jvreeland
I can't speak for absolutely every package but most if not all on Arch will be
dynamically linked and shouldn't need to be recompiled. (The new version was
released on Arch 3/3)

------
pera
Linux? afaik I don't use any program that requires GnuTLS...

~~~
nandhp
Are you sure? At least on Debian, GnuTLS is used by CUPS, exim4, cURL/GnuTLS,
GnomeVFS, Gtk, NetworkManager, libvncclient, libvncserver, VLC, and wget.

~~~
scott_karana
Git and _bloody GnuPG_ are also on that list.

~~~
pera
Oh.. well, it seems that Debian uses GnuTLS instead of OpenSSL, I was not
aware of that.

In Arch Linux very few packages depends on GnuTlS.

------
ufmace
Does this make anyone else's conspiracy antenna twitch a bit? The Apple one
was only a little suspicious in that way. A bug in another major crypto
library that weakens it in a very similar way makes it look a little more
suspicious. Since this is OSS, the investigation of the source control logs
will probably be a bit more public. I wonder if they'll find anything
interesting.

------
vezzy-fnord
Makes me wonder how long this may have been used as a 0-day.

------
droprip
I am not very familiar with low level C or the coding patterns used with it,
so I must ask; why do we see goto statements in both of these recent bugs? As
far as I know it's a bad practice overall, is there some specific reason for
using it here?

~~~
EddSeabrook
C doesn't have exceptions, so goto is commonly used to emulate that style of
programming.

~~~
thrownaway2424
It's not just that, it also doesn't have automatic destruction of objects, so
any local array or structure containing a pointer needs to be laboriously
freed by hand.

And in other words, nobody should be writing anything in C. Ever. The need to
be compatible with programs written in C violates my rule against writing
anything in C and is therefore not a valid reason to write crypto stacks in C.

~~~
deletes
You realize that most lower things are written in or base on C, right.

~~~
thrownaway2424
Yes I am fully aware of the sad state of our industry.

~~~
codygman
I'm curious, what do you propose the industry use?

~~~
ForHackernews
Isn't Go designed to fill this niche? It's supposed to be a low-level systems
language, but with "friendlier" features than C, and built-in concurrency
support.

~~~
pktgen
Go is advertised as a systems language but certain things like the lack of
manual memory management say otherwise.

~~~
wbl
Before there was C, there was Pascal. You didn't have malloc in Pascal. At ETH
Zurich the standard OS was written in Oberon: it ran directly on the hardware
with a garbage collector collecting everything.

------
ybaumes
Since 2005? 10 years long in production? And while the code is open, no-one
ever seen the bug? Is that the power of open source??

------
murftown
How many apps really use GnuTLS anyways? Apache doesn't by default. SSH
doesn't. Are most RedHat installations therefore not really affected?

------
arunc
That's a good hype for GnuTLS, but most of the packages that I know of uses
OpenSSL - Apache, Nginx and so on. So it doesn't really matter.

------
laumars
As someone who uses tends to compile most things against openssl, I was
wondering if someone could answer how widespread gnutls usage is?

------
elwell
But I thought open-source is immune to slip-ups like this?

/s

------
mattjaynes
Does anyone know if this affects any of the popular configuration management
tools like Puppet, Chef, SaltStack, etc?

~~~
vacri
If you're on a Debian derivative, you can find out which _installed_ packages
depend on an item with "aptitude why [foo]"

------
albertop
So I wonder where are all commenters blasting Apple for careless coding.
Crypto is brittle.

------
0xdeadbeefbabe
What's with the back button ARS? Helping me stay off hn?

------
joelthelion
Is there a tool to check if you're affected?

------
balls187
Windows is bound to be next.

#it_comes_in_threes

------
thrownaway2424
Demand unit tests and comments. I mean, I was incensed by the quality of the
Apple code, but this code is just as bad:

    
    
      * Checks if the issuer of a certificate is a
      * Certificate Authority, or if the certificate is the same
      * as the issuer (and therefore it doesn't need to be a CA).
      *
      * Returns true or false, if the issuer is a CA,
      * or not.
      */
      static int
      check_if_ca (gnutls_x509_crt_t cert, gnutls_x509_crt_t issuer,
                 unsigned int flags)
      {
    

Sure, returns "true" or "false" which are not things in C. This actually
returns either 0 or 1. Many C library functions return 0 for OK and non-zero
for error. This one returns 0 for error and 1 for OK.

Imagine you are reviewing the a call site of this code:

    
    
      if (check_if_ca(...)) { 
        // CA is valid, proceed
      }
    

vs.

    
    
      if (check_if_ca(...) == 0) {
        // CA is valid, proceed
      }
    

To the reviewer who is accustomed to strcmp, either of these might appear to
be fine, meaning that the reviewer (or even the author) has to carefully check
the documentation of this function.

What else is wrong with this signature? For one thing it would be easy to swap
the arguments around:

    
    
      if (check_if_ca(cert, issuer, flags)) ...
      if (check_if_ca(issuer, cert, flags)) ...
    

What's the difference? They both look reasonable. What are the valid/relevant
values of |flags|?

Would it be easier to comprehend |flags| if it were an options struct, e.g.

    
    
      GNUTLSCertificateVerificationOptions opts;
      opts.set_allow_rsa_md2(true);
      ...
      cert.Verify(opts);
    

?

Would it be easier to verify the correctness of a call site of check_if_ca if
it looked like this:

    
    
      if (issuer_cert.IsCA() || cert == issuer_cert) ...
    

Where are the unit tests. The unit tests should be right here in the lib
directory as whatever_unittest.c, adjacent to the source file they are
testing, so you don't have to go groping around in the tree trying to find the
relevant test, if it even exists. By the way, I found no test that calls this
function.

Basically this code has all the same problems as the Apple code, except for
the mixed tabs/spaces stuff (as far as I can tell). It would be shameful for
any professional programmer or organization of programmers to create this
code.

~~~
epsylon
> Sure, returns "true" or "false" which are not things in C

#include <stdbool.h>

Available since C99.

~~~
dTal
It's a strange thing, but C99 features seem very slow to catch on in the C
community, particularly features conceived specifically to alleviate bad
"C-isms". The only explanations I can think of are ignorance (not really an
excuse after well over a decade) or possibly a subconscious fear that they
somehow make a program "less portable", even though basically every compiler
supports it (and besides, I've never noticed any aversion to trivial features
like //-style comments).

[EDIT - maybe pride in the bad C-isms?]

~~~
spiralpolitik
This mostly due to slow support from the compiler people. 10 years after
neither `clang` or `gcc` provide a complete C99 implementation [1].

[1] [http://en.wikipedia.org/wiki/C99](http://en.wikipedia.org/wiki/C99)

~~~
sltkr
I think that's a bit dishonest -- the standard is almost entirely supported by
GCC:

[http://gcc.gnu.org/c99status.html](http://gcc.gnu.org/c99status.html)

> C99 is substantially completely supported as of GCC 4.5 (with -std=c99
> -pedantic-errors used), modulo bugs, extended identifiers (supported except
> for corner cases when -fextended-identifiers is used), and floating-point
> issues (mainly but not entirely relating to optional C99 features from
> Annexes F and G).

... and also by clang:

[http://clang.llvm.org/docs/UsersManual.html#c](http://clang.llvm.org/docs/UsersManual.html#c)

> The support for standard C in clang is feature-complete except for the C99
> floating-point pragmas.

Compiler/library support for C++ is much less complete(standards were
published in 1998, 2003 and 2011, and none are completely implemented in any
compiler) but that clearly didn't stop people from using C++. The reason is
that the commonly supported subset was useful enough. The same is true of C99.

I think it was mostly Microsoft that was holding C99 adoption back by refusing
to support it in their compiler suite (officially, they support C++ and
C89/C90 only). That means you can't generally compile C99 code with the
Microsoft C/C++ compiler, which meant you had to avoid either that compiler or
(if you care about portability) the C99 standard. I don't think limited C99
support in GCC or Clang was a limiting factor to anyone in the past decade.

~~~
helmut_hed
_Compiler /library support for C++ is much less complete(standards were
published in 1998, 2003 and 2011, and none are completely implemented in any
compiler)_

Clang begs to differ on that point
[http://clang.llvm.org/cxx_status.html](http://clang.llvm.org/cxx_status.html)

and gcc claims to implement "all of the major features" so you may be right on
that one
[http://gcc.gnu.org/gcc-4.8/cxx0x_status.html](http://gcc.gnu.org/gcc-4.8/cxx0x_status.html)

At any rate C++11 features are quite well supported IMO. Even VC++ is catching
up.

~~~
sltkr
> Clang begs to differ on that point
> [http://clang.llvm.org/cxx_status.html](http://clang.llvm.org/cxx_status.html)

Impressive! I see that exported templates got scrapped in the latest standard
-- they probably never supported that.

In any case, my point wasn't that Clang was bad (I think Clang is very good)
but that the few limitations that might exist in Clang or GCC are probably not
holding back C99 adoption.

~~~
mitchty
I'll just note, that after coming back to C after a while in ruby/python/ungh,
perl land everything in C99 and C11 has been a welcome change.

Seeing lack of adoption to things like just stdbool.h or even C99 initializer
syntax is somewhat amusing. I understand backwards compatibility and all but
there seems a general unwillingness to abandon C89 which I can only think is
due to the microsoft toolchain.

As to c++ support clang has been really spearheading the implementation of new
c++ standards and last I recall they even found bugs or inconsistencies. It
always pays to have at least one implementation before standardizing I think.

------
benihana
So I guess the whole meme of "if the code was open to scrutiny, this bug
wouldn't have happened" doesn't seem to be so valid now. There was legitimate
outrage on Hacker News that Apple could allow such a bug, and that it was an
indicator of the evil of closed source systems.

------
greatsuccess
After Apple and now GNU, henceforth no SSL distribution should be accepted at
face value without proof of continuous automated testing results. Period. This
is a scandal now.

------
hoers
Is there a list somewhere of which applications use GnuTLS?

------
bananas
Thou who reimplements code is doomed to reimplement bugs as well.

------
hiphopyo
Choose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most
secure Unix-like OS. Creator of the world's most used SSH implementation
OpenSSH, the world's most elegant firewall PF, and the world's most elegant
mail server OpenSMTPD. OpenBSD -- the cleanest kernel, the cleanest userland
and the cleanest configuration syntax.

~~~
gonzo
unfortunately, it is as performant as a pig in winter mud.

