3 ms·

Well then I guess "mainstream of software security" needs to do a better marketing job to explain to dumb programmers like me why I should be using memory safe

by ok_dad 4y ago

Well then I guess "mainstream of software security" needs to do a better marketing job to explain to dumb programmers like me why I should be using memory safe programming languages! Seriously, I would love to see a succinct explanation for the "rewrite everything" philosophy, but it seems religiously dogmatic to me so far and has done the opposite of convince me to use Rust (or another memory-safe language). On the other hand, the "statically typed language" community has done a great job of convincing me that I should be using statically typed programming languages by showing many examples of where typing would help me in my day to day work, and now I like using Go a lot and I avoid tons of issues I had with Python in the past.

tptacek 4y ago
No, they don't. Not in this case, at least. They can just build better software, and it will get adopted. You're writing Go already, so I'm not sure why anyone would want to burn time in pointless debates about this stuff. Carry on! You're already doing it right.
- ok_dad 4y ago
  I wanted to point you at this, which is example zero for why rewriting in "memory safe language number X" isn't always the best path: https://news.ycombinator.com/item?id=33171028 https://news.ycombinator.com/item?id=33171028 I'm definitely not debating that using better languages is better, but what I am saying is that some tools written in C have been effectively tested in the real-world by being on billions of machines and being used millions of times per day. I am not totally sure, but I think if there were major issues with the current NTP implementations we would probably have found them by now? Maybe not! But, in any case, rewrites need to be more carefully considered, planned, and executed than just some people I don't know writing a new NTP in Rust and stating it's fine to use for 80% of cases. Thanks for having a nice discussion with me, I think I am a bit more convinced that we need to rewrite some stuff, but perhaps also more convinced that we need to do a better job of picking what to rewrite and why!
  - tptacek 4y ago
    Yes, I understand the point you're making that sufficiently audited C code is as safe as Rust. No, it isn't. Where that sufficiently-audited C code is feasible to replace, it will all be replaced. Browsers may take a decade or two, but C/C++-language NTP servers had better head for the bunkers and hope for some global cataclysm to halt all progress in the industry.
    - ok_dad 4y ago
      > the point you're making that sufficiently audited C code is as safe as Rust The point I am actually trying to make is that memory safety is not the only consideration for security and safety. If you make a memory safe NTP and there turns out to be bad logic inside that code that does something allowing a security hole, then that's just as bad, if not worse, than using the decades-old software that did not have that bad logic, because that software has been tested in the real world day in day out for DECADES. I trust (somewhat) that Rust isn't going to allow unsafe memory access. I don't trust that Rust programmers can write code with no bugs that's better than a tool that has been refined over generations of programmers. Memory safe programming is a tech solution to a human problem (human imperfection). Again, new projects should be written in a memory safe language, but that's a whole other topic, IMO.
      - tptacek 4y ago
        The claim isn't that memory-safe languages foreclose on all security vulnerabilities; only the worst of them. As someone who has at various times had the job of carefully reviewing large C codebases for vulnerabilities, I'll attest: whatever the rest of the vulnerabilities may be, you spend most of your time trying (and failing) to hunt down all the memory corruption problems. Your confidence in the decades of review C programs have had, in all but a very few cases, is probably misplaced.
        ok_dad 4y ago
        I’m not even saying reviews, I’m saying that code has been tested in “the arena” and been proven billions of times. I used to work in incoming quality inspection, I know human reviews are at best 85 percent accurate. I’m arguing that decades of hammering on those old as hell programs have done the reviews for you.
stoplying1 4y ago
The irony of you calling others dogmatic in this conversation is a cue for me to stop reading it, I guess.

by ok_dad 4y ago

tptacek 4y ago

No, they don't. Not in this case, at least. They can just build better software, and it will get adopted. You're writing Go already, so I'm not sure why anyone would want to burn time in pointless debates about this stuff. Carry on! You're already doing it right.

ok_dad 4y ago
I wanted to point you at this, which is example zero for why rewriting in "memory safe language number X" isn't always the best path: https://news.ycombinator.com/item?id=33171028 https://news.ycombinator.com/item?id=33171028 I'm definitely not debating that using better languages is better, but what I am saying is that some tools written in C have been effectively tested in the real-world by being on billions of machines and being used millions of times per day. I am not totally sure, but I think if there were major issues with the current NTP implementations we would probably have found them by now? Maybe not! But, in any case, rewrites need to be more carefully considered, planned, and executed than just some people I don't know writing a new NTP in Rust and stating it's fine to use for 80% of cases. Thanks for having a nice discussion with me, I think I am a bit more convinced that we need to rewrite some stuff, but perhaps also more convinced that we need to do a better job of picking what to rewrite and why!
- tptacek 4y ago
  Yes, I understand the point you're making that sufficiently audited C code is as safe as Rust. No, it isn't. Where that sufficiently-audited C code is feasible to replace, it will all be replaced. Browsers may take a decade or two, but C/C++-language NTP servers had better head for the bunkers and hope for some global cataclysm to halt all progress in the industry.
  - ok_dad 4y ago
    > the point you're making that sufficiently audited C code is as safe as Rust The point I am actually trying to make is that memory safety is not the only consideration for security and safety. If you make a memory safe NTP and there turns out to be bad logic inside that code that does something allowing a security hole, then that's just as bad, if not worse, than using the decades-old software that did not have that bad logic, because that software has been tested in the real world day in day out for DECADES. I trust (somewhat) that Rust isn't going to allow unsafe memory access. I don't trust that Rust programmers can write code with no bugs that's better than a tool that has been refined over generations of programmers. Memory safe programming is a tech solution to a human problem (human imperfection). Again, new projects should be written in a memory safe language, but that's a whole other topic, IMO.
    - tptacek 4y ago
      The claim isn't that memory-safe languages foreclose on all security vulnerabilities; only the worst of them. As someone who has at various times had the job of carefully reviewing large C codebases for vulnerabilities, I'll attest: whatever the rest of the vulnerabilities may be, you spend most of your time trying (and failing) to hunt down all the memory corruption problems. Your confidence in the decades of review C programs have had, in all but a very few cases, is probably misplaced.
      - ok_dad 4y ago
        I’m not even saying reviews, I’m saying that code has been tested in “the arena” and been proven billions of times. I used to work in incoming quality inspection, I know human reviews are at best 85 percent accurate. I’m arguing that decades of hammering on those old as hell programs have done the reviews for you.

stoplying1 4y ago

The irony of you calling others dogmatic in this conversation is a cue for me to stop reading it, I guess.