14 ms·

GnuTLS considered harmful (2008)

185 points by calpaterson 13y ago

agwa 13y ago
The annoying thing about GnuTLS is that it normally might not be very widely used, except that the Debian project initiated a huge push to make software linkable with GnuTLS instead of OpenSSL, because of issues with the OpenSSL license[1]. So if you're a Debian or Ubuntu user, you're probably relying on GnuTLS a lot more than users of any other distribution, or people who compile the upstream sources themselves. (Not that OpenSSL is a panacea, but at least it gets more attention than GnuTLS). [1] The OpenSSL license is incompatible with the GPL, making it technically illegal to distribute binaries of GPL programs linked with OpenSSL (so Debian refuses to do so), unless the GPL program has an OpenSSL license exception.
- Xylakant 13y ago
  The problems of linking GPL-code with OpenSSL was one of the reasons why ruby is dual-licenced today afaik.
  - Argorak 13y ago
    Among others. Ruby was GPL/Ruby-licensed and is now licensed BSD/Ruby, which makes shipping OpenSSL easier.
- nly 13y ago
  Some critical (to me) dependency chains on my system (Arch, KDE) seems to be Networkmanager → libsoup → glib-networking → GnuTLS Eclipse → WebkitGTK → libsoup ... VLC → FFmpeg → GnuTLS kdelibs (core KDE libs) → upower → libimobiledevice → GnuTLS I have a feeling there are greater dependencies within GNOME distros and, as you said, Debian. Networkmanager is an especially annoying one because it uses NSS directly and gnuTLS indirectly.
  - dfc 13y ago
    If any Debian user is curious they can use the following commands to see gnutls dependents: $ apt-cache rdepends libgnutls27 libgnutls26 libcurl3-gnutls $ apt-cache --installed rdepends libgnutls27 libgnutls26 libcurl3-gnutls The latter invocation only displays packages which are installed locally, the former prints all packages apt is aware of.
- alexforster 13y ago
  I don't understand why NSS[1] isn't more highly regarded. It's the crypto library that both Chrome and Firefox use, and it has a comparatively good security record[2]. [1] https://developer.mozilla.org/en-US/docs/NSS https://developer.mozilla.org/en-US/docs/NSS [2] http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nss http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nss
  - nly 13y ago
    It's regarded enough to be used by Java, Flash, Networkmanager, and Libreoffice... API is very low level though when all you want is a secure socket.
    - timclassic 13y ago
      Exactly.
  - hyc_symas 13y ago
    NSS was designed for use in single-user browsers and the API is completely unsuitable for more general, multi-user system-wide deployment. https://wiki.mozilla.org/NSS_Library_Init https://wiki.mozilla.org/NSS_Library_Init RedHat has misguidedly chosen to base all of its security infrastructure on NSS, even though NSS was never designed for such a use. It is completely inappropriate for servers, multi-user workstations, etc.
    - blahbl4hblahtoo 13y ago
      Having a system wide certificate store is a good idea, though...
  - cpeterso 13y ago
    Chrome is dropping NSS for OpenSSL: https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1 https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53...
- belorn 13y ago
  While some usage comparison between GnuTLS and OpenSSL is good, it is important to remember that each project support different features. For example, OpenSSL do not support OpenPGP.
