3 ms·

It can be both successful and a terrible idea. Another example would be the single-user automobile becoming the dominant form of transit in the US.

rando289 12y ago
It can be whatever you want to call it. Terrible in comparison to a fantasy land of candy and rainbows. OP is saying "as a community we should say no to funding C security software". It's about as insightful as saying anyone who uses a car is dumb.
- prodigal_erik 12y ago
  I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished, and by now yet another attempt shows such poor judgment that funding ought not be provided. Certainly Linux has had remote root exploits, and so many local exploits that its multi-user model is no longer taken very seriously, and the other kernels have fared no better.
  - rando289 12y ago
    > I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished Kinda proves my point.
  - Sanddancer 12y ago
    Conversely, the well-audited OpenBSD kernel has had next to none of these problems precisely because they pay attention to correctness, even with the "fatigued and rusty scrap iron" that is the C language.
    - PhantomGremlin 12y ago
      I'm sure that OpenBSD is much more secure in general than Linux. I love it and use it as my own firewall. But even OpenBSD has had its share of local root exploits. They've even had 2 remote root exploits, and so few only because most services are disabled by default.
      - Sanddancer 12y ago
        True. However, they also as a group have done some pretty significant research into problems declared solved in order to make systems more secure. For example, the change a few years back to make malloc based on mmap instead of more traditional heap pools, so that if there is an overflow, the program's much more likely to segfault than to go gleefully trampling over data, etc. Additionally, it's worth keeping in mind that the reason for the OpenBSD team forking OpenSSL wasn't Heartbleed, but rather the OpenSSL team's rather terribly coded malloc replacement that did things in there. All of the security research and practices the OpenBSD team typically insists upon couldn't do anything because OpenSSL insisted on running in its own leaky memory box.
  - bstx 12y ago
    > I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished https://sel4.systems https://sel4.systems Possibly one of the most trustworthy pieces of software there is.
    - prodigal_erik 12y ago
      Man, I'd forgotten about that project. I wonder how much of the code could have been written differently and how much was effectively dictated by the theorem prover. Those are probably the very first people in the industry who deserve to be called engineers.
    - Intermernet 12y ago
      The sneaky thing they did is write seL4 in Literate Haskell, and then translate it to C. That involves some serious understanding of both languages! http://ssrg.nicta.com.au/projects/seL4/tech.pml http://ssrg.nicta.com.au/projects/seL4/tech.pml
    - Dewie 12y ago
      So what did they do? Write the code in C and then proved it with Isabelle/HOL? Extracted C code from Isabelle/HOL?
  - beagle3 12y ago
    d.j.b software (qmail, nacl, dnscurve, others). It is rare, but it has been done.
    - borplk 12y ago
      Oh the irony. Those that you mention are also safe until proven otherwise. I remember before Heartbleed was discovered everyone was raving about how secure OpenSSL is because it has been around for so long yadda yadda ... Heartbleed was discovered and everyone's suddenly acting "haha I knew it all along .. it was shit".
      - beagle3 12y ago
        Everything is safe only until proven otherwise. Java will save you from (say) buffer overflows, but not SQL injections or permission errors (the most probable successful attack against Apache servers had always been writable executable directories, even though it is written in C and had its share of buffer overflows) And if your circle thought OpenSSL was tight, you are hanging in the wrong circles for security. Heart less was exceptionally bad, but OpenSSL for a long time had a couple of security fixes a month on Ubuntu and Debian - that's enough to tell you that you need to follow advisories closely and not trust blindly. And yes, I have been saying that for at least 5 years, before heartbleed was introduced.
    - _delirium 12y ago
      Even djb software has your usual C-type security issues, though in less frequency than normal. qmail had an integer overflow that was theoretically exploitable, but couldn't be practically exploited in a normal configuration (djb admitted that was "pure luck"). And djbdns had an integer overflow that was exploitable (though in fairly unusual circumstances): http://article.gmane.org/gmane.network.djbdns/13864 http://article.gmane.org/gmane.network.djbdns/13864
- bashinator 12y ago
  Wow, that wasn't what I was saying at all. Read my post again - using (mostly) single-occupancy internal-combustion automobiles as the primary form of transit for the world's population is a terrible idea. When the car was first invented, I don't think anyone was thinking about 40,000 road deaths a year and CO2 pollution causing global climage change. When UNIX and linux kernels were written in C, nobody was thinking about string formatting or memory allocation exploits being used to steal millions of credit card numbers. That doesn't mean that drivers are dumb, or kernel developers. It does mean that we're living with the terrible consequences of various first-to-market success stories.

