1. 62
  1.  

  2. 24

    It is safe to say that nobody can write memory-safe C, not even famous programmers that use all the tools.

    For me, it’s a top highlight. My rule of thumb is that if OpenBSD guys sometimes produce memory corruption bugs or null dereference bugs, then there is very little chance (next to none) than an average programmer will be able to produce a secure/rock solid C code.

    1. -1

      My rule of thumb is that if OpenBSD guys sometimes produce memory corruption bugs or null dereference bugs, then there is very little chance (next to none) than an average programmer will be able to produce a secure/rock solid C code.

      Why do you think “the OpenBSD guys” are so much better than you?

      Or if they are better than you, where do you get the idea that there isn’t someone that much better still? And so on?

      Or maybe let’s say you actually don’t know anything about programming, why would you trying to convince anyone else of anything coming directly from a place of ignorance? Can your gods truly not speak for themselves?

      I think you’re better than you realise, and could be even better than you think is possible, and that those “OpenBSD guys” need to eat and shit just like you.

      1. 24

        Why do you think “the OpenBSD guys” are so much better than you?

        It’s not about who is better than who. It’s more about who has what priorities; OpenBSD guys’ priority is security at the cost of functionality and convenience. Unless this is average Joe’s priority as well, statistically speaking OpenBSD guys will produce more secure code than Joe does, because they focus on it. And Joe just wants to write an application with some features, he doesn’t focus on security that much.

        So, since guys that focus on writing safe code sometimes produce exploitable code, then average Joe will certainly do it as well.

        If that weren’t true, then it would mean that OpenBSD guys security skill is below average, which I don’t think is true.

        1. 5

          OpenBSD guys’ priority is security at the cost of functionality

          I have heard that claim many times before. However, in reality I purely use OpenBSD for convenience. Having sndio instead of pulse, having no-effort/single command upgrades, not having to mess with wpa_supplicant or network manager, having easy to read firewall rules, having an XFCE desktop that just works (unlike Xubuntu), etc. My trade-off is that for example Steam hasn’t been ported to that platform.

          So, since guys that focus on writing safe code sometimes produce exploitable code, then average Joe will certainly do it as well.

          To understand you better. Do you think average Joe both will use Rust and create less mistakes? Also, do you think average Joe will make more logic errors with C or with Rust? Do you think average Joe will use Rust to implement curl?

          I am not saying that you are wrong - not a C fan, nor against Rust, quite the opposite actually - but wonder what you base your assumptions on.

          1. 3

            I’d also add that there is deep & widespread misunderstanding of the OpenBSD philosophy by the wider developer community, who are significantly influenced by the GNU philosophy (and other philosophies cousin to it). I have noticed this presenting acutely around the role of C in OpenBSD since Rust became a common topic of discussion.

            C, the existing software written in C, and the value of that existing software continuing to be joined by new software also written in C, all have an important relationship to the Unix and BSD philosophies (most dramatically the OpenBSD philosophy), not merely “because security”.

            C is thus more dramatically connected to OpenBSD than projects philosophically related to the “GNU is Not Unix” philosophy. Discussions narrowly around the subject of C and Rust as they relate to security are perfectly reasonable (and productive), but OpenBSD folks are unlikely to participate in those discussions to disabuse non-OpenBSD users of their notions about OpenBSD.

            I’ve specifically commented about this subject and related concepts on the orange site, but have learned the lesson presumably already learned many times over by beards grayer than my own: anyone with legitimate curiosity should watch or read their own words to learn what OpenBSD folks care about. Once you grok it, you will see that looking to that source (not my interpretation of it) is itself a fundamental part of the philosophy.

            1. 1

              If that weren’t true, then it would mean that OpenBSD guys security skill is below average, which I don’t think is true.

              At least not far above average. And why not? They’re mostly amateurs, and their bugs don’t cost them money.

              And Joe just wants to write an application with some features, he doesn’t focus on security that much.

              I think you’re making a straw man. OpenBSD people aren’t going to make fewer bugs using any language other than C, and comparing Average Joe to any Expert just feels sillier and sillier.

              1. 3

                What’s your source for the assertion ‘They’re mostly amateurs’?

                1. 2

                  What a weird question.

                  Most openbsd contributors aren’t paid to contribute.

                  1. 3

                    What a weird answer. Would you also argue that attorneys who accept pro bono work are amateurs because they’re not paid for that specific work?

                    Most of the regular OpenBSD contributors are paid to program computers.

                    1. 1

                      because they’re not paid for that specific work?

                      Yes. In part because they’re not paid for that specific work, I refuse to accept dark_grimoire’s insistence that “if they can’t do it nobody can”.

                    2. 1

                      You seem to be using the word “amateur” with multiple meanings. It can mean someone not paid to do something, aka “not a professional”. But when I use it in day to day conversation I mean something more similar to “hobbyist”, which does not tell much about ability. Also saying they are amateurs, thus do not write “professional” code, implies anyone can just submit whatever patch they want and it will be accepted, which is very far from the truth. I assume with reasonable certainty that you never contributed to OpenBSD yourself, to say that. I am not a contributor, but whenever I look at the source code, it looks better than much of what I saw in “professional” work. This may be due to the focus on doing simple things, and also very good reviews by maintainers. And as you said, the risk of loosing money may be a driver for improvement, but it is certainly not the only one (and not at all for some people).

                      1. 1

                        You seem to be using the word “amateur” with multiple meanings,

                        I’m not.

                        as you said, the risk of loosing money may be a driver for improvement, but it is certainly not the only one

                        So you do understand what I meant.

                2. -1

                  nailed it

            2. 7

              This seems to assume that all of cURL can be reimplemented without the use of unsafe.

              Maybe it can, I don’t know, but I know other web-related Rust projects have had memory bugs/CVEs.

              1. 4

                Since cURL doesn’t have much need to touch raw memory or external API’s beyond what the standard library provides, I think it’s safe to assume that it shouldn’t need to use unsafe. Any time that it does would be for a performance tradeoff.

                1. 1

                  I would imagine that it could. Rust without unsafe is pretty limited, in that the only data structure that it supports is a tree, but that is pretty much all that you need for most parsers and most of the dangerous code (i.e. the code that interacts with untrusted data) in cURL is parsing protocol messages.

                  1. 3

                    …the only data structure that it supports is a tree…

                    Technically true, if you consider records, sequences and such to be special cases of trees, but not terribly useful. You can make anything out of a tree after all. More precise to say that safe rust only supports non-cyclic data structures.

                    1. 1

                      No, safe rust doesn’t support arbitrary DAGs. An arbitrary DAG allows shapes where one node has two pointers to it from places higher up. This requires aliasing, which requires unsafe in Rust. The most common way of doing this in Rust is via the RC crate, which can be implemented in Rust only with unsafe code.

                2. 5

                  For example this great study shows that using Typescript would have prevented approximately 15% of all bugs that you find in typical Javascript code. It’s hard to argue against static types with evidence like that.

                  And yet, there is no shortage of contrarian people who will pop up to do just that :-)

                  1. 8

                    *waves*

                      1. 4

                        The OP is talking about a paper not in that set: https://web.archive.org/web/20191014123107/http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/type_study.pdf

                        @yawaramin has been teasing me for a while because I keep meaning to do a serious analysis of the Typescript paper but never get around to it

                        1. 3

                          But that post does illustrate a meta point: mere existence of a paper is not a strong evidence, sadly.

                          1. 3

                            Of course, the existence of the paper doesn’t prove anything, you need to actually read the paper and judge whether it’s doing a good job.

                      2. 5

                        On the Impact of Programming Languages on Code Quality

                        “This paper is a reproduction of work by Ray et al. which claimed to have uncovered a statistically significant association between eleven programming languages and software defects in projects hosted on GitHub. … We uncover a number of flaws that undermine the conclusions of the original study as only four languages are found to have a statistically significant association with defects, and even for those the effect size is exceedingly small.”

                        1. 2

                          What matters for a business is to create a product, as fast as possible, that people use.

                          Certainly shipping bugs is counter-productive but is not the only metric. What you have to demonstrate is that it would have taken less time to get to a stable point using TypeScript than JavaScript. If it takes 2x longer to write code because of the extra type annotations and slower tooling, it might not offset the extra time that a JavaScript developer would have taken fixing those 15% extra bugs.

                          The 2x number is pulled out of thin air and I’m not saying that JavaScript is superior. In my experience, the number of bugs is not linear to the size of the codebase and dynamically-typed language tends to hit a plateau where it becomes an unmanageable mess more quickly than statically-typed languages. Another metric is that teams that are familiar with a given language are more productive in it, even if it has a lot of quirks.

                          Just saying that language choices is a complicated topic :)

                          1. 1

                            Language choices are indeed complicated topics, especially that even the “rule of thumb” you provided as the first sentence is not true in every circumstance. I agree that most startups and many larger businesses value releasing an MVP as fast as possible, but I worked for at least a couple of projects where correctness and code quality was highly valued, even more so than release speed. A simple example I might give is the hard medical sector where life is at stake.

                            Does it mean that Rust is a perfect choice for those kinds of projects? No. There are certain standards that must be met. Some of the standards actually specify which languages are allowed or force you to use certain coding guidelines, avoid problematic parts of languages etc.

                        2. 5

                          See: project everest, a project to make a formally verified TLS stack.

                          1. 4

                            Also of note, no rust in sight! Rust is fine, but it’s definitely not the end-all-be-all of secure languages.