- benihana 13y ago
  The irony of what's happening here, that dogmatism about a belief is causing an inferior solution to be used, is infuriating and one of the reasons people have such a problem with dogmatic personalities like rms. It's technically illegal to use a better solution because of something as relatively unimportant as a license. Think of it like a Maslov's hierarchy - having strong security is way more important to most people than having a proper copyleft license. But instead of being pragmatic, we're stuck with a ridiculously dogmatic solution that ends up harming way more than the ill it was trying to cure. It reminds me a lot of environmentalists going crazy to ban nuclear power in the 70s before we had as clear a grasp on the impact of dumping carbon dioxide into the air.
  - chimeracoder 13y ago
    > The irony of what's happening here, that dogmatism about a belief is causing an inferior solution to be used, is infuriating and one of the reasons people have such a problem with dogmatic personalities like rms. It's technically illegal to use a better solution because of something as relatively unimportant as a license. Why do you jump to blame the GPL and rms, when one could just as easily fault the OpenSSL authors for using the 4-clause BSD instead of the far more common 3-clause? > It's technically illegal to use a better solution because of something as relatively unimportant as a license. No, it is technically illegal to distribute compiled binaries that use OpenSSL, because the OpenSSL authors wanted to retain the advertising privileges. But it is not illegal to use the software as long as it is distributed in source and compiled by the end user. I would not call licensing unimportant. As long as software is copyrightable, licensing terms are highly important.
    - pierrebai 13y ago
      The reason the GPL is annoying is that free license with an advertizing clause have existed for a very long time and are actually widely used. A quick look at the about box of various software will usually show you a long list of mandatory acknowledgements for various open source licenses. The problem is that the GPL willingly refuses to permit advertizing clauses. Is there a congent argument about why an advertizing clause is a limitation of freedom? The GPL is more often than other free licenses putting restirctions on usage of diversely licensed software. It is an impediment. And, as we see, it has real-world consequences. There is more risk for freedom using bad software security than wielding to innocuous clauses.
- dbbolton 13y ago
  Actually, I don't think that's generally true if you're talking about the libs. A cursory glance at the output of `apt-cache rdepends libgnutls26` suggests that wget is the only relatively "popular" package depending on it. However, some other distros such as Arch do not have wget depending on it, so you do have a point about Debian.
euank 13y ago
It's a shame this is being upvoted so highly when it's factually incorrect. A rebuttal can be found here: http://nmav.gnutls.org/2011/05/is-really-gnutls-considered-harmful.html http://nmav.gnutls.org/2011/05/is-really-gnutls-considered-h... It's rather silly that the news of a critical bug in GnuTLS that was caused by a goto somehow makes non-news and factually wrong information from 5 years ago popular.
- Xylakant 13y ago
  If you dive into the exchange following http://www.openldap.org/lists/openldap-devel/200802/msg00100.html http://www.openldap.org/lists/openldap-devel/200802/msg00100... you'll see that the criticism does not only allude to the liberal use of strcat() and strcopy() but has more fundamental problems about the general quality and efficiency of the code. While I do agree that digging up a 5 year old rant with a catchy tagline does not tell us everything about the projects current state, the rebuttal also misses some of the points brought up in the initial criticism
- mikeash 13y ago
  That rebuttal doesn't address the more important claim that the library uses NUL-terminated strings for potentially arbitrary binary data. Not that this affects your point, but the critical bug was not caused by a goto. Rather, it was caused by a mismatch in return value semantics, where a variable was used to store a value where 0 meant success, and then later used to return a value where non-zero meant success.