rando289 12y ago

It can be whatever you want to call it. Terrible in comparison to a fantasy land of candy and rainbows. OP is saying "as a community we should say no to funding C security software". It's about as insightful as saying anyone who uses a car is dumb.

prodigal_erik 12y ago
I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished, and by now yet another attempt shows such poor judgment that funding ought not be provided. Certainly Linux has had remote root exploits, and so many local exploits that its multi-user model is no longer taken very seriously, and the other kernels have fared no better.
- rando289 12y ago
  > I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished Kinda proves my point.
- Sanddancer 12y ago
  Conversely, the well-audited OpenBSD kernel has had next to none of these problems precisely because they pay attention to correctness, even with the "fatigued and rusty scrap iron" that is the C language.
  - PhantomGremlin 12y ago
    I'm sure that OpenBSD is much more secure in general than Linux. I love it and use it as my own firewall. But even OpenBSD has had its share of local root exploits. They've even had 2 remote root exploits, and so few only because most services are disabled by default.
    - Sanddancer 12y ago
      True. However, they also as a group have done some pretty significant research into problems declared solved in order to make systems more secure. For example, the change a few years back to make malloc based on mmap instead of more traditional heap pools, so that if there is an overflow, the program's much more likely to segfault than to go gleefully trampling over data, etc. Additionally, it's worth keeping in mind that the reason for the OpenBSD team forking OpenSSL wasn't Heartbleed, but rather the OpenSSL team's rather terribly coded malloc replacement that did things in there. All of the security research and practices the OpenBSD team typically insists upon couldn't do anything because OpenSSL insisted on running in its own leaky memory box.
- bstx 12y ago
  > I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished https://sel4.systems https://sel4.systems Possibly one of the most trustworthy pieces of software there is.
  - prodigal_erik 12y ago
    Man, I'd forgotten about that project. I wonder how much of the code could have been written differently and how much was effectively dictated by the theorem prover. Those are probably the very first people in the industry who deserve to be called engineers.
  - Intermernet 12y ago
    The sneaky thing they did is write seL4 in Literate Haskell, and then translate it to C. That involves some serious understanding of both languages! http://ssrg.nicta.com.au/projects/seL4/tech.pml http://ssrg.nicta.com.au/projects/seL4/tech.pml
  - Dewie 12y ago
    So what did they do? Write the code in C and then proved it with Isabelle/HOL? Extracted C code from Isabelle/HOL?
- beagle3 12y ago
  d.j.b software (qmail, nacl, dnscurve, others). It is rare, but it has been done.
  - borplk 12y ago
    Oh the irony. Those that you mention are also safe until proven otherwise. I remember before Heartbleed was discovered everyone was raving about how secure OpenSSL is because it has been around for so long yadda yadda ... Heartbleed was discovered and everyone's suddenly acting "haha I knew it all along .. it was shit".
    - beagle3 12y ago
      Everything is safe only until proven otherwise. Java will save you from (say) buffer overflows, but not SQL injections or permission errors (the most probable successful attack against Apache servers had always been writable executable directories, even though it is written in C and had its share of buffer overflows) And if your circle thought OpenSSL was tight, you are hanging in the wrong circles for security. Heart less was exceptionally bad, but OpenSSL for a long time had a couple of security fixes a month on Ubuntu and Debian - that's enough to tell you that you need to follow advisories closely and not trust blindly. And yes, I have been saying that for at least 5 years, before heartbleed was introduced.
  - _delirium 12y ago
    Even djb software has your usual C-type security issues, though in less frequency than normal. qmail had an integer overflow that was theoretically exploitable, but couldn't be practically exploited in a normal configuration (djb admitted that was "pure luck"). And djbdns had an integer overflow that was exploitable (though in fairly unusual circumstances): http://article.gmane.org/gmane.network.djbdns/13864 http://article.gmane.org/gmane.network.djbdns/13864
bashinator 12y ago
Wow, that wasn't what I was saying at all. Read my post again - using (mostly) single-occupancy internal-combustion automobiles as the primary form of transit for the world's population is a terrible idea. When the car was first invented, I don't think anyone was thinking about 40,000 road deaths a year and CO2 pollution causing global climage change. When UNIX and linux kernels were written in C, nobody was thinking about string formatting or memory allocation exploits being used to steal millions of credit card numbers. That doesn't mean that drivers are dumb, or kernel developers. It does mean that we're living with the terrible consequences of various first-to-market success stories.