9 ms·

Asinine victim-blaming. "If you were good at C, it wouldn't have memory safety problems." OpenSSH, a program written by one of the most security conscious gro

Asinine victim-blaming. "If you were good at C, it wouldn't have memory safety problems." OpenSSH, a program written by one of the most security conscious groups of developers out there (OpenBSD), used widely by pretty much every technology company out there including all of the top 8 companies in the world, has had multiple memory safety problems over its lifetime, /none/ of which would have happened in Rust, Zig, or any of their ilk. Yes, portability in LLVM-based languages is a problem for sure. Even an LLVM/GCC monoculture isn't particularly great. But saying "nah, you're just doing it wrong"? No.

adamnemecek 6y ago
The funniest part is that he compares it to bc.
- ghoward 6y ago
  Author here. Cryptography is not far off of bc. It is deterministic and should be easily testable. My bc is battle-hardened because I did my due diligence. The authors of the Cryptography library are writing _crypto_, which requires such due diligence. Did they? What I should add to the post is that if they were not planning on doing that due diligence from the start, they should have written it in Rust from the beginning and not made promises to users that they couldn't keep.
  - adamnemecek 6y ago
    Most programs have those properties. Cryptography is very far off from bc because no one is actually trying to exploit bc. It’s open source software. There are no promises.
    - ghoward 6y ago
      In the post, I try to make the case that there were, in fact, promises. Obviously, I didn't make that case well. However, if I was very careful with bc, despite the fact that no one was going to exploit it (which would not be the case if there was a vector for it, such as someone using bc in a script that runs as root), how much more careful should the Cryptography authors have been, since they were writing crypto? And if they were not going to be careful, they should have used Rust from the beginning and not made (implicit) promises to users. Edit: typo.
      - adamnemecek 6y ago
        > how much more careful should the Cryptography authors have been, since they were writing crypto? Did you consider that they are being careful by rewriting it in Rust? > And if they were not going to be careful, they should have used Rust from the beginning and not made (implicit) promises to users. Maybe Rust wasn't quite there at that point.
        ghoward 6y ago
        > Did you consider that they are being careful by rewriting it in Rust? So they are only starting to be careful after several years? I addressed that point in the post. > Maybe Rust wasn't quite there at that point. It wasn't. But that's the point. Rust wasn't there, it's not there now. It needs to be as portable as C to be "there".
        adamnemecek 6y ago
        > So they are only starting to be careful after several years? I addressed that point in the post. No since you’ll get to the “battle tested” point much fastener.
        ghoward 6y ago
        > No since you’ll get to the “battle tested” point much fastener. I'm not sure what you mean here. Are you saying that a bc will get to a battle-tested state faster than crypto? If you are, I disagree whole-heartedly. Crypto is bigint math with a few extras. bc has bigint math, a lexer, a parser, and an interpreter. Of those, the parser and interpreter are far more complicated than the bigint math. And bc's bigint math is not actually just bigint; it's bigdecimal.