- simias 13y ago
  It addresses the use of the libc str* functions but not the first point about the prototype of set_subject_alt_name. It's also discussed later in the thread: http://www.openldap.org/lists/openldap-devel/200802/msg00100.html http://www.openldap.org/lists/openldap-devel/200802/msg00100... > You note that there's really a small number of instances of strcat() in the code. That's true, but that's because you've provided your own _gnutls_str_cat() function instead, which is also heavily used. Assuming that strlen() isn't going to SEGV on you (which depends on dumb luck) this becomes just a question of efficiency. I also think that in the rebuttal the example is extremely poorly chosen since the code is equivalent to the much simpler char str[256] = "PKIX1.CRLDistributionPoints.?1.distributionPoint.fullName"; Assuming you even need str to be 256 char long, otherwise you would use 'char str[] = "...";' or 'const char *str = ' if you don't modify the string. Maybe the use of the concatenation is legitimate in the real code but I cannot judge that since it appears to have changed since the article was written: https://gitorious.org/gnutls/gnutls/source/d9ce82a4ce690857f828e6c434718c2a85bfbab0:lib/x509/extensions.c#L1041 https://gitorious.org/gnutls/gnutls/source/d9ce82a4ce690857f... No strcat in there. Maybe it wasn't such a good idea after all? :) EDIT: Actually, I dug into the git repo to find the old code and looked to revert to a commit around the date the blog post was written. Obviously I don't intend to get any work done this afternoon. I found this commit on the same day (2011/05/10): https://gitorious.org/gnutls/gnutls/commit/3df051196838f4f43f2350c637bb3fae3001ddaf https://gitorious.org/gnutls/gnutls/commit/3df051196838f4f43... "eliminated last instances of strcpy() and strcat() to keep pendantics happy." So the reason he says the problem is not here anymore is because he fixed it just before writing this blog post, more than 3 years after the openldap rant. I'm sure nmav was well-intentioned but it does weaken his rebuttal somewhat.
