Hacker News Reader

Comment by hlieberman | Hacker News Reader

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.

View on HN

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.

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.

(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

[1] https://github.com/mit-plv/fiat-crypto

Thank you for your kind words and the links!

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.

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.

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.

>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.

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"

So this means it should be flagged?

Not at all, thing is, are you sure it was a Rust fanboy?

You think it was an Apple or Arch fanboy?

No, I think it was a random dude on Internet without any way to prove who did it.

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"

Perhaps the flagger simply put this post in the "truly terrible" category- it retreads old and tired arguments without ever introducing any new depth or nuance.

Yes, the possibility is not zero, it would be great if flagging would always ask for a reason (similar with reporting on reddit ,where you have to specify the rule that is broken and everyone could see what was flagged and why)

Though don't you think that your criteria would affect all the "X subpar re-implemented in Rust" submissions there are same thing all the time only X changes.

Sure? I didn't say anything about other submissions. I honestly don't know which ones you have in mind anyway, so anything I could say would just be a guess. :)

Nope, that is the typical conspiracy theory of hanging people on trees without proofs.

Author here.

My argument is actually that Rust cannot replace C because it's not portable enough.

I would love for Rust to be portable enough.

Gavin, I don’t know you but let me just take this opportunity to say that I think you’re an incredible person and a smart talented hacker. The idea that software maintainers do indeed have some responsibility to their users rings true and consistent with reality.

Thank you. I'm glad to know there are others that feel the same way. :)

My pleasure. Don’t let these Rust justice warriors discourage you.

I'm not a Rust user.

I flagged it because it's poorly written flamebait that doesn't add anything to the comments on the GitHub thread.

The funniest part is that he compares it to bc.

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.

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.

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.

> 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.

> 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".

> 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.

> 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.

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.

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.

I made the argument knowing that, actually. And in my opinion, the promises are almost always implicit.

No, after re-reading your piece, I don't think you did.

Then I guess I made the argument poorly and still need practice writing for an audience.

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.

I don't know why I can't reply to your reply, so I'll post it here.

My argument is that Rust _still_ isn't ready for the Cryptography library because it's not portable enough.

And I am not a direct user of the Cryptography library. I am an indirect user on x86_64, so I am unaffected. They have kept their implicit promise to me.

The only people that can be pissed off by promises are paying customers.

So those paying to Cryptography developers, are the ones to be pissed off, IF their platforms aren't being considered.

Does that include the customers of https://fishinabarrel.github.io/, the company owned by one of the Cryptography developers?

Yes, assuming they are paying for it and are not able to use it on the use cases they are paying for.

Then again, they clearly mention on that page:

" Please put us out of business.

Stop writing C/C++.

Probably you should also sandbox your software. "

Reply on news.ycombinator.com