segfaultbuserr 6y ago
As a Gentoo user and an enthusiastic non-x86 user, when I was just reading the opening, I expected to hear an argument about the necessity of supporting uncommon architectures as a standard library. Gentoo supports a broad range of systems, every time an underlying library switches to a less supported environment creates a headache for Gentoo developers and users, "vintage architecture needs some love" would be an interesting article (not saying it's practical, but interesting). Unfortunately, the author's main argument is a denial of C's memory safety problems. I was disappointed.
- ghoward 6y ago
  Author here. If you read deeper into the post, I do, in fact, talk about how supporting those less well-known architectures is important. Edit: Also, those arguments were made plenty by others, so I didn't feel a need to rehash them much.
  - segfaultbuserr 6y ago
    (note: the original comment has been rewritten) > If you read deeper into the post I did skim the entire post, but the discussion on supporting alternative computer architectures was significantly shorter than the issue of memory safety, or Rust or Zig as languages. > Also, those arguments were made plenty by others, so I didn't feel a need to rehash them much. Fair enough. BTW, I agree with you that generating portable C is actually an interesting solution. Recently, there are a few successful projects like HACL* (Microsoft) [0], Fiat-Crypto (MIT CSAIL) [1] that are based on this idea - they use a high-level framework to synthesize human-unreadable but formally verified C code, effectively using C as a form of portable assembly. Both have been deployed in real-world systems like OpenSSH, Chromium and the Linux kernel with great success. [0] https://github.com/project-everest/hacl-star https://github.com/project-everest/hacl-star [1] https://github.com/mit-plv/fiat-crypto https://github.com/mit-plv/fiat-crypto
    - ghoward 6y ago
      Thank you for your kind words and the links!
simion314 6y ago
>Asinine victim-blaming The fact the post is flagged now somehow makes me feel that Rust community can't stand anything else then praise and worship.
- zanellato19 6y ago
  It retreads the same old, tired argument that Rust developers have been disproving it for so long, i.e. "Just write good C code" or in this case "Just battle test it"
  - simion314 6y ago
    So this means it should be flagged?
    - pjmlp 6y ago
      Not at all, thing is, are you sure it was a Rust fanboy?
      - simion314 6y ago
        You think it was an Apple or Arch fanboy?
        pjmlp 6y ago
        No, I think it was a random dude on Internet without any way to prove who did it.
        simion314 6y ago
        Sure it is possible, someone that is not attached to Rust just decided to hide some criticism, but IMO this chance is almost Zero. At least we agree that flagging should be used only for out of scope articles or truly terrible ones like "I wrote an incomplete, undocumented,unsupported, unremarkable, buggy piece of code in Rust"
ghoward 6y ago
Author here. What they did wrong was making promises to users and then breaking those promises. I also tried to make the case that they either did not do their due diligence, which they should have done because they used C in the first place, or they did and should not have given up that battle-tested code. I even mentioned that they were victims of the Rust language not keeping its promises. So I disagree that I am blaming the victim here. Also, if they did not want to do the due diligence required by using C, they should have written Cryptography in Rust from the beginning and not made promises to users that they couldn't keep.
- tptacek 6y ago
  Rust was not a viable option when pyca/cryptography was first released. You should be more familiar with projects before you invent strange promises you feel they've made to you.
  - ghoward 6y ago
    I made the argument knowing that, actually. And in my opinion, the promises are almost always implicit.
    - tptacek 6y ago
      No, after re-reading your piece, I don't think you did.
      - ghoward 6y ago
        Then I guess I made the argument poorly and still need practice writing for an audience.
        tptacek 6y ago
        A good start would have been acknowledging that flaw in your premise, anywhere in the piece. It's an unsalvageable argument regardless; you have invented a promise nobody made to you, compelling strangers to manage a project in which you have no involvement to conduct their work in accordance with your wishes.
wglb 6y ago
Then there is qmail. Totally written in C. No bugs, no security flaws. But the author is way brighter than I am. I spent my youth programming real-time interrupt rich medical diagnostic software in low-level assembly language, which is harder to get right than C. We had very few bugs. I would be reluctant to do this in C, probably less so in Rust (which I have yet to master) I appreciate what the Rust community is trying to accomplish, and suspect it will happen. However, there is an sense of overselling this idea of memory safety. Keep in mind that SolarWinds and Equifax are not memory safety issues. Also, someone wrote a Rust version of heartbleed, so it would be good to keep a perspective. And it isn't like I haven't been in the position to be rabid promoter of programming demagoguery. First was the unnecessarily limited gammar of Fortran II. I discovered XP/L and promoted that beyond reason. Then there was the GOTO demagogery which I was one of the loudest. And along with that Structured Programming, then Object Oriented Programming. So as you promote Rust, don't sell the idea that it will prevent every security nightmare out there--it will massively help with some very important ones. Additional work beyond programming language is necessary to improve security.
- pjmlp 6y ago
  When companies like Microsoft and Google publish security reports they state 70% of security exploits were caused by memory corruption bugs, they don't say 100%. Naturally memory safe systems programming languages still suffer from the remaining 30% root causes for security exploits. It isn't perfect, but much better, and we aren't still there because bean counters haven't been paying attention how much money it costs to fix those bugs, and the lack of liability.
  - wglb 6y ago
    Agreed. But there are exploits and there are breaches. Exploits are bad and Rust will help, but in the rest of industry and government and military, exploits are not the whole story with respect to what causes breaches.

adamnemecek 6y ago

The funniest part is that he compares it to bc.

ghoward 6y ago
Author here. Cryptography is not far off of bc. It is deterministic and should be easily testable. My bc is battle-hardened because I did my due diligence. The authors of the Cryptography library are writing _crypto_, which requires such due diligence. Did they? What I should add to the post is that if they were not planning on doing that due diligence from the start, they should have written it in Rust from the beginning and not made promises to users that they couldn't keep.
- adamnemecek 6y ago
  Most programs have those properties. Cryptography is very far off from bc because no one is actually trying to exploit bc. It’s open source software. There are no promises.
  - ghoward 6y ago
    In the post, I try to make the case that there were, in fact, promises. Obviously, I didn't make that case well. However, if I was very careful with bc, despite the fact that no one was going to exploit it (which would not be the case if there was a vector for it, such as someone using bc in a script that runs as root), how much more careful should the Cryptography authors have been, since they were writing crypto? And if they were not going to be careful, they should have used Rust from the beginning and not made (implicit) promises to users. Edit: typo.
    - adamnemecek 6y ago
      > how much more careful should the Cryptography authors have been, since they were writing crypto? Did you consider that they are being careful by rewriting it in Rust? > And if they were not going to be careful, they should have used Rust from the beginning and not made (implicit) promises to users. Maybe Rust wasn't quite there at that point.
      - ghoward 6y ago
        > Did you consider that they are being careful by rewriting it in Rust? So they are only starting to be careful after several years? I addressed that point in the post. > Maybe Rust wasn't quite there at that point. It wasn't. But that's the point. Rust wasn't there, it's not there now. It needs to be as portable as C to be "there".
        adamnemecek 6y ago
        > So they are only starting to be careful after several years? I addressed that point in the post. No since you’ll get to the “battle tested” point much fastener.
        ghoward 6y ago
        > No since you’ll get to the “battle tested” point much fastener. I'm not sure what you mean here. Are you saying that a bc will get to a battle-tested state faster than crypto? If you are, I disagree whole-heartedly. Crypto is bigint math with a few extras. bc has bigint math, a lexer, a parser, and an interpreter. Of those, the parser and interpreter are far more complicated than the bigint math. And bc's bigint math is not actually just bigint; it's bigdecimal.

segfaultbuserr 6y ago

As a Gentoo user and an enthusiastic non-x86 user, when I was just reading the opening, I expected to hear an argument about the necessity of supporting uncommon architectures as a standard library. Gentoo supports a broad range of systems, every time an underlying library switches to a less supported environment creates a headache for Gentoo developers and users, "vintage architecture needs some love" would be an interesting article (not saying it's practical, but interesting). Unfortunately, the author's main argument is a denial of C's memory safety problems. I was disappointed.

ghoward 6y ago
Author here. If you read deeper into the post, I do, in fact, talk about how supporting those less well-known architectures is important. Edit: Also, those arguments were made plenty by others, so I didn't feel a need to rehash them much.
- segfaultbuserr 6y ago
  (note: the original comment has been rewritten) > If you read deeper into the post I did skim the entire post, but the discussion on supporting alternative computer architectures was significantly shorter than the issue of memory safety, or Rust or Zig as languages. > Also, those arguments were made plenty by others, so I didn't feel a need to rehash them much. Fair enough. BTW, I agree with you that generating portable C is actually an interesting solution. Recently, there are a few successful projects like HACL* (Microsoft) [0], Fiat-Crypto (MIT CSAIL) [1] that are based on this idea - they use a high-level framework to synthesize human-unreadable but formally verified C code, effectively using C as a form of portable assembly. Both have been deployed in real-world systems like OpenSSH, Chromium and the Linux kernel with great success. [0] https://github.com/project-everest/hacl-star https://github.com/project-everest/hacl-star [1] https://github.com/mit-plv/fiat-crypto https://github.com/mit-plv/fiat-crypto
  - ghoward 6y ago
    Thank you for your kind words and the links!

simion314 6y ago

>Asinine victim-blaming The fact the post is flagged now somehow makes me feel that Rust community can't stand anything else then praise and worship.

zanellato19 6y ago
It retreads the same old, tired argument that Rust developers have been disproving it for so long, i.e. "Just write good C code" or in this case "Just battle test it"
- simion314 6y ago
  So this means it should be flagged?
  - pjmlp 6y ago
    Not at all, thing is, are you sure it was a Rust fanboy?
    - simion314 6y ago
      You think it was an Apple or Arch fanboy?
      - pjmlp 6y ago
        No, I think it was a random dude on Internet without any way to prove who did it.
        simion314 6y ago
        Sure it is possible, someone that is not attached to Rust just decided to hide some criticism, but IMO this chance is almost Zero. At least we agree that flagging should be used only for out of scope articles or truly terrible ones like "I wrote an incomplete, undocumented,unsupported, unremarkable, buggy piece of code in Rust"

ghoward 6y ago

Author here. What they did wrong was making promises to users and then breaking those promises. I also tried to make the case that they either did not do their due diligence, which they should have done because they used C in the first place, or they did and should not have given up that battle-tested code. I even mentioned that they were victims of the Rust language not keeping its promises. So I disagree that I am blaming the victim here. Also, if they did not want to do the due diligence required by using C, they should have written Cryptography in Rust from the beginning and not made promises to users that they couldn't keep.

tptacek 6y ago
Rust was not a viable option when pyca/cryptography was first released. You should be more familiar with projects before you invent strange promises you feel they've made to you.
- ghoward 6y ago
  I made the argument knowing that, actually. And in my opinion, the promises are almost always implicit.
  - tptacek 6y ago
    No, after re-reading your piece, I don't think you did.
    - ghoward 6y ago
      Then I guess I made the argument poorly and still need practice writing for an audience.
      - tptacek 6y ago
        A good start would have been acknowledging that flaw in your premise, anywhere in the piece. It's an unsalvageable argument regardless; you have invented a promise nobody made to you, compelling strangers to manage a project in which you have no involvement to conduct their work in accordance with your wishes.

wglb 6y ago

Then there is qmail. Totally written in C. No bugs, no security flaws. But the author is way brighter than I am. I spent my youth programming real-time interrupt rich medical diagnostic software in low-level assembly language, which is harder to get right than C. We had very few bugs. I would be reluctant to do this in C, probably less so in Rust (which I have yet to master) I appreciate what the Rust community is trying to accomplish, and suspect it will happen. However, there is an sense of overselling this idea of memory safety. Keep in mind that SolarWinds and Equifax are not memory safety issues. Also, someone wrote a Rust version of heartbleed, so it would be good to keep a perspective. And it isn't like I haven't been in the position to be rabid promoter of programming demagoguery. First was the unnecessarily limited gammar of Fortran II. I discovered XP/L and promoted that beyond reason. Then there was the GOTO demagogery which I was one of the loudest. And along with that Structured Programming, then Object Oriented Programming. So as you promote Rust, don't sell the idea that it will prevent every security nightmare out there--it will massively help with some very important ones. Additional work beyond programming language is necessary to improve security.

pjmlp 6y ago
When companies like Microsoft and Google publish security reports they state 70% of security exploits were caused by memory corruption bugs, they don't say 100%. Naturally memory safe systems programming languages still suffer from the remaining 30% root causes for security exploits. It isn't perfect, but much better, and we aren't still there because bean counters haven't been paying attention how much money it costs to fix those bugs, and the lack of liability.
- wglb 6y ago
  Agreed. But there are exploits and there are breaches. Exploits are bad and Rust will help, but in the rest of industry and government and military, exploits are not the whole story with respect to what causes breaches.