Xylakant 13y ago
Money quote from the message thread: "I can't even find the words to express how gross this is." (http://www.openldap.org/lists/openldap-devel/200802/msg00100.html http://www.openldap.org/lists/openldap-devel/200802/msg00100...) Interestingly, the conversation stays somewhat civil even after that quote, looks like professionals at work :)
- grannyg00se 13y ago
  Probably helps that the message containing that quote also contained a handful of significant examples of poor coding choices along with suggestions for improvement.
- ajross 13y ago
  The quote seems to simply be complaining about the repeated use of the subexpression "strlen(str)", by implication because it's needless and inefficient. Except that it's not. At least on glibc, strlen() is declared "pure" to the compiler and (unless otherwise defeated by pointer aliasing) repeated calls will be optimized away. That's not to say that this is the best way to write the code, but the concern seems poorly informed.
  - steveklabnik 13y ago
    It's not an efficiency concern, it's a security concern.
    - ajross 13y ago
      Common subexpression elimination isn't normally considered a security technique, so I guess I don't understand your point. Maybe you're saying it's a "code smell" kind of thing and that being sloppy here indicates more subtle problems elsewhere? Which then hits the argument about whether this is really "sloppy" or just intentionally simple. Shrug. My point was just that this needs better evidence. There is no demonstrated bug in the linked code, and the assertion that it is "gross" (OP) or "insecure" (you) seems poorly justified.
ape4 13y ago
Fixing the strlen()s is easy but the binary stuff is harder. Assuming it hasn't already been done.
- hyc_symas 13y ago
  If you're focusing on the strlen() you're missing the forest for the trees. The problem is someone who knew nothing about security or good programming practices decided to write a security library and somehow convinced the community at large to trust his code. Everyone's a beginner at some point but no sane person trusts their system security to code written by someone so demonstrably incompetent, and no honest beginner would attempt such an undertaking and then advertise it as production-ready or secure. The fact that there are still certificate validation bugs in GnuTLS today indicates that the GnuTLS developers still haven't learned the essentials of X.509 certificates. Even with a rapidly deployed fix for this most recent CVE, you'd be a fool to rely on GnuTLS for anything. The code and the developers have proven themselves not to be trustworthy. Multiple times.
lispm 13y ago
No matter how you look at it, C is the wrong choice for security relevant systems software. But where is the alternative?
- mox1 13y ago
  Java obviously, there are no security issues with java... No wait! Ruby, that should be perfect, can't cause buffer overflow there.... Ermm.. wait I got , well use python!
  - lispm 13y ago
    What do you think the Java runtime is written in? The Ruby runtime? The Python runtime? Hint: it starts with a C. If you build a house in a swamp, you are in trouble.
    - mox1 13y ago
      I was making a joke.... If C is the wrong choice, what is the right choice?
      - jmz92 13y ago
        In a couple years or so, my bet would be on Rust.
    - diminoten 13y ago
      > The Python runtime? Why, Python, of course![0] [0] - http://pypy.org/ http://pypy.org/ (I jest, your point is entirely valid)
    - aryastark 13y ago
      Wow, you're daft. Everything is, ultimately, getting turned into machine code. Not even Lisp Machines could get away from this fundamental fact: http://funcall.blogspot.com/2009/04/some-lisp-machine-minutia.html http://funcall.blogspot.com/2009/04/some-lisp-machine-minuti... > Bogus objects — properly tagged words with invalid addresses that pointed at uninitialized memory or into the middle of object of a different type — which would cause the GC to corrupt memory would be left in registers or on the stack. These sort of problems were everywhere in the microcode. Go build your cabin in the woods now.
pg_is_a_butt 13y ago
GnuEverything is harmful. bunch of morons making shit code for shit people. shave your beard, hippy. you STINK.
AceJohnny2 13y ago
Any updates to this 6-year old post? I would hope that, with systems like Debian forcing a move to GnuTLS from OpenSSL (for licensing reasons), it would have since received more care.
blueskin_ 13y ago
I really don't see the Point of GnuTLS. Sure, if you want to directly integrate OpenSSL with GPL code, you can't, but as it's a library, you should be using it normally anyway. OpenSSL is far more widely used, has a longer history, and I would say is better tested and understood.
hyc_symas 13y ago
For the morbidly curious, ITS#5361 which triggered the above email: http://www.openldap.org/its/index.cgi/Incoming?id=5361 http://www.openldap.org/its/index.cgi/Incoming?id=5361
- hyc_symas 13y ago
  Other gems - ITS#5991 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5991 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=599... which required us to hack up a workaround. It also triggered ITS #5992 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5992 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=599... Discussion of the GnuTLS bug is summarized here https://www.debian-administration.org/users/dkg/weblog/42 https://www.debian-administration.org/users/dkg/weblog/42 And people still wonder that GnuTLS certificate verification bugs continue to surface?

185 points by calpaterson 13y ago

agwa 13y ago

The annoying thing about GnuTLS is that it normally might not be very widely used, except that the Debian project initiated a huge push to make software linkable with GnuTLS instead of OpenSSL, because of issues with the OpenSSL license[1]. So if you're a Debian or Ubuntu user, you're probably relying on GnuTLS a lot more than users of any other distribution, or people who compile the upstream sources themselves. (Not that OpenSSL is a panacea, but at least it gets more attention than GnuTLS). [1] The OpenSSL license is incompatible with the GPL, making it technically illegal to distribute binaries of GPL programs linked with OpenSSL (so Debian refuses to do so), unless the GPL program has an OpenSSL license exception.

Xylakant 13y ago
The problems of linking GPL-code with OpenSSL was one of the reasons why ruby is dual-licenced today afaik.
- Argorak 13y ago
  Among others. Ruby was GPL/Ruby-licensed and is now licensed BSD/Ruby, which makes shipping OpenSSL easier.
nly 13y ago
Some critical (to me) dependency chains on my system (Arch, KDE) seems to be Networkmanager → libsoup → glib-networking → GnuTLS Eclipse → WebkitGTK → libsoup ... VLC → FFmpeg → GnuTLS kdelibs (core KDE libs) → upower → libimobiledevice → GnuTLS I have a feeling there are greater dependencies within GNOME distros and, as you said, Debian. Networkmanager is an especially annoying one because it uses NSS directly and gnuTLS indirectly.
- dfc 13y ago
  If any Debian user is curious they can use the following commands to see gnutls dependents: $ apt-cache rdepends libgnutls27 libgnutls26 libcurl3-gnutls $ apt-cache --installed rdepends libgnutls27 libgnutls26 libcurl3-gnutls The latter invocation only displays packages which are installed locally, the former prints all packages apt is aware of.
alexforster 13y ago
I don't understand why NSS[1] isn't more highly regarded. It's the crypto library that both Chrome and Firefox use, and it has a comparatively good security record[2]. [1] https://developer.mozilla.org/en-US/docs/NSS https://developer.mozilla.org/en-US/docs/NSS [2] http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nss http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nss
- nly 13y ago
  It's regarded enough to be used by Java, Flash, Networkmanager, and Libreoffice... API is very low level though when all you want is a secure socket.
  - timclassic 13y ago
    Exactly.
- hyc_symas 13y ago
  NSS was designed for use in single-user browsers and the API is completely unsuitable for more general, multi-user system-wide deployment. https://wiki.mozilla.org/NSS_Library_Init https://wiki.mozilla.org/NSS_Library_Init RedHat has misguidedly chosen to base all of its security infrastructure on NSS, even though NSS was never designed for such a use. It is completely inappropriate for servers, multi-user workstations, etc.
  - blahbl4hblahtoo 13y ago
    Having a system wide certificate store is a good idea, though...
- cpeterso 13y ago
  Chrome is dropping NSS for OpenSSL: https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1 https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53...
belorn 13y ago
While some usage comparison between GnuTLS and OpenSSL is good, it is important to remember that each project support different features. For example, OpenSSL do not support OpenPGP.
benihana 13y ago
The irony of what's happening here, that dogmatism about a belief is causing an inferior solution to be used, is infuriating and one of the reasons people have such a problem with dogmatic personalities like rms. It's technically illegal to use a better solution because of something as relatively unimportant as a license. Think of it like a Maslov's hierarchy - having strong security is way more important to most people than having a proper copyleft license. But instead of being pragmatic, we're stuck with a ridiculously dogmatic solution that ends up harming way more than the ill it was trying to cure. It reminds me a lot of environmentalists going crazy to ban nuclear power in the 70s before we had as clear a grasp on the impact of dumping carbon dioxide into the air.
- chimeracoder 13y ago
  > The irony of what's happening here, that dogmatism about a belief is causing an inferior solution to be used, is infuriating and one of the reasons people have such a problem with dogmatic personalities like rms. It's technically illegal to use a better solution because of something as relatively unimportant as a license. Why do you jump to blame the GPL and rms, when one could just as easily fault the OpenSSL authors for using the 4-clause BSD instead of the far more common 3-clause? > It's technically illegal to use a better solution because of something as relatively unimportant as a license. No, it is technically illegal to distribute compiled binaries that use OpenSSL, because the OpenSSL authors wanted to retain the advertising privileges. But it is not illegal to use the software as long as it is distributed in source and compiled by the end user. I would not call licensing unimportant. As long as software is copyrightable, licensing terms are highly important.
  - pierrebai 13y ago
    The reason the GPL is annoying is that free license with an advertizing clause have existed for a very long time and are actually widely used. A quick look at the about box of various software will usually show you a long list of mandatory acknowledgements for various open source licenses. The problem is that the GPL willingly refuses to permit advertizing clauses. Is there a congent argument about why an advertizing clause is a limitation of freedom? The GPL is more often than other free licenses putting restirctions on usage of diversely licensed software. It is an impediment. And, as we see, it has real-world consequences. There is more risk for freedom using bad software security than wielding to innocuous clauses.
dbbolton 13y ago
Actually, I don't think that's generally true if you're talking about the libs. A cursory glance at the output of `apt-cache rdepends libgnutls26` suggests that wget is the only relatively "popular" package depending on it. However, some other distros such as Arch do not have wget depending on it, so you do have a point about Debian.

euank 13y ago

It's a shame this is being upvoted so highly when it's factually incorrect. A rebuttal can be found here: http://nmav.gnutls.org/2011/05/is-really-gnutls-considered-harmful.html http://nmav.gnutls.org/2011/05/is-really-gnutls-considered-h... It's rather silly that the news of a critical bug in GnuTLS that was caused by a goto somehow makes non-news and factually wrong information from 5 years ago popular.

Xylakant 13y ago
If you dive into the exchange following http://www.openldap.org/lists/openldap-devel/200802/msg00100.html http://www.openldap.org/lists/openldap-devel/200802/msg00100... you'll see that the criticism does not only allude to the liberal use of strcat() and strcopy() but has more fundamental problems about the general quality and efficiency of the code. While I do agree that digging up a 5 year old rant with a catchy tagline does not tell us everything about the projects current state, the rebuttal also misses some of the points brought up in the initial criticism
mikeash 13y ago
That rebuttal doesn't address the more important claim that the library uses NUL-terminated strings for potentially arbitrary binary data. Not that this affects your point, but the critical bug was not caused by a goto. Rather, it was caused by a mismatch in return value semantics, where a variable was used to store a value where 0 meant success, and then later used to return a value where non-zero meant success.
simias 13y ago
It addresses the use of the libc str* functions but not the first point about the prototype of set_subject_alt_name. It's also discussed later in the thread: http://www.openldap.org/lists/openldap-devel/200802/msg00100.html http://www.openldap.org/lists/openldap-devel/200802/msg00100... > You note that there's really a small number of instances of strcat() in the code. That's true, but that's because you've provided your own _gnutls_str_cat() function instead, which is also heavily used. Assuming that strlen() isn't going to SEGV on you (which depends on dumb luck) this becomes just a question of efficiency. I also think that in the rebuttal the example is extremely poorly chosen since the code is equivalent to the much simpler char str[256] = "PKIX1.CRLDistributionPoints.?1.distributionPoint.fullName"; Assuming you even need str to be 256 char long, otherwise you would use 'char str[] = "...";' or 'const char *str = ' if you don't modify the string. Maybe the use of the concatenation is legitimate in the real code but I cannot judge that since it appears to have changed since the article was written: https://gitorious.org/gnutls/gnutls/source/d9ce82a4ce690857f828e6c434718c2a85bfbab0:lib/x509/extensions.c#L1041 https://gitorious.org/gnutls/gnutls/source/d9ce82a4ce690857f... No strcat in there. Maybe it wasn't such a good idea after all? :) EDIT: Actually, I dug into the git repo to find the old code and looked to revert to a commit around the date the blog post was written. Obviously I don't intend to get any work done this afternoon. I found this commit on the same day (2011/05/10): https://gitorious.org/gnutls/gnutls/commit/3df051196838f4f43f2350c637bb3fae3001ddaf https://gitorious.org/gnutls/gnutls/commit/3df051196838f4f43... "eliminated last instances of strcpy() and strcat() to keep pendantics happy." So the reason he says the problem is not here anymore is because he fixed it just before writing this blog post, more than 3 years after the openldap rant. I'm sure nmav was well-intentioned but it does weaken his rebuttal somewhat.

