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.
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.
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.
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.
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.
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"
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. :)
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.
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.
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.
> 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.
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.
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.
> First, their argument for Rust (and against C) because of memory safety implies that they have not done due diligence in finding and fixing such bugs.
No, it implies that finding such bugs is exponentially harder in C than it is in other languages. Eventually you reach so far up the diminishing returns curve that you simply are able to accomplish more in one language with your time on Earth than you can in another. This is a numbers game, and C loses out to safer competitors when it comes to bugs.
The due diligence that these developers are doing is a meta-analysis that has gone over your head.
> And with my bc, I did my due diligence with memory safety. I fuzzed my bc and eliminated all of the bugs.
That's a pretty absolute claim. And one I doubt.
I'll save my trust for people humble enough to understand the limitations of technologies and themselves.
Which makes it all the worse, because he's using that as "proof" that he has done more due diligence than these other devs, and suggesting that they could achieve just-as-good-or-better results by emulating him (which is provably false given the nature of C vs rust when it comes to bugs).
For a calculator it may be no huge deal to have such a cavalier attitude. But for cryptography, bugs are considerably more important as the threat model isn't even in the same league.
The fact that I _could have had_ a cavalier attitude towards C memory safety, but didn't, shows (I believe) just how much the Cryptography authors fell short because _they were writing crypto_. If anything, they should have surpassed the amount of due diligence that I did on bc, but they didn't.
It's easy to look back in hindsight and take potshots based on everything someone did wrong. There's not a project out there where you couldn't do this.
I took a quick look over the thread, and TBH I find the authors' reasons and explanations compelling, logical, and respectful (their FAQ, the fact that they polled the users almost a year ago, the fact that they announced their intentions in advance, and how to deal with the impending changes). I suggest you re-think your approach; this won't reflect well.
I mean escalating a minor dust-up into a blog post about their wrongs, and then further pushing it in a worldwide forum (HN).
I don't mean to be rude, but as a disinterested third party, the optics of all of this and your handling of a disagreement reflect badly upon you. At some point in the future after you've cooled off, you'll probably delete the post (but better sooner than later!)
I actually don't see what you said as being rude, just honest, and I appreciate that.
I actually let myself cool down before I wrote the post. I was going to write the post right after I saw the GitHub issue, but I sat on it for awhile, thinking through my thoughts.
It's unfortunate that such a dust-up (which wasn't minor, by the way; it got published in LWN, see https://lwn.net/Articles/845535/) was a perfect way to make arguments against Rust that I have wanted to make.
And I wanted to make them because if Rust can be as portable as C, I would LOVE that!
I understand why people are angry and that portability is a worthwhile goal in many scenarios. I also understand that Rust is far from the ubiquity that C has achieved. I also understand that people feel betrayed by a library they depended on drastically altering its dependency structure.
On the other hand, there's a group of developers with limited resources and perceived moral high ground in terms of security that fits right in with the trends that I've observed in the cryptography community.
Both sides have valid arguments. Which sides of this split you fall on depends on your personal values and immediate needs.
Ultimately, the whole debate is fruitless bickering because you cannot reconcile differences in values. This doesn't just apply to the Python "cryptography" library, but also other places where a switch to Rust was enforced by upstream.
The alternative is to define "closer" portability (iOS, Android, Windows, macOS, desktop/server Linux) and "wider" portability (BSDs, illumos, QNX, custom embedded OSes, architectures that aren't x86_64 and ARM). Then make it clear from the get-go which one of these you're aiming for.
There is a happy middle ground[1]. Someone could build a Rust->C compiler and then packages meant for releases could be bundled with pre-compiled C sources.
[1] of course the question of who is responsible for building such a compiler potentially becomes a new value-based conflict.
The author correctly, IMO, points out that this is not possible currently because there's no Rust Specification, so the exact behaviour of such a compiler cannot even be described.
I was surprised by how informal the Rust language semantics are when I was trying to find out how the `?` operator works, exactly. There's no official description anywhere except for an RFC which was created before the feature was introduced, but from which the feature has diverged significantly since it was added to the language!
The Rust Book, normally assumed to be the "true" description of the language, is quite incomplete in places as it's not a formal specification. For example, the section about `?` does not mention that different error types will be auto-converted if there's a `From` implementation between them. This is quite important information missing from the documentation. Just from reading that page, you would be writing really verbose type conversions yourself, everywhere.
But the Rust Book does mention this elsewhere[2] (if you're careful enough reading the first link, you can see that it says `?` is "more or less" equivalent to `try!`, and reading the docs for `try!` you could actually find out what it does, and hope they didn't change anything when implementing `?` - but that's a quite a lot of assumptions). You just need to read the whole book, or at least be lucky enough to look at all the right places, to make sure you understand how a language feature works, precisely.
Compiling to C, althought a common approach used by many that want to save the effort to implement a full backend, always has the issue that it might not be possible to express 1:1 the desired source language semantics in C, and some subtle bugs depending on which C compiler is used.
Can you give some examples of language semantics that cannot be expressed in C?
One I can think of is doing coroutine / stack swapping stuff. Though even that is not insurmountable if your sequential code is rendered into C in a “CPS” style.
Another related one is exotic manipulations of the instruction pointer beyond what goto/switch provide. This can be solved too, but inefficiently (put all jump-to-able lines of code in a big switch statement). GCC provides computed goto but that is not standard.
In either case, it’s worth pointing out that Rust does not do these types of things and it would be relatively straightforward for a machine to create a 100% semantically equivalent C program from a rust program.
Semantics of loops might also be tricky. In fact rust struggles with LLVM's optimizer already on some infinite loops because C++ and rust diverge in semantics there.
That’s actually trivial using unsigned arithmetic and two’s complement representation for signed integers, its also equally efficient[1]. Unsigned arithmetic is fully defined in c, including checking for overflow.
But that's my point; how can you be sure the compiler will emit the right code instead of assuming that the addition does not overflow and then proceed on pruning the test, since overflow on signed integers is not defined?
I mentioned that there are other places in the Book where this information is mentioned, but it's funny how the `?` is described in at least 3 places (your link plus my two other links), but the section you would expect most information about it, called "The ? operator for easier error handling" which is fully dedicated to explaining the operator, does not mention that fact.
My point, above all, is not tied to this specific example, by the way, hope you understand how an informal tutorial about the language does not replace a strict specification - and pointing out that such information is available somewhere if I look hard enough does not disprove anything.
> Right now, as far as I know, there is no official language spec for Zig, like there is for Go. This means that this new compiler may not match what the official compiler does.
They’re actively working on a spec for Zig btw. Here’s Andrew talking about it, first thing as part of the roadmap video: https://youtu.be/pacsngNYXI0
This is just a longer version of every angry comment on the Github Issue thread it's referring to, differing only in that this person doesn't seem to be a maintainer of any project intersecting with `cryptography`. If you're interested in this debate, such as it is, just read the Github thread.
We won't get rid of C that easily, given the amount of systems that depend on it and won't be rewritten, which is exactly why besides Apple, also Google, Oracle, ARM, Microsoft are leading efforts to turn modern computers into C machines, with hardware memory tagging to fix at hardware level what WG14 won't fix.
Portability would for sure be a great asset for Rust. But it's a new language compared to C. I also agree that having a clear spec is a must. But the author got lost, none of these languages have a clear sweet spot yet that would help them to define a clear spec.
I had added several links to the post regarding replies to what I said about Zig.
I have also clarified a few arguments.
And because there seems to be some disbelief at my claim of absolutely not bugs in my bc, I am going to throw down the gauntlet like I did in https://news.ycombinator.com/item?id=26293920.
I encourage everyone who thinks I am wrong to _prove_ me wrong. Find a memory safety bug in my bc.
Rust freely declares itself to be inspired by Cyclone et al, but its capabilities are quite different from Cyclone's region analysis (and Carp actually came after Rust).
The C++ static analysis, on the other hand, is quite limited in comparison even to Cyclone. It's not sound and doesn't even aim to be- in other words, "just" another static analysis that will not catch everything. ("Just" in quotes because of course more of this is great- my point is merely that it's not the same functionality coming to C++.)
What makes you think I'm "advocating" anything? My goal is for people to understand the state of things.
C and C++ have had static analyzers to catch "some version" of these problems for a long time now, so presumably anyone asking about borrow checker functionality would be interested in whether that functionality matches Rust's (i.e. is sound).
We should not forget that even if those static analysers aren't sound, they allow to keep using 50 years of eco-system.
Which is why companies like Microsoft, despite all security talk, in the end add support for recent ISO C versions, and have "secure" platforms like Azure Sphere with a C only SDK.
Likely not because a feature like that kind of has to be implemented as part of the core language. Maybe someone could retrofit a “safe” version of c/c++, but there’s nothing on the horizon that indicates that would be possible (they are hampered by back compat issues).
I mean, MyPy does have some core PEP support, but remains optional for Python.
If something as core as type checking can be an optional feature, I'd be surprised if a heftier brain than mine can't get most of the way to a C++ borrow checker optionally.
Doesn't C++ famously fetish complexity? Wasn't pi once calculated at compile-timel with a C++ template? Where is my Obfuscated C entry that looks like an ASCII Robotron game and borrow-checks, say, the Linux kernel?
On religion and LGBTQ issues:
> A strong, free nation can only be made up of religious and virtuous individuals, strong nuclear families with a cisgender father and a cisgender mother, and a lively and effective civil society, all protected under the wise framework of the Constitution as it was intended by our Founding Fathers.
> To have a virtuous people, America must return to its religious roots.
> Strong, nuclear families consisting of a cisgender father and a cisgender mother are the “fundamental units of society." All governments under the Constitution should protect and encourage them and discourage all other kinds of families made through voluntary actions.
On the right to vote and welfare:
> they who have actually paid for the services of government, and thus, should have a say in how it runs. Those who haven’t, and get themselves addicted to welfare, should not, for they do not pay the price of living in society.
> In addition, all government welfare is waste.
You can look at the sidebar for more fun tags, to see his opinions about Black Lives Matter (evil), "censorship" (Facebook and Squarespace taking down his favorite conspiracy pages), and many tags about his Mormon faith, which as an atheist, is probably not my place to criticize.
It's still mind boggling to me that enforcing public safety procedures can be interpreted as any sort of tyranny. He purposefully goes out of his way to not wear a mask, but still takes the time to keep one in his pocket to just see how far he can go breaking the rules.
You're like that person in the Adult Swim sketch about Google being a guy, where the person asking "Google" about something gets a million results showing A) and just 1 result showing B), and they decide to take B).
First of all, if you're really arguing that masks affect mental health more than they save lives (https://gavinhoward.com/2020/08/in-science-all-factors-matte...), I don't even know what to say. I'd really want to see the science behind this, but I suspect there isn't any real science. Common sense and knowledge of professions where people use a mask for long periods of time should be enough to debunk this.
Also, this is truly abhorrent:
> Of course, 161,392 people have died. (Oh whoops! It turns out that only 6% of those people died from COVID-19 alone, so it’s really 9,700 deaths)
If my car breaks don't work, I ostensibly die because I'll be crushed when my car falls of a cliff, but the real cause of my death is the fact that the car breaks didn't work.
For the other article, gee, I wonder if the folks behind it have an agenda to push: "Townhall: <<Conservative>> News, Cartoons, Top Stories".
Anyway, do realize that this is a global phenomenon, people aren't out to get your "freedoms" and countries which are far freer than the US have realized that Covid is a real pandemic and treat it using real science, not pseudo-sience peddled by crackpots or even worse, people with a hidden agenda (usually one about making $$$).
I know I won't change your mind, but please break out of your bubble. Find international sources, use Google Translate to see what they say, compare, contrast, think critically. Also, read up on your history and check out what they did to fight the 1919 flu, for example. Or SARS. Or what they're doing all over East Asia, mostly successfully.
Oh, by the way, your argument makes you look even worse than you think it does. It's all about ME ME ME! "There's a tiny chance that masks hurt me" and "there's a tiny chance that masks don't help others as much as people say", so basically, "f** everyone else in that case, I don't want to be inconvenienced".
Look, bub, you're on HN, now on /r/im14andthisisdeep.
> Who knows? The point is that we don't know all of the ways that masks affect us.
I don't know all the ways that the rice I ate yesterday affects me. I'm not going to stop eating rice because of this.
Your argument is completely null.
When there's no clear proof of something having a strong negative effect, the rational thing is to assume it doesn't have a strong negative effect.
When something clearly has a strong positive effect, the rational thing is to assume it has a strong positive effect.
And when we decide to do something, we balance positives with negatives. There is nothing in this world that only has positive aspects (the opposite is also true, nothing truly has only negative aspects). We never do something because it's "perfect", we do things that are "good" (more positives than negatives). We live because of water and oxygen but water can drown us and oxygen can burn us.
Your logic is: "a lot of very respectable people (as well as common sense) say that this thing has a positive effect, but I don't know if it has any negative effect, so I just won't do it at all".
That's no logic, it sounds more like spite.
I don't say this lightly, even on the internet, but you act like a horrible person. Please reflect on your behavior and for your sake, I hope you change.
Rice has been with humans since basically the beginning. Masks, not so much. My argument is that we don't know if there are actually more positives than negatives with masks.
Because he might have more expertise and experience in technology than medicine. We should evaluate arguments on their merits alone, ad hominem is destructive to effective discussion.
> so I focus my attention on people who are otherwise sensible.
Participation in a discussion usually implies an interest and a willingness to spend your time considering various arguments. If you only limit your exposure to arguments made by people who agree with you in other domains then I have to conclude your interest in this space is not very high.
> Participation is a discussion usually implies an interest and a willingness to spend your time considering various arguments.
My only posts in this thread have been to explain why I flagged the post and why I feel it's valid to dismiss the author based on his other views.
The author's position on masks is that he's too precious to comply with local laws, that businesses complying with said laws should be boycotted, and that executive orders aren't actually laws so he isn't bound by them. The first two beliefs are merely antisocial; it's the last claim that causes me to place him in the crank category.
> If you only limit your exposure to arguments made by people who agree with you in other domains then I have to assume your interest in this space is not very high.
My political beliefs are sufficiently bizarre that at best few people agree with them; if anything, he and I probably have some beliefs in common.
I consider dismissing arguments outright based on ad hominem and guilt by association without consideration of their substance deeply anti social and otherwise harmful to human collaboration, peace, and progress.
I'm amazed by the hostility of these comments, including personal attacks, and by this post being flagged. The author isn't some nobody who just finished a boot camp, but a very skilled C hacker. He makes a good argument for the importance of portability, a topic that seldom comes up in the C/Rust discussions I've read.
Yes but we're talking about today. And C's smallness/simplicity means that bootstrapping on new architectures is straightforward. Meanwhile Rust needs 64bit, etc. just to build. Rust's early embrace of compile-time complexity (ZCA) means this will always be a fundamental problem for the language. In fact it's getting worse over time.
The authors of Rust and Zig fail to understand why C is ubiquitous: “worse is better.” You can’t replace C with a better C because that is counter to why C is ubiquitous in the first place.
To be fair most engineers (including many brilliant ones) fail at grasping the intuition of providing simple but not 100% adequate solutions. The difficulty of the last 20% will drive most potential users/implementers away, and reduces the virality.
It seems like "worse is better" only applies selectively when C has the advantage. For instance, Rust has no formal spec, but surely that is fine according to the "worse is better" philosophy, because the current situation serves most, but not 100% of users. Rust doesn't support ancient architectures that aren't being manufactured anymore, but Rust supports most common architectures. Surely that is fine according to the "worse is better" philosophy?
It seems many who favor C over Rust don't actually believe in "worse is better". A language must be equal or better than C in all possible aspects before it can be greeted with reluctant distrust instead of hostility. "Worse is better" can be used to defend C, but never a new language.
I think you’re missing what the essence of “worse is better” means. It’s about the complexity of provided solutions, not generic “badness” or undone work. This is explained well in the original “worse is better” paper (lisp vs C).
Even if rust lacks a formal spec and ports to multiple platforms, it is unarguably more complex than C and is an example of “MIT” engineering. Both Rust and Zig pursue the “right thing” whereas C pursued the simplest workable thing, thus increasing its virality.
I think you’re missing my point. There is a non-linear relationship between the ubiquitousness of a language and its quality. That is to say, more quality does not always result in more ubiquitousness.
That does not mean progress is not possible, just that it’s not necessarily viral.
If the zig and rust creators understand that then they should stop measuring their success as a percentage of the size of their user base to the size of C’s user base because their goals are arguably counter to having a user base as large as C’s.
> If the zig and rust creators understand that then they should stop measuring their success as a percentage of the size of their user base to the size of C’s user base ...
Please provide a source for these alleged success criteria.
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.