Xylakant 13y ago

Money quote from the message thread: "I can't even find the words to express how gross this is." (http://www.openldap.org/lists/openldap-devel/200802/msg00100.html http://www.openldap.org/lists/openldap-devel/200802/msg00100...) Interestingly, the conversation stays somewhat civil even after that quote, looks like professionals at work :)

grannyg00se 13y ago
Probably helps that the message containing that quote also contained a handful of significant examples of poor coding choices along with suggestions for improvement.
ajross 13y ago
The quote seems to simply be complaining about the repeated use of the subexpression "strlen(str)", by implication because it's needless and inefficient. Except that it's not. At least on glibc, strlen() is declared "pure" to the compiler and (unless otherwise defeated by pointer aliasing) repeated calls will be optimized away. That's not to say that this is the best way to write the code, but the concern seems poorly informed.
- steveklabnik 13y ago
  It's not an efficiency concern, it's a security concern.
  - ajross 13y ago
    Common subexpression elimination isn't normally considered a security technique, so I guess I don't understand your point. Maybe you're saying it's a "code smell" kind of thing and that being sloppy here indicates more subtle problems elsewhere? Which then hits the argument about whether this is really "sloppy" or just intentionally simple. Shrug. My point was just that this needs better evidence. There is no demonstrated bug in the linked code, and the assertion that it is "gross" (OP) or "insecure" (you) seems poorly justified.

ape4 13y ago

Fixing the strlen()s is easy but the binary stuff is harder. Assuming it hasn't already been done.

hyc_symas 13y ago
If you're focusing on the strlen() you're missing the forest for the trees. The problem is someone who knew nothing about security or good programming practices decided to write a security library and somehow convinced the community at large to trust his code. Everyone's a beginner at some point but no sane person trusts their system security to code written by someone so demonstrably incompetent, and no honest beginner would attempt such an undertaking and then advertise it as production-ready or secure. The fact that there are still certificate validation bugs in GnuTLS today indicates that the GnuTLS developers still haven't learned the essentials of X.509 certificates. Even with a rapidly deployed fix for this most recent CVE, you'd be a fool to rely on GnuTLS for anything. The code and the developers have proven themselves not to be trustworthy. Multiple times.

lispm 13y ago

No matter how you look at it, C is the wrong choice for security relevant systems software. But where is the alternative?

mox1 13y ago
Java obviously, there are no security issues with java... No wait! Ruby, that should be perfect, can't cause buffer overflow there.... Ermm.. wait I got , well use python!
- lispm 13y ago
  What do you think the Java runtime is written in? The Ruby runtime? The Python runtime? Hint: it starts with a C. If you build a house in a swamp, you are in trouble.
  - mox1 13y ago
    I was making a joke.... If C is the wrong choice, what is the right choice?
    - jmz92 13y ago
      In a couple years or so, my bet would be on Rust.
  - diminoten 13y ago
    > The Python runtime? Why, Python, of course![0] [0] - http://pypy.org/ http://pypy.org/ (I jest, your point is entirely valid)
  - aryastark 13y ago
    Wow, you're daft. Everything is, ultimately, getting turned into machine code. Not even Lisp Machines could get away from this fundamental fact: http://funcall.blogspot.com/2009/04/some-lisp-machine-minutia.html http://funcall.blogspot.com/2009/04/some-lisp-machine-minuti... > Bogus objects — properly tagged words with invalid addresses that pointed at uninitialized memory or into the middle of object of a different type — which would cause the GC to corrupt memory would be left in registers or on the stack. These sort of problems were everywhere in the microcode. Go build your cabin in the woods now.

pg_is_a_butt 13y ago

GnuEverything is harmful. bunch of morons making shit code for shit people. shave your beard, hippy. you STINK.

AceJohnny2 13y ago

Any updates to this 6-year old post? I would hope that, with systems like Debian forcing a move to GnuTLS from OpenSSL (for licensing reasons), it would have since received more care.

blueskin_ 13y ago

I really don't see the Point of GnuTLS. Sure, if you want to directly integrate OpenSSL with GPL code, you can't, but as it's a library, you should be using it normally anyway. OpenSSL is far more widely used, has a longer history, and I would say is better tested and understood.

hyc_symas 13y ago

For the morbidly curious, ITS#5361 which triggered the above email: http://www.openldap.org/its/index.cgi/Incoming?id=5361 http://www.openldap.org/its/index.cgi/Incoming?id=5361

hyc_symas 13y ago
Other gems - ITS#5991 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5991 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=599... which required us to hack up a workaround. It also triggered ITS #5992 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5992 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=599... Discussion of the GnuTLS bug is summarized here https://www.debian-administration.org/users/dkg/weblog/42 https://www.debian-administration.org/users/dkg/weblog/42 And people still wonder that GnuTLS certificate verification bugs continue to surface?