1. 1

    The nice thing about monospace fonts is that they make it easier to align code; doing so improves readability. Spaces are for alignment, not indentation. It’s also why I like the gofumpt code formatter for Go: it does everything that gofmt does, but also adds in some vertical alignment for keys/values when assigning variables across multiple lines.

    1. 2

      Yeah if you like to align things inside a line then this approach (and most formatters) isn’t going to work well for you. Although you could in theory still use a proportional font, you’d just need the editor to typeset the alignment for you. In practice that seems impractical.

      1. 1

        The longer I’ve been coding the longer I actually have the desire to align things. There are a few cases where it can improve readability (make it easy to comoare similar adjacent lines) but usually I find that one of the following downsides is more important:

        1. Abstracting the similar lines in a more robust way.
        2. Avoiding noiser diffs which you change the “longest” line.

        There are definitely still some cases where aligning is the right thing to do but it is rare enough that I didn’t miss it much. (And if the lines are truely that similar they often align anyeays as long as your have fixed-width digits which I do definitely recommend)

      1. 12

        I’ll take the unpopular side and say that I appreciate good typography on a website, and am happy to pay the bandwidth costs to get something that is a pleasure to read. The only thing I don’t like is getting a bunch of trackers as well, so I prefer if sites serve their own fonts directly, though I understand that is a bit of an ask for non-tech-savvy folk.

        I liked how the author redesigned the various types of quotes and pull-outs to be more uniform. However, I think they’re a bit too minimal. If I were to do it, I’d doing something more to tell the different types apart instead of only the different icons at the top.

        1. 2

          If you have a preferred font, you can change your browser’s default serif/sans-serif/monospace fonts to make every site’s default fonts respect your typographic preferences and save your bandwidth (along with the bandwidth of all the viewers of your website). I find this to be a much better practice than forcing my typographic preferences upon everyone.

          I wrote about this in more detail on my own site: An opinionated list of best practices for textual websites.

        1. 5

          I am a big fan of coverage, but feel that a lot of the debate around the practice largely misses the point(s). So, while I agree that complete or high coverage does not automatically mean that a test suite or the software is good… of course it doesn’t? In the extreme, it’s pretty trivial to reach 100% coverage without testing the actual behaviour at all.

          Coverage is useful for other reasons, for example the one this article ends with:

          Our results suggest that coverage, while useful for identifying under-tested parts of a program, should not be used as a quality target because it is not a good indicator of test suite effectiveness.

          Identifying under-tested parts of a program seems like a pretty important part of a testing strategy to me. Like many advantages of coverage, though, you have to have pretty high coverage for it to be useful. There are other “flavours” of this advantage that I find useful all the time, most obviously dead code elimination. High test coverage at the very least signals that the developers are putting effort into testing, and checking that their testing is actually hitting important pieces of the code. Maybe their test suite is in fact nearly useless, but that seems pretty unlikely, and it could be nearly useless without coverage, too. That said, like any metric, it can be gamed, and pursuing the metric itself can easily go wrong. Test coverage is a means to many useful ends, not an end unto itself.

          The quest for 100% may be a bit of a wank, but I’ve tried that in a few projects before and actually found it quite useful. In particular it highlights issues with code changes that affect the coverage of the test suite in a very simple way. Day-to-day, this means that you don’t need to meticulously pour over the test suite every time any change is made to make sure that some dead code or dead/redundant branches weren’t added. If you don’t have total coverage, doing that is a chore. If you do, it’s trivial: “oh, the number is not 100% anymore, I should look into why”. I regularly end up significantly improving the code during this process. It’s undeniably a lot of work to get there (depending on the sort of project), but once you do, there are a lot of efficiency benefits to be had. If the project has platform-specific or -dependant aspects, then this is even more useful in conjunction with a decent CI system.

          As to the article itself, the methodology here seems rather… convenient to me:

          • Programs are mutated by replacing a conditional operator with a different one. This mutation does not affect coverage (except perhaps branch coverage, in exactly one case, if you’re replacing > with >= as they are here). It also hardly seems like a common case.

          • The effectiveness of the test suite as a whole is determined by running random subsets of the tests and seeing if they catch the bug. This is absurd. Test suites are called test suites for a reason. The instant you remove arbitrary tests, you are no longer evaluating the effectiveness of the test suite, full stop. You are - obviously - evaluating the effectiveness of a random subset of the test suite. Who cares about that?

          Am I missing something? In short, given this methodology, the only things these results seem to say to me is: “running a random subset of a test suite is not a reliable way to detect random mutations that change one conditional operator to another”. I don’t think this is at all an indicator of overall test suite effectiveness.

          That said, I have not read the actual paper (paywall), and am assuming that the summary in the article is accurate.

          1. 4

            I also find coverage extremely valuable for finding dead or unreachable code.

            I frequently find that unreachable code should be unreachable, e.g. error-handling for a function that doesn’t error when provided with certain inputs; this unreachable-by-design error handling should be replaced with panics since reaching them implies a critical bug. Doing so combines well with fuzz-testing.

            It’s also useful for discovering properties of inputs. Say I run a function isOdd that never returns true and thus never allows a certain branch to be covered. I therefore know that somehow all inputs are even; I can then investigate why this is and perhaps learn more about the algorithms or validation the program uses.

            In other words, good coverage helps me design better programs; it’s not just a bug-finding tool.

            This only holds true if I have a plethora of test cases (esp if I employ something like property testing) and if tests lean a little towards integration on the (contrived) “unit -> integration” test spectrum. I.e. only test user-facing parts and see what gets covered, and see how much code gets covered for each user-facing component.

            1. 1

              This matches my experience very well. Good point that the sort of test suite is relevant here. I get the impression that the article is coming from more of a purist unit-testing perspective, but this dead code elimination thing is mostly useful when you have a pretty integrated test suite (I agree that this axis is largely contrived).

              I find it particularly nice for non-user-facing things with well-defined inputs and outputs like parsers, servers, and so on. If you have a test suite that mostly does the thing the software actually has to do (e.g. read this file with these options and output this file), in my experience, coverage exposes dead code a lot more often than you expect.

              This has the interesting side-effect that unit tests which only exist to cover internal code are actually harmful in a way, because something useless will still be covered.

              1. 1

                I find it particularly nice for non-user-facing things with well-defined inputs and outputs like parsers, servers, and so on. If you have a test suite that mostly does the thing the software actually has to do (e.g. read this file with these options and output this file), in my experience, coverage exposes dead code a lot more often than you expect.

                I think it’s just fine, as long as it’s possible to turn them off and just run the subset of tests for public functions or user-facing code. I typically have a portable Makefile that includes make test-cov, make test, and make test-quick; if applicable, only make test needs to touch all test files.

            2. 2

              I have not read the actual paper (paywall)

              The PDF is on the linked ACM site: https://dl.acm.org/doi/pdf/10.1145/2568225.2568271 – I think you must have misinterpreted something or took a wrong turn somewhere(?)

              Otherwise there is always that certain site run by a certain Kazakhstani :-)

              1. 1

                Paywalled in the typical ACM fashion as far as I can tell?

                That said, sure, there are… ways (and someone’s found an author copy on the open web now). I’m just lazy :)

                1. 1

                  Skimmed the paper. It seems the methodology summary in the article is accurate, and I stand by my critique of it. To be fair, doing studies like this is incredibly hard, but I don’t think the suggested conclusions follow from the data. The constructed “suites” are essentially synthetic, and so don’t really say anything about how useful of a quality metric or target coverage is in a real-world project.

                  1. 1

                    Huh, I can just access it. I don’t know, ACM is weird at times; for a while they blocked my IP because it was “infiltrated by Sci-Hub” 🤷 Don’t ask me what that means exactly, quoting their support department.

                    1. 1

                      Hm. Out of curiosity, do you have a lingering academic account, or are you accessing it via some institution’s network? I know I was surprised and dismayed when my magical “free” access to all papers got taken away :)

                      1. 1

                        I only barely finished high school, and that was a long time ago. So no 🙃

                        Maybe they’re providing free access to some developing countries (Indonesia in my case), or they just haven’t fully understood carrier grade NAT (my IP address is shared by hundreds or thousands of people, as is common in many countries). Or maybe both. Or maybe it’s one of those “free access to the first n articles, paywall afterwards” things? I don’t store cookies by default (only whitelisted sites), so that could play a factor too.

                2. 1

                  Identifying under-tested parts of a program seems like a pretty important part of a testing strategy to me.

                  My interpretation is that test coverage reports can be useful if you look at them in detail to identify specific areas in the code where you thought you were testing it but you were wrong.

                  But test coverage reports are completely useless if you just look at a percentage number on its own and say “the tests for project X are better than project Y because their number is higher”. We have a codebase at work with the coverage number around 80%, and having looked at it in detail, I can tell you that we could raise that number to 90% and get absolutely no actual benefit from it.

                1. 12

                  As someone who hosts websites, one of which is connected to my actual identity, on VPSes: the best DDoS protection for low- to mid-effort attacks is performance. On a VPS hosting a static site and a few lightweight daemons, I take the following measures:

                  • I use TLS with 0-RTT enabled and ECDSA certs combined with OCSP Must-Staple
                  • I enable TCP_FASTOPEN in both the kernel and my Nginx build
                  • Since I’m not running any untrusted code (all the daemons running are either default system packages or programs I built myself), I disable Spectre/Meltdown mitigations for a perf boost.
                  • (overkill) I channeled the learnings from my Gentoo days of yore to build a statically-linked Nginx from source along with with mimalloc, OpenSSL, PCRE, zlib-ng, and musl (with mimalloc it wasn’t noticeably slower) using gcc optimizations (-march, -flto if it worked, and several others).
                  • Kept page weight extremely light (<40kb without next-gen image formats, home page <5kb).

                  All of the above steps managed to nearly double the req/sec my server was able to handle to several thousand; at that point, I’m pretty sure the benchmark was benchmarking itself.

                  If you notice a DDoS, try enabling Fail2Ban with a rule for rapidly-repeating requests. Enabling Fail2Ban with such a rule for a couple months combined with Nginx’s built-in DDoS mitigation has helped my servers weather a couple attacks so far.

                  Recommended readings:

                  Performance tuning outside application-level improvements is one hell of a rabbit hole.

                  1. 2

                    Just wanted to add that I’ve since revised my stance on disabling Spectre/Meltdown mitigations; if you’re using an affected processor, you should leave then enabled unless you’re benchmarking or using a disposable VM.

                  1. 2

                    I decided to actually implement the ideas from a blog post I wrote and shared here a few months ago.

                    Feedback is quite welcome; I hope to release v1.0.0 less than a day from now. This repository contains a Go library as well as a pair of CLI executables for measuring password strength and generating passwords. Unlike existing solutions I’m aware of, MOAC uses physical limits to computation to analyze password strength.

                    In addition to specifying/measuring length, charsets, and/or entropy, users can also work with physical values (mass, energy, etc); MOAC determines what the most powerful brute-force attack that the laws of physics can allow would look like to determine how strong a password is.

                    The difference between a password crackable in 1000 years and 1e8 years is hard to comprehend while the difference between requiring the mass-energy of a mountain and the mass-energy of a planet is much more apparent. Large masses are easier to visualize than long durations.

                    1. 1

                      Personally, I dislike most language servers; I find them to be slow and heavy, just like most IDEs.

                      There are notable exceptions. gopls and rust-analyzer tend to have decent performance.

                      Tree-Sitter support is great, and so is the improved Lua functionality. I’ve moved some of my init.vim to lua files, and might eventually go 100% lua. Lua is the first language I really cut my teeth on (I worked on some Minetest mods) so it has a special place in my heart.

                      1. 1

                        Can someone tell me more about what tree-sitter does? I have it enabled but still not sure about the breadth of its functionality.

                        From what I understand it can parse source code into syntax trees which help with things like syntax highlighting. Does it do more than this?

                        1. 2

                          It can also provide text objects and symbols which other tools can use.

                          1. 1

                            Once you have syntax trees you can do a ton of things like accurate text-objects (ast-objects?), indentation, folding… Most of the things that are currently done with regexes that can fail could be done with a tree-sitter that wouldn’t.

                            1. 1

                              Makes sense. Thanks a lot.

                              Also the linked article has well written info about tree-sitter. I should have checked it before asking.

                        1. 3

                          I only end up finding features in tmux by fat fingering features I was attempting to use; it’s not very discoverable.

                          1. 4
                            • Tmux supports right-click if built with mouse-support. The resulting menu exposes the most important functions.
                            • <Prefix>+? opens a list of all current keybindings
                            • Tmux has extensive documentation
                            • Patches are always welcome
                          1. 10

                            Requested follow-up: “Why people with anime profile pictures make excellent hackers”, esp. surrounding video conversion/encoding/decoding/filtering.

                            1. 5

                              I don’t think the comparison works, for a slightly non-obvious reason: The anime community is significantly less participatory than furry is.

                              While there are undoubtedly some excellent people to be found in the anime community, there’s a pronounced producer-vs-consumer dichotomy that’s far more blurred in the furry community. How many anime fans know Japanese and {translate manga chapters, subtitle anime videos} for their friends to read, compared to the sum total of all anime fans? (Now consider that having an anime avatar isn’t necessarily the same as being a bona fide anime fan.)

                              Although there are common elements, every fursona is fundamentally unique to the person. Additionally, most (not all; there are adoptables) furries create their own fursona. There is no established, central canon in furry. It’s very decentralized; you could say we’re a fandom unto ourselves.

                              Above, @friendlysock remarked on the correlation of neurodiversity with technical participation and LGBTQ+ identities. Furries are predominantly LGBTQ+ (and, at least in my case, grew up in a very gay-unfriendly environment; computer security and online privacy was literally a survival strategy for most of my young adult life).

                              It’s for a combination of the reasons I’ve stated above that I suspect the comparison you provided won’t generally hold. But, of course, there will be individual data points that do, and the Internet is better off for them existing. :)

                              1. 6

                                I don’t think the comparison works, for a slightly non-obvious reason: The anime community is significantly less participatory than furry is.

                                This seems like a bit of a trivial difference. At its core this is about how various personality traits, career/activity choices, interests, and such correlate and interact (if at all). How exactly these traits are expressed doesn’t strike me as all that important for the purpose of this discussion.

                                1. 2

                                  How many anime fans know Japanese and {translate manga chapters, subtitle anime videos} for their friends to read

                                  I have many friends in anime communities of sorts, many of them are programmers and many of those who are programmers also know japanese to varying degrees and have translated things or otherwise helped to produce fansubs for anime, scanlations (i.e. manga translations), light novel, visual novel or game translations, or produced fanart of anime and other anime-related things. I used to work on fansubs and scanlations myself. Many also worked on websites and other sorts of software aimed at the anime community.

                                  A lot of anime fans are also not neurotypical and were drawn to computers and anime because of their neurodiversity, so I don’t think there’s much of a difference there. I see your point about LGBTQ+-unfriendly environments and computer security though, and it’s not something that could be said for most anime fans.

                                  I think the main difference is that anime and manga and other related media have always been somewhat popular and are only increasing in popularity and social acceptance, so it’s not a tightly knit group like the furry community and it’s hard to even define what “anime community” means, much less make generalizations of it. So not all anime avatars are necessarily bona fide anime fans (definitely not on twitter) and most won’t fit my experience with anime fans.

                                  But regarding video conversion/encoding/decoding/filtering that the parent mentioned, the answer is that many of them worked on fansubs as encoders and had to get their hands dirty with ffmpeg a lot to get good quality encodes with low filesizes, or started to contribute to video player software because they were watching a lot of anime and noticed issues with the playback, or got interested in how to upscale small resolution files with filters, or reduce banding, and so on.

                              1. 5

                                If you don’t trust the source of the bash install script, why do you trust their software?

                                If you don’t trust that the bash install script isn’t getting MITM’d somehow, why do you trust that the rest of the software isn’t, too?

                                1. 1

                                  My issue is not the bash script, my issue is the security put in place to host this bash script.

                                  Usually distributions (I can only speak about Fedora/CentOS/RHEL) have tight ACLs, and review processes for new packages to be uploaded. Supply chain attacks are taken seriously. There are processes and tools in place for auditing the supply chain.

                                  Who administers https://get.tool.sh/? How do you audit that the supply chain hasn’t been tainted? Who uploads a new version? How do they upload a new version? Is there an approval process? If a version is tainted, how can people know whether they installed that version or not?

                                  Also, on an unrelated to security note, packages provide a way to track installed files, and can easily get purged. Distributions usually avoid pre-install or post-install script which creates untracked files of which the package manager is not aware. (YMMV, exceptions do occur, for example: postgresql usually creates the data directory in its post-install script)

                                  1. 1

                                    Do you audit and ensure the review process was carried out correctly for every piece of software you install?

                                    1. 1

                                      Well… I install my software from the official Fedora repos, so I assume every package was approved. I can look it up on koji.

                                      Regarding what I install outside of my package manager (golang and/or rust libraries when I develop), I develop on local VMs. The threat model is these programs reading my firefox cookies, ssh keys etc… Which they can’t since they’re sandboxed.

                                  2. 1

                                    I might trust their software, their laptop, and even their build server (if it’s not their laptop), but not their web host.

                                    1. 2

                                      So how would you detect if their web host tampered with the binary? Did you verify a signature? Did you verify a signature that you didn’t get from the same source as the binary?

                                      1. 1

                                        That’s my point, and why I’d rather get things through a distro.

                                    2. 1

                                      If you don’t trust the source of the bash install script, why do you trust their software?

                                      If you don’t trust the install script, don’t trust the software. That’s why you should read the install script first.

                                      If it’s a massive 200+ line script that’s hard to understand, I’d probably avoid the software in question if I have any choice in the matter since it’s probably doing something unspeakable to my system. If it’s just installing some files in the appropriate dirs, that’s a different story.

                                      The best way to distribute software, IMO, is a simple .tar.gz with $PREFIX subdirs laid out (bin/, share/, lib/, etc). Just extract the tarball into $PREFIX, no install scripts necessary.

                                      1. 2

                                        The best way to distribute software, IMO, is a simple .tar.gz with $PREFIX subdirs laid out (bin/, share/, lib/, etc). Just extract the tarball into $PREFIX, no install scripts necessary.

                                        This breaks down if your software needs a user, or a /var/lib/myapp owned by that user, or something else.

                                        “You could add this to the README!” And yeah, sure. But a lot of devs aren’t all that Unix-savvy as most people here are.

                                        Maybe what’s really needed is a standard way to set up this stuff, e.g.:

                                        $ setup-sw setup.json
                                        Create:
                                            User _arp242 (no login)
                                            Directory /var/lib/arp242 owned by _arp242
                                        [Y/n]?
                                        

                                        Basically an “ansible-light” with a UI specifically catered to this use case.

                                        That loads and loads of people keeping writing these scripts demonstrates there’s a use case here that’s not yet adequately solved.

                                        Actually, this could even do the download and extraction as well:

                                        $ setup-sw https://install.arp242.net/setup.json
                                        
                                        1. 1

                                          How is this different from a packaging format and package manager? I can just as easily run dnf install https://install.seirdy.one/package.rpm, for instance.

                                          Plenty of packages come with init scripts or Systemd units that create and run as users too; web servers like Nginx are popular examples.

                                          1. 1

                                            Yeah, it’s not really, except that it’s probably easier to create. I don’t have a system with dnf; I’m not even sure which distro(s) it belongs to (Fedora/RedHat/CentOS, I think?) And then there’s apt, and pacman, and xbps, and FreeBSD’s pkg, etc. etc.

                                            People like these shell scripts because they’re simple, they can test them, and when done right work more or less anywhere. It’s also low in maintenance as there aren’t 10 different packages to update and test.

                                    1. 2

                                      Is there actually a target audience for this kind of post?

                                      There are certainly people who are very concerned with the security of their machine; and whether it be “only downloading distro-packaged applications and assuming the distro already does the needed checks” or “only install software onto an air-gapped machine running openbsd in a VM unless self-compiled only from software where each file has been GPG signed by someone I’ve personally attended at least 3 weddings for”, these people generally already have security practices in place. And I strongly doubt they are unaware that “downloading random things from the Internet and giving them root access” is not always a great idea.

                                      On the flip side, we’ve got developers running lord knows what from NPM or PyPI or whathaveyou, folks who are using distro-style packages from 3rd party vendors, people installing precompiled applications distributed via Github – heck we have folks running Windows and using magical mysterious NSIS installers that don’t always even have the benefit of being open source.

                                      Going off of the assumption that these are still developers, systems administrators, or some variety of computing enthusiasts though (because, really, who else is reading Lobsters), they almost definitely already know “Hmm letting literally anything run random stuff, especially as a privileged user, may not be great.” So, again, they already know the message here.

                                      So what’s the real audience, what’s the real purpose this exists? Is this some sort of abstract art about more developers not going through the essay per distro to push their project through existing distro-based distribution channels instead? Some sort of gatekeeping from Serious Computer People to keep Not So Serious Computer People away?

                                      I really don’t get it. What’s the point here?

                                      1. 2

                                        The point is that an install script should be simple and easy to read. Users should read the install script before running it so they understand what’s going on.

                                        The essay-per-distro isn’t the only path; users can also build from source and install. A Makefile or sane build system should output a list of files being installed with sources and destinations so that users understand what’s happening on their machines.

                                        This post describes installing software blindly, allowing it to do basically anything to your computer with root privileges.

                                        Most software doesn’t need a super fancy 200+ line install script when extracting a simple .tar.gz into $PREFIX would suffice.

                                      1. 3

                                        I’m sad that people keep trying to import the worst bits of the WWW into gemini. Gemini makes it really easy to host your own server/capsule/instance, and the adopted cultural practice is to write your posts on your own site and link to others.

                                        I hope that attempts to bring centralising web services and silos to gemini fail, to be brutally honest.

                                        1. 8

                                          Gemini makes it really easy to host your own server/capsule/instance, and the adopted cultural practice is to write your posts on your own site and link to others.

                                          To be honest, most people don’t want to do that. There’s still costs and burdens associated with hosting anything, and (even federated) servers can become policy domains/communities of their own.

                                          If you truly want this, use a P2P system.

                                          1. 6

                                            The good news is that things like this usually die out pretty quickly due to lack of interest. You don’t really have to worry about it.

                                            1. 6

                                              This is basically the problem with Gemini: it does little to nothing to solve the actual problems it sets out to solve, they just seem solved because of the conventions of the currently-small user base. If it ever actually took off it would be the same as the web very fast.

                                              1. 2

                                                I’d add that the basic issue with Gemini is that it’s trying to address social problems with technical solutions.

                                                1. 2

                                                  Can you elaborate on what these actual problems are that you see Gemini trying to solve that are only solved because of a small user base? Looking at https://gemini.circumlunar.space/docs/faq.gmi, a lot of the design goal has to do with Privacy. Gemini isn’t going to magically get cookies just because lots of people start using it.

                                                  @gerikson I hear this all the time about addressing social problems with technical solutions being some sort of bad idea. What is the alternative? I’d argue that the only way (besides superhuman Mahatma Gandhi or MLK levels of persuasive power) to solve social problems is with technical solutions. Now, you can’t just focus on the technology by itself. That’s certainly a failure mode. But social problems often boil down to some technology permitting people to do too much (e.g. cookies). Restricting people from doing things we’ve come to realize have negative externalities, this usually requires a change in technology.

                                                  1. 2

                                                    Gemini is trying to work against the current widespread and profitable harvesting of online activity to target ads.

                                                    Effectively combating this requires legislation. Individual actions will do nothing to change it.

                                                    For example, we’ve had ad-blockers for a decade or more. Has online advertising gone away? No it has not. A costly arms-race between blockers and detectors has ensued instead.

                                                    Trying to defeat tracking online by offering a solution that’s much more limited than even HTML 4-era web and expecting a significant adoption is bordering on delusional.

                                                    1. 1

                                                      Trying to defeat tracking online by offering a solution that’s much more limited than even HTML 4-era web and expecting a significant adoption is bordering on delusional.

                                                      I don’t think they expect adoption - it feels more “pretend it isn’t real”.

                                                    2. 1

                                                      The three items at the top of that page are:

                                                      Tracking: Gemini may lack some of the obvious “tracking features” like 3rd party cookies, but given the sophistication of fingerprinting solutions big tracking uses at this point, that’s at most a speedbump to them going online. Privacy of Gemini users is largely safeish due to Gemini hosts being largely “good guys” at this point.

                                                      Flashy design is bad: One can deliver any content over Gemini, and as big publishers and the users who like their flashy stuff came in, the flashy content (whether HTML-over-Gemini, SWF-over-Gemini, or some new future abomination) would follow.

                                                      Bloat is bad: this is basically the same as the last point. As people put out more and more flashy stuff, the bloat they put out would also increase.

                                                      In context, my comment was also triggered by the parent post whose point was social networks / non-self-hosting is bad, which the OP is a contradiction to in the Gemini space already.

                                                      1. 4

                                                        I likely just don’t know enough about Gemini, but:

                                                        • How do you do images over Gemini?! I thought there’s no way to do it.

                                                        • If each page loads as a single resource, isn’t there just much less room for fingerprinting? Clients are also not required to cache anything. I have a hard time seeing how one domain can learn anything about another. The spec has one line of request going out and one line of response header. How could this possibly be fingerprinted?

                                                        the parent post whose point was social networks / non-self-hosting is bad, which the OP is a contradiction to in the Gemini space already.

                                                        There’s no contradiction here. You literally can’t insert a newline in Gemini. The bloody protocol spec limits how long posts on this social network can be. Talk of bloat sounds like a lot of pearl clutching and false equivalence to me.

                                                        I flagged @kline’s post as unkind. This is the worst part of www, really? No need for the mainstream to worry when we’re all so good at tearing each other down. I have criticisms of Gemini, but I don’t feel the need to bring them up when people are sharing projects.

                                                        1. 1

                                                          On how to do images: right from the FAQ you linked you can serve any content type that has MIME type over Gemini, so images should be easy.

                                                          For ad tracking you don’t need to have the client involved, anything a server can learn about the client it can relay to another server. Advertiser just has to make doing so a requirement of sellin their ads. This assuming the most rose coloured future where client side tech somehow never gets served via another MIME type for tracking purpose.

                                                          1. 2

                                                            Oh, I understand that you can serve images over Gemini. But can you embed them? I don’t believe so. Requiring images to be explicitly requested seems like a huge improvement.

                                                            You’re right that servers can just sell your information outright. Is your point that it doesn’t make sense to worry about privacy if you choose to interact with a server? That’s internally consistent but an impractically high bar, IMO.

                                                        2. 1

                                                          How would you go about fingerprinting Gemini users? Gemini has no user-agents or interactivity; clients just open a TLS connection and show the resulting contents. All you really get is an IP address. What other information can be gained?

                                                          Gemtext leaves presentation in the hands of the user agent rather than the content author; authors only dictate content with per-line semantics.

                                                          What sort of bloat are you envisioning in Gemini? One of the core ideas of Gemini is that one user action should trigger no more than one request. For example, a user must click a link to load an image (inline or in another window, depending on the client).

                                                          Finally, the best part of Gemini (imo) is the fact that it isn’t mainstream, and thus won’t be plagued by corporate interests. It’s actively hostile to corporate interests like branding (emoji favicons were recently rejected) and tracking (one-way communication, one request at a time, without any identifiers beyond an IP address or optional client cert for auth).

                                                          I invite you to try out Gemini before commenting with a blanket-statement dismissal.

                                                          1. 1

                                                            I agree that if you serve only Gemtext, over any protocol, bloat is unlikely.

                                                            Your “best part” is in full agreement with my post. So long as it never catches on Gemini can remain largely pure because only people who want the culture happen to use it. Don’t need a whole new protocol or format for people to choose to be good, though…

                                                      2. 2

                                                        It’s like “use plain text email” - it works in their tiny bubble, fails to meet reality with i.e; your clients, non-technical friends, important orgs, etc.

                                                      3. 2

                                                        I don’t think this project is trying to import anything from the Web. It’s creating it’s own thing and allowing ppl on Gemini to socialize. Or even if they are not on Gemini, to be able to participate and this IMO is the built of such projects. It can help bring more people to the protocol. IMO, for a young protocol such as Gemini, project like this can really help spread the word and I welcome them.

                                                      1. 1

                                                        Migadu lets you create virtually emails and addresses for a given domain (I say “virtually” unlimited because they claim there isn’t a limit, but they might change that if abuse occurs).

                                                        You do have to pay for Migadu email, but this is a really nice bonus.

                                                        Additionally, almost all email providers let you add a “+” to your email address: username+website@domain.tld is an automatic alias for username@domain.tld.

                                                        1. 1

                                                          I’m not sure I understand. There’s basically two issues here - making sure that your origin (and scripts loaded by it) is unable to call FLoC APIs, and opting your website out of being used as input to browser cohort calculations. This article seems to be mainly about the former, and how there are better solutions than setting a header - although it does not really make it clear which part is about which - but the posts I’ve seen giving this advice so far (and IIUC, the original linked blog post falls into this category) have been mostly about the latter. The idea being that by opting your website out, you’re helping to make FLoC’s cohort calculations less effective and therefore less useful. What exactly is the misinformation being combatted here and/or what am I missing?

                                                          It’s very late here so there’s definitely a strong chance that I’m just overlooking something obvious.

                                                          1. 1

                                                            This article seems to be mainly about the former,

                                                            Sorry, the initial version of the article kinda glossed over that. I’ve updated it a few times since with more information. The “What explicitly opting out actually entails” section covers the latter concern. The “This has happened before” section might also be relevant.

                                                            Thanks for the feedback.

                                                          1. 3

                                                            You don’t need to add this permission policy to every request, just as you don’t need to wear a helmet for every form of physical activity.

                                                            I disagree. If a helmet were as light as air, I would wear a helmet all the time, and tell others to do so.

                                                            1. 9

                                                              Perhaps a “broken helmet” would be a better analogy, since adding this header won’t necessarily help. I don’t think we should legitimize the need to add a half-baked work-around whenever Google does exactly what we expect it to do; it shifts burden and blame away from Google and towards webmasters.

                                                              1. 3

                                                                There are kinds of physical activity where a helmet makes the wearer less safe, especially when the risk of getting snagged and choking is higher than the risk of traumatic head impact. This is why every children’s playground has large “no helmets” signs.

                                                                1. 4

                                                                  Metaphor is metaphor. Your point is granted but seems irrelevant to Permission-Policy header.

                                                                  1. 2

                                                                    This is why every children’s playground has large “no helmets” signs.

                                                                    Wait, what? Is this an American thing? I can’t imagine an Australian parent even considering putting their kids in helmets for a playground. Hell, our seven and nine year old boys play unsupervised in the playground over the road.

                                                                    1. 4

                                                                      I’ve always assumed the fear was kid arriving by bicycle (helmets required by law) and running to play without removing helmets.

                                                                      1. 1

                                                                        Ah okay, that makes sense.

                                                                        I’ve always wondered about compulsory safety equipment laws. As a motorcyclist, I subscribe to the “all the gear, all the time” mentality - albeit with different kit for road and track use.

                                                                        But if someone wants to ride without a helmet, well, … as Scott Adams said, “I say it’s a free country and you should be able to kill yourself at any rate you choose, as long as your cold dead body is not blocking my driveway in the morning.”

                                                                        I guess you could make a utilitarian argument for it in the case of a socialist medical system, because of the cost of caring for the injured. But then I wonder which would be cheaper, an elaborately injured motorcyclist, or one who’s dead because they didn’t wear a helmet.

                                                                        1. 2

                                                                          Fully agree. Laws should proctect people from each other, not themselves.

                                                                          We’ve managed to lobby to avoid cycling helmet laws for adults so far in my area, but they’ve been required for minors for decades. Which seems extra dumb, because the kid can just take their helmet off and what, you’re going to ticket them? A 9-year-old? No, the law is just unenforced mostly.

                                                                1. 1

                                                                  The Indieweb helps with this. With the Indieweb:

                                                                  • Users post content to their own websites. This includes responses to other websites.
                                                                  • A webmention gets (automatically or manually) sent to the parent website of a reply; the parent website can then display a “comment” with a link to the response.
                                                                  • Alternatively: the user publishes on their own site but syndicates elsewhere, using something like https://brid.gy to automate the process.

                                                                  With this system, users own their own content on their own websites without trusting silos to host content for them.

                                                                  This is a very incomplete solution: expecting everyone to run their own website and go through the onboarding process for the Indieweb is laughably unrealistic, and having one place (centralized or decentralized) to see multiple people’s reactions is useful. It is only a solution for a subset of people and use-cases.

                                                                  Also worth noting: most websites with regularly-updating content (blogs, Twitter, even YouTube) have RSS feeds; full-text feeds can be another great way to preserve content.

                                                                  1. 2

                                                                    I’m late, but I wanted to say that I love Edbrowse. Just as vim-like browsing addons gave me Vim-keybinding muscle memory before I even set (Neo)Vim as my $EDITOR, Edbrowse has been teaching me line-based editing before I even started using /bin/ed.

                                                                    It’s a very different way to browse. Although it won’t replace “normal” browsers for me, I do reach for it frequently. Just as writing a “full” program can be overkill when a shell script would work, pulling up a browser automation framework like Selenium might be overkill when all you need is Edbrowse.

                                                                    1. 6

                                                                      What I like about services like these is that if you were to migrate from srht.site to a dedicated server (e.g. self-hosting or using a VPS), you’d just have to change the deploy line. There’s no vendor lock-in or special tooling; the only “special” tooling is acurl, which isn’t really that special since it behaves like a curl wrapper with a client secret, syntax and all.

                                                                      1. 3

                                                                        There’s no vendor lock-in or special tooling

                                                                        If you’re talking about GitHub or GitLab pages: a git repo isn’t really special tooling. You’re an rsync --exclude .git away from migrating to your own server. I can’t think of examples where migration would be hard for any arbitrary HTML hosting service (except blogging platforms maybe?)

                                                                        1. 2

                                                                          In this case, I was curious about using builds.sr.ht and setting up my blog this way was just an excuse to do it.

                                                                          I actually removed my previous deploy routine from my Makefile for this. It wasn’t very complicated:

                                                                          upload:
                                                                                  @rsync -avz --delete public/ root@monotux.tech:/srv/monotux.tech/
                                                                          
                                                                          deploy: build upload
                                                                          
                                                                        1. 13

                                                                          There were some… colorful comments in the post when I read it. I’m sure there’s a better source for this than a page that also publishes transphobic comments and is filled with /g/-tier comments.

                                                                          1. 5

                                                                            My initial reaction to your comment was that LinuxReviews is a wiki that anyone can edit, so it might just be a single bad actor. A closer look revealed the author of that article to be one of the main authors of the site, and a staff member to boot. I also see a similar pattern in the comments. Yeah, things aren’t looking good.

                                                                            /me sighs. Guess I’ll keep my LR account for correcting errors/misinformation on popular posts but otherwise keep some distance.

                                                                            1. 4

                                                                              There’s also blatantly nationalistic hostility in the post itself, claiming that American’s don’t understand “face” or trustworthiness.

                                                                          1. 15

                                                                            (Comment mirrored from one I made under the post itself)

                                                                            Whether or not the server-side code is visible isn’t very important. There are two reasons why:

                                                                            1. (Anti-Signal) Signal is a closed platform; users can’t self-host a Signal server and expect to be able to talk to other Signal users. Users must accept whatever code the server runs, no modifications. This is an example of the difference between “free software” and “open-source”; this type of SaaS is open-source but not necessarily free.

                                                                            2. (Pro-Signal) All three Signal apps (at the time of writing this comment) use E2EE with minimal metadata leakage. The server is unaware of the contents of the messages and cannot connect a sender to a recipient. As long as the apps don’t get an update that changes this situation, users don’t need to trust a Signal server to protect their privacy.

                                                                            I wrote about the first reason in a bit more detail in a blog post. The follow-up article was posted here a bit over a week ago.

                                                                            1. 5

                                                                              Very good points. A lot of open-source software can hardly be described as free, in any greater sense of the word. For example, is the Firefox user really free? In practice, is he not just as subject to the will of Mozilla as a Chrome user is to the will of Google?

                                                                              1. 3

                                                                                As long as the apps don’t get an update that changes this situation

                                                                                How would users verify this, exactly? Refuse all updates? Inspect on-wire behavior of new versions somehow (seems dicey)? Is there some easier way?

                                                                                1. 2

                                                                                  Summarizing from the follow-up:

                                                                                  The easier way is to use an open platform/protocol and let users choose from many clients and server {implementations, providers}. These will all have to remain compatible with each other, ensuring some degree of stability. Simplicity of protocols and implementations can reduce the need to constantly push and keep up with updates. If an app gets a “bad” update, users can switch instead of being forced to accept it.

                                                                                  Having to get many implementations to agree on a compatible protocol slows down disruptive featuritis and discourages the “move fast and break things” mentality pervasive in Silicon Valley. Rather than constantly piling on new feature additions/removals, developers will be incentivised to prioritize stability, security, and bugfixes. Those updates are easier to keep track of.

                                                                                  1. 3

                                                                                    I just spent 20 minutes trying to make sense of your comment and I have trouble connecting the dots. What are these 3 apps that Signal has? Are they all by Whisper Systems? I didn’t see any others mentioned on Wikipedia. If so, can’t WhisperSystems coordinate releases to provide the illusion of stability while guarantees erode under the hood? I don’t understand why arguments about an open protocol with many clients and servers matter when they don’t apply to Signal.

                                                                                    1. 1

                                                                                      Perhaps Android, iOS, and Desktop (Web)? Not the OP, just speculating based on how I read the comments.

                                                                                      1. 2

                                                                                        Yeah, that’s my assumption as well. In which case you can’t really think of the clients as independent. And so there’s no way to justify a closed-source end-to-end encrypted messaging app. There’s just no way to provide the desired guarantees without access to the sources, and without making it possible to verify that the sources correspond to what’s running on the server.

                                                                                2. 1

                                                                                  This is an example of the difference between “free software” and “open-source”; this type of SaaS is open-source but not necessarily free.

                                                                                  I’m very familiar with both the OSD and FSD and am thoroughly confused by this comment. Can you explain what you mean, or what difference you’re pointing out?

                                                                                1. 21

                                                                                  This mindset of replacing a language to remove a class of errors is naive at best.

                                                                                  I hate null with a passion and I do think Rust memory safety is a valuable feature. But lets take the biggest problem of that class as an example, the heartbleed bug. If you look at the vulnerability code, it is a very basic mistake. If you took an introductory course in C, you would learn how not to do that.

                                                                                  To argue that it was just a matter of using a language that doesn’t allow for that kind of error is the solution is to defend an impossible solution. Without doubting the good intentions of whomever wrote that piece of code, let us call a spade a spade, it was objectively poor code with basic flaws.

                                                                                  You don’t solve bad engineering by throwing a hack at it such as changing the language. It will manifest itself in the form of other classes of bugs and there is no evidence whatsoever that the outcome isn’t actually worse than the problem one is trying to fix.

                                                                                  Java doesn’t allow one to reference data by its memory address, precisely to avoid this whole class of problems, why isn’t everyone raving about how that magically solved all problems? The answer is: because it obviously didn’t.

                                                                                  I love curl and use it intensively, but this post goes down that whole mindset. Running scripts to find bugs and so on.

                                                                                  1. 67

                                                                                    I’m not convinced by this argument. Large C and C++ projects seem to always have loads of memory vulns. Either they’re not caused by bad programming or bad programming is inevitable.

                                                                                    I think the core question of whether memory unsafe languages result in more vulnerable code can probably be answered with data. The only review I’m aware of is this fairly short one by a Rust contributor, but there are probably others: https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/

                                                                                    1. 17

                                                                                      Good article, the writer sums it up brilliant:

                                                                                      Until you have the evidence, don’t bother with hypothetical notions that someone can write 10 million lines of C without ubiquitious memory-unsafety vulnerabilities – it’s just Flat Earth Theory for software engineers.

                                                                                      1. 14

                                                                                        There should be a corollary: until you have the evidence, don’t bother with hypothetical notions that rewriting 10 million lines of C in another language would fix more bugs than it introduces.

                                                                                        1. 9

                                                                                          Agreed. But nuance is deserved on “both sides” of the argument.

                                                                                          It’s fair to say that rewriting 10 million lines of C in a memory safe language will, in fact, fix more memory bugs than it introduces (because it fix them all and wont introduce any).

                                                                                          It’s also fair to acknowledge that memory bugs are not the only security bugs and that security bugs aren’t the only important bugs.

                                                                                          It’s not fair to say that it’s literally impossible for a C program to ever be totally secure.

                                                                                          My tentative conclusion is this: If your C program is not nominally related to security, itself, then it very likely will become more secure by rewriting in Rust/Zig/Go/whatever. In other words, if there are no crypto or security algorithms implemented in your project, then the only real source of security issues is from C, itself (or your dependencies, of course).

                                                                                          If you C program is related to security in purpose, as in sudo, a crypto library, password manager, etc, then the answer is a lot less clear. Many venerable C projects have the advantage of time- they’ve been around forever and have lots of battle testing. It’s likely that if they stay stable and don’t have a lot of code churn that they wont introduce many new security bugs over time.

                                                                                          1. 1

                                                                                            if there are no crypto or security algorithms implemented in your project, then the only real source of security issues is from C, itself

                                                                                            I don’t think this is true. All sorts of programs accept untrusted input, not just crypto or security projects, and almost any code that handles untrusted input will have all sorts of opportunities to be unsafe, regardless of implementation language.

                                                                                            1. 1

                                                                                              Theoretically yes. But, in practice, if you’re not just passing a user-provided query string into your database, it’s much, MUCH, harder for bad input to pose a security threat. What’s the worst they can do- type such a long string that you OOM? I can be pretty confident that no matter what they type, it’s not going to start writing to arbitrary parts of my process’s memory.

                                                                                              1. 1

                                                                                                It’s not just databases, tho, it’s any templating or code generation that uses untrusted input.

                                                                                                Do you generate printf format strings, filesystem paths, URLs, HTML, db queries, shell commands, markdown, yaml, config files, etc? If so, you can have escaping issues.

                                                                                                And then there are problems specific to memory unsafety: buffer overturns let you write arbitrary instructions to process memory, etc.

                                                                                                1. 1

                                                                                                  Did you forget that my original comment was specifically claiming that you should not use C because of buffer overruns? So that’s not a counter-point to my comment at all- it’s an argument for it.

                                                                                                  My overall assertion was that if you’re writing a program in C, it will almost definitely become more secure if you rewrote it in a memory-safe language, with the exception of programs that are about security things- those programs might already have hard-won wisdom that you’d be giving up in a rewrite, so the trade-off is less clear.

                                                                                                  I made a remark that if your C program doesn’t, itself, do “security stuff”, that the only security issues will be from the choice of C. That’s not really correct, as you pointed out- you can surely do something very stupid like passing a user-provided query right to your database, or connect to a user-provided URL, or whatever.

                                                                                                  But if that’s the bar we’re setting, then that program definitely has no business being written in C (really at all, but still). There’s certainly no way it’s going to become less secure with a rewrite in a memory-safe language.

                                                                                    2. 63

                                                                                      Your argument is essentially a form of “victim shaming” where we slap the programmers and tell them to be better and more careful engineers next time.

                                                                                      It is an escapism that stiffles progress by conveniently opting to blame the person making the mistake, rather than the surrounding tools and environment that either enabled, or failed to prevent the error.

                                                                                      It can be applied to all sorts of other contexts including things such as car safety. You could stop making cars safer and just blame the drivers for not paying more attention, going too fast, drink driving, etc…

                                                                                      If we can improve our tools of the trade to reduce or - better yet - eliminate the possibility of mistakes and errors we should do it. If it takes another whole language to do it then so be it.

                                                                                      That’s similar to a car manufacturer using a different engine or chassis because somehow it reduces the accidents because of the properties that it has.

                                                                                      The way we can make that progress is exactly by blaming our “tools” as the “mistake enablers”. Not the person using the tools. Usually they’ve done their best in good faith to avoid a mistake. If they have still made one, that’s an opportunity for improvement of our tools.

                                                                                      1. 38

                                                                                        Your argument is essentially “you can’t prevent bad engineering or silly programmer errors with technical means; this is a human problem that should be fixed at the human level”. I think this is the wrong way to look at it.

                                                                                        I think it’s all about the programmer’s mental bandwidth; humans are wonderful, intricate, and beautiful biological machines. But in spite of this we’re also pretty flawed and error-prone. Ask someone to do the exact same non-trivial thing every Wednesday afternoon for a year and chances are a large amount of them will fail at least once to follow the instructions exactly. Usually this is okay because most things in life have fairly comfortable error margins and the consequences of failure are non-existent or very small, but for some things it’s a bit different.

                                                                                        This is why checklists are used extensively in aviation; it’s not because the pilots are dumb or inexperienced, it’s because it’s just so damn easy to forget something when dealing with these complex systems, and the margin for error is fairly low if you’re 2km up in the sky and the consequences can be very severe.

                                                                                        C imposes fairly high mental bandwidth: there are a lot of things you need to do “the right way” or you run in to problems. I don’t think anyone is immune to forgetting something on occasion; who knows what happened with the Heartbleed thing; perhaps the programmer got distracted for a few seconds because the cat jumped on the desk, or maybe their spouse asked what they wanted for dinner tonight, or maybe they were in a bad mood that day, or maybe they … just forgot.

                                                                                        Very few people are in top form all day, every day. And if you write code every day then sooner or later you will make a mistake. Maybe it’s only once every five years, but if you’re working on something like OpenSSL the “make a silly mistake once every five years” won’t really cut it, just as it won’t for pilots.

                                                                                        The code is now finished and moves on to the reviewer(s); and the more they need to keep in mind when checking the code the more chance there is they may miss something. Reviewing code is something I already find quite hard even with “easy” languages: how can I be sure that it’s “correct”? Doing a proper review takes almost as much time as writing the code itself (or longer!) The more you need to review/check for every line of code, the bigger the chance is that you’ll miss a mistake like this.


                                                                                        I don’t think that memory safety is some sort of panacea, or that it’s a fix for sloppy programming. But it makes it frees up mental bandwidth and mistakes will be harder and their consequences less severe. It’s just one thing you don’t have to think about, and now you have more space to think about other aspects of the program (including security problems not related to memory safety).

                                                                                        @x64k mentioned PHP in another reply, and this suffers from the same problem; I’ve seen critical security fixes which consist of changing in_array($list, $item) to in_array($list, $item, true). That last parameters enable strict type checking (so that "1" == 1 is false). The root cause of these issues is the same as in C: it imposes too much bandwidth to get it right, every time, all the time.

                                                                                        NULLs have the same issue: you need to think “can this be NULL?” every time. It’s not a hard question, but it’s sooner or later you’ll get it wrong and asking it all the time takes up a lot of bandwidth probably best spent elsewhere.

                                                                                        1. 30

                                                                                          Java does magically solve all memory problems. People did rave about garbage collection: garbage collection is in fact revolutionary.

                                                                                          1. 5

                                                                                            That was a long time ago so lots of people don’t remember what OP is talking about anymore. The claim wasn’t that Java would magically solve all memory problems. That was back when the whole “scripting vs. systems” language dichotomy was all the rage and everyone thought everything would be written in TCL, Scheme or whatever in ten years or so. There was a more or less general expectation (read: lots of marketing material, since Java was commercially-backed, but certainly no shortage of independent tech evangelists) that, without pointers, all problems would go away – no more security issues, no more crashes and so on.

                                                                                            Unsurprisingly, neither of those happened, and Java software turned out to be crash-prone in its own unpleasant ways (there was a joke about how you can close a Java program if you can’t find the quit button: wiggle the mouse around, it’ll eventually throw an unhandled exception) in addition to good ol’ language-agnostic programmer error.

                                                                                          2. 29

                                                                                            If you took an introductory course in C, you would learn how not to do that.

                                                                                            Yet somehow the cURL person/people made the mistake. Things slip by.

                                                                                            Java doesn’t allow one to reference data by its memory address, precisely to avoid this whole class of problems, why isn’t everyone raving about how that magically solved all problems? The answer is: because it obviously didn’t.

                                                                                            That, actually, was one of the the biggest selling points of Java to C++ devs. It’s probably the biggest reason that Java is still such a dominant language today.

                                                                                            I also take issue with your whole message. You say that you can’t fix bad engineering by throwing a new language at it. But that’s an over generalization of the arguments being made. You literally can fix bad memory engineering by using a language that doesn’t allow it, whether that’s Java or Rust. In the meantime, you offer no solution other than “don’t do this thing that history has shown is effectively unavoidable in any sufficiently large and long-lived C program”. So what do you suggest instead? Or are we just going to wait for heartbleed 2.0 and act surprised that it happened yet again in a C program?

                                                                                            Further, you throw out a complaint that we can’t prove that rewriting in Rust (or whatever) won’t make things worse than they currently are. We live in the real world- you can’t prove lots of things, but is there any reason to actually suspect that this is realistically possible?

                                                                                            1. 27

                                                                                              This mindset of replacing a language to remove a class of errors is naive at best.

                                                                                              I’d rather say that your post is, charitably, naive at best (and it continuing to dominate the conversation is an unfortunate consequence of the removal of the ability to flag down egregiously incorrect posts, sadly).

                                                                                              I hate null with a passion and I do think Rust memory safety is a valuable feature. But lets take the biggest problem of that class as an example, the heartbleed bug. If you look at the vulnerability code, it is a very basic mistake. If you took an introductory course in C, you would learn how not to do that.

                                                                                              Do you really believe that the OpenSSL programmers (whatever else you can say about that project) lack an introductory knowledge of C? Do you feel the linux kernel devs, who have made identical mistakes, similarly lack an introductory knowledge of C? Nginx devs? Apache? Etc, etc.

                                                                                              This is an extraordinary claim.

                                                                                              You don’t solve bad engineering by throwing a hack at it such as changing the language.

                                                                                              Probably one of the most successful fields in history at profoundly reducing, and keeping low, error rates has been the Aviation industry, and the lesson of their success is that you don’t solve human errors by insisting that the people who made the errors would have known not to if they’d just taken an introductory course they’d already long covered, or in general just be more perfect.

                                                                                              The Aviation industry realized that humans, no matter how well tutored and disciplined and focused, inevitably will still make mistakes, and that the only thing that reduces errors is looking at the mistakes that are made and then changing the system to account for those mistakes and reduce or eliminate their ability to recur.

                                                                                              When your dogma leads to you making extraordinary (indeed, ludicrous) claims, and the historical evidence points the polar opposite of the attitude you’re preaching being the successful approach, it’s past time to start reconsidering your premise.

                                                                                              1. 13

                                                                                                The Aviation industry realized that humans, no matter how well tutored and disciplined and focused, inevitably will still make mistakes, and that the only thing that reduces errors is looking at the mistakes that are made and then changing the system to account for those mistakes and reduce or eliminate their ability to recur.

                                                                                                I’d like to stress that this is only one part of Aviation’s approach, at least as driven by the FAA and the NTSB in the US. The FAA also strives to create a culture of safety, by mandating investigations into incidents, requiring regular medical checkups depending on your pilot rating, releasing accident findings often, incentivizing record-keeping on both aircraft (maintenance books) and pilots (logbooks), encouraging pilots to share anonymous information on incidents that occurred with minor aircraft or no passenger impact, and many more. This isn’t as simple as tweaking the system. It’s about prioritizing safety at every step of the conversation.

                                                                                                1. 7

                                                                                                  A fair point. And of course all of this flies directly in the face of just yelling “be more perfect at using the deadly tools!” at people.

                                                                                                  1. 4

                                                                                                    Yup, I meant this more to demonstrate what it takes to increase safety in an organized endeavor.

                                                                                                  2. 1

                                                                                                    Dropping the discussion of “the problem is human nature” in this comment. I’m explicitly not rhetorically commenting on it or implying such.

                                                                                                    These “other parts”, and culture of safety - how would we translate that across into programming? Actually, come to think of it that’s probably not the first question. The first question is, is it possible to translate that across into programming?

                                                                                                    I think it’s fair to say that in e.g. webdev people flat-out just value developer velocity over aerospace levels of safety because (I presume) faster development is simply more valuable in webdev than it is in aerospace - if the thing crashes every tuesday you’ll lose money, but you won’t lose that much money. So, maybe it’s impractical to construct such a culture. Maybe. I don’t know.

                                                                                                    But, supposing it is practical, what are we talking about? Record-keeping sounds like encouraging people to blog about minor accidents, I guess? But people posting blogs is useless if you don’t have some social structure for discussing the stuff, and I’m not sure what the analogous social structure would be here.

                                                                                                    “Prioritizing safety at every step of the conversation” sounds like being able to say no to your boss without worry.

                                                                                                    “This isn’t as simple as tweaking the system” sounds like you’re saying “treat this seriously and stop chronicly underserving it both financially and politically”, which sounds to me like “aim for the high-hanging fruit of potential problems”, which I don’t think anyone with the word “monetize” job description will ever remotely consider.

                                                                                                    What are the low-hanging fruit options in this “stop excessively focusing on low-hanging fruit options” mindset you speak of?

                                                                                                    Actually, it sounds like that sort of thing would need sort of government intervention in IT security or massive consumer backlash. Or more likely both, with the latter causing the former.

                                                                                                    1. 1

                                                                                                      The first question is, is it possible to translate that across into programming?

                                                                                                      It most certainly is. The “easiest” place to see evidence of this is to look into fields of high-reliability computing. Computing for power plants, aviation, medical devices, or space are all good examples. A step down would be cloud providers that do their best to provide high availability guarantees. These providers also spend a lot of engineering effort + processes in emphasizing reliability.

                                                                                                      But, supposing it is practical, what are we talking about? Record-keeping sounds like encouraging people to blog about minor accidents, I guess? But people posting blogs is useless if you don’t have some social structure for discussing the stuff, and I’m not sure what the analogous social structure would be here.

                                                                                                      Thing of the postmortem process posted on the blogs of the big cloud providers. This is a lot like the accident reports that the NTSB releases after accident investigation. I think outside of the context of a single entity coding for a unified goal (whether that’s an affiliation of friends, a co-op, or a company), it’s tough to create a “culture” of any sort, because in different contexts of computing, different tradeoffs are desired. After all, I doubt you need a high reliability process to write a simple script.

                                                                                                      “This isn’t as simple as tweaking the system” sounds like you’re saying “treat this seriously and stop chronicly underserving it both financially and politically”, which sounds to me like “aim for the high-hanging fruit of potential problems”, which I don’t think anyone with the word “monetize” job description will ever remotely consider.

                                                                                                      You’d be surprised how many organizations, both monetizing and not, have this issue. Processes become ossified; change is hard. Aiming for high-hanging fruit is expensive. But a mix of long-term thinking and short-term thinking is always the key to making good decisions, and in computing it’s no different. You have to push for change if you’re pushing against a current trend of unsafety.

                                                                                                      What are the low-hanging fruit options in this “stop excessively focusing on low-hanging fruit options” mindset you speak of?

                                                                                                      There needs to be a feedback mechanism between failure of the system and engineers creating the system. Once that feedback is in place, safety can be prioritized over time. Or at least, this is one way I’ve seen this done. There are probably many paths out there.

                                                                                                      I think it’s fair to say that in e.g. webdev people flat-out just value developer velocity over aerospace levels of safety because (I presume) faster development is simply more valuable in webdev than it is in aerospace - if the thing crashes every tuesday you’ll lose money, but you won’t lose that much money. So, maybe it’s impractical to construct such a culture. Maybe. I don’t know.

                                                                                                      This here is the core problem. Honestly, there’s no reason to hold most software to a very high standard. If you’re writing code to scrape the weather from time to time from some online API and push it to a billboard, meh. What software needs to do is get a lot better about prioritizing safety in the applications that require it (and yes, that will require some debate in the community to come up with applications that require this safety, and yes there will probably be different schools of thought as there always are). I feel that security is a minimum, but beyond that, it’s all application specific. Perhaps the thing software needs the most now is just pedagogy on operating and coding with safety in mind.

                                                                                                      1. 1

                                                                                                        A step down would be cloud providers that do their best to provide high availability guarantees. These providers also spend a lot of engineering effort + processes in emphasizing reliability.

                                                                                                        Google’s SRE program and the SRE book being published for free are poster examples of promoting a culture of software reliability.

                                                                                                2. 18

                                                                                                  You don’t solve bad engineering by throwing a hack at it such as changing the language.

                                                                                                  Yes, you absolutely do. One thing you can rely on is that humans will make mistakes. Even if they are the best, even if you pay them the most, even if you ride their ass 24 hours a day. Languages that make certain kinds of common mistakes uncommon or impossible save us from ourselves. All other things being equal, you’d be a fool not to choose a safer language.

                                                                                                  1. 8

                                                                                                    I wrote a crypto library in C. It’s small, only 2K lines of code. I’ve been very diligent every step of the way (save one, which I paid dearly). I reviewed the code several times over. There was even an external audit. And very recently, I’ve basically fixed dead code. Copying a whopping 1KB, allocating and wiping a whole buffer, wasting lines of code, for no benefit whatsoever. Objectively a poor piece of code with a basic flaw.

                                                                                                    I’m very careful with my library, and overall I’m very proud of its overall quality; but sometimes I’m just tired.

                                                                                                    (As for why it wasn’t noticed: as bad as it was, the old code was correct, so it didn’t trigger any error.)

                                                                                                    1. 7

                                                                                                      All programmers are bad programmers then, otherwise why do we need compiler error messages?

                                                                                                      Software apparently can’t just be written correctly the first time.

                                                                                                      1. 15

                                                                                                        I’m half joking here but, indeed, if language-level memory safety were all it takes for secure software to happen, we could have been saved ages ago. We didn’t have to wait for Go, or Rust, or Zig to pop up. A memory-safe language with no null pointers, where buffer overflow, double-frees and use-after-free bugs are impossible, has been available for more than 20 years now, and the security track record of applications written in that language is a very useful lesson. That language is PHP.

                                                                                                        I’m not arguing that (re)writing curl in Go or Rust wouldn’t eventually lead to a program with fewer vulnerabilities in this particular class, I’m just arguing that “this program is written in C and therefore not trustworthy because C is an unsafe language” is, at best, silly. PHP 4 was safer than Rust and boy do I not want to go back to dealing with PHP 4 applications.

                                                                                                        Now of course one may argue that, just like half of curl’s vulnerabilities are C mistakes, half of those vulnerabilities were PHP 4 mistakes. But in that case, it seems a little unwise to wager that, ten years from now, we won’t have any “half of X vulnerabilities are Rust mistakes” blog posts…

                                                                                                        1. 13

                                                                                                          Language-level anything isn’t all it takes, but from my experience they do help and they help much more than “a little”, and… I’ll split this in two.

                                                                                                          The thing I’ve done that found the largest number of bugs ever was when I once wrote a script to look for methods (in a >100kloc code base) that that three properties: a) Each method accepted at least one pointer parameter b) contained null in the code and c) did not mention null in the documentation for that method. Did that find all null-related errors? Far from it, and there were several false positives for each bug, and many of the bugs weren’t serious, but I used the output to fix many bugs in just a couple of days.

                                                                                                          Did this fix all bugs related to null pointers? No, not even nearly. Could I have found and fixed them in other ways? Yes, I could. The other ways would have been slower, though. The script (or let’s call it a query) augmented my capability, in much the same way as many modern techniques augment programmers.

                                                                                                          And this brings me to the second part.

                                                                                                          We have many techniques that do do nothing capable programmers can’t do. (I’ve written assembly language without any written specification, other documentation, unit tests or dedicated testers, and the code ran in production and worked. It can be done.)

                                                                                                          That doesn’t mean that these techniques are superfluous. Capable programmers are short of time and attention; techniques that use CPU cycles, RAM and files, and that save brain time are generally a net gain.

                                                                                                          That includes safe languages, but also things like linting, code queries, unit tests, writing documentation and fuzzing (or other white-noise tests). I’d say it also includes code review, which can be described as using other ream members’ attention to reduce the total attention needed to deliver features/fix bugs.

                                                                                                          Saying “this program is safe because it has been fuzzed” or “because it uses unit tests” doersn’t make sense. But “this program is unsafe because it does not use anything more than programmer brains” makes sense and is at least a reasonable starting assumption.

                                                                                                          (The example I used above was a code query. A customer reported a bug, I hacked together a code query to find similar possible trouble spots, and found many. select functions from code where …)

                                                                                                          1. 2

                                                                                                            PHP – like Go, Rust and many others out there – also doesn’t use anything more than programmer brains to avoid off-by-one errors, for example, which is one of the most common causes of bugs with or without security implications. Yet nobody rushes to claim that programs written in one of these languages are inherently unsafe because they rely on nothing but programmer brains to find such bugs.

                                                                                                            As I mentioned above: I’m not saying these things don’t matter, of course they do. But conflating memory safety with software security or reliability is a bad idea. There’s tons of memory-safe code out there that has so many CVEs it’s not even funny.

                                                                                                            1. 17

                                                                                                              But conflating memory safety with software security or reliability is a bad idea. There’s tons of memory-safe code out there that has so many CVEs it’s not even funny.

                                                                                                              Who is doing this? The title of the OP is explicitly not conflating memory safety with software security. Like, can you find anyone with any kind of credibility conflating these things? Are there actually credible people saying, “curl would not have any CVEs if it were written in a memory safe language”?

                                                                                                              It is absolutely amazing to me how often this straw man comes up.

                                                                                                              EDIT: I use the word “credible” because you can probably find a person somewhere on the Internet making comments that support almost any kind of position, no matter how ridiculous. So “credible” in this context might mean, “an author or maintainer of software the other people actually use.” Or similarish. But I do mean “credible” in a broad sense. It doesn’t have to be some kind of authority. Basically, someone with some kind of stake in the game.

                                                                                                              1. 7

                                                                                                                Just a few days ago there was a story on the lobster.rs front page whose author’s chief complaint about Linux was that its security was “not ideal”, the first reason for that being that “Linux is written in C, [which] makes security bugs rather common and, more importantly, means that a bug in one part of the code can impact any other part of the code. Nothing is secure unless everything is secure.” (Edit: which, to be clear, was in specific contrast to some Wayland compositor being written in Rust).

                                                                                                                Yeah, I’m tired of it, too. I like and use Rust but I really dislike the “evangelism taskforce” aspect of its community.

                                                                                                                1. 9

                                                                                                                  I suppose “nothing is secure unless everything is secure” is probably conflating things. But saying that C makes security bugs more common doesn’t necessarily. In any case, is this person credible? Are they writing software that other people use?

                                                                                                                  I guess I just don’t understand why people spend so much time attacking a straw man. (Do you even agree that it is a straw man?) If someone made this conflation in a Rust space, for example, folks would be very quick to correct them that Rust doesn’t solve all security problems. Rust’s thesis is that it reduces them. Sometimes people get confused either because they don’t understand or because none are so enthusiastic as the newly converted. But I can’t remember anyone with credibility making this conflation.

                                                                                                                  Like, sure, if you see someone conflating memory safety with all types of security vulnerabilities, then absolutely point it out. But I don’t think it makes sense to talk about that conflation as a general phenomenon that is driving any sort of action. Instead, what’s driving that action is the thesis that many security vulnerabilities are indeed related to memory safety problems, and that using tools which reduce those problems in turn can eventually lead to more secure software. While some people disagree with that, it takes a much more nuance argument and it sounds a lot less ridiculous than the straw man you’re tearing down.

                                                                                                                  Yeah, I’m tired of it, too. I like and use Rust but I really dislike the “evangelism taskforce” aspect of its community.

                                                                                                                  I’m more tired of people complaining about the “evangelism taskforce.” I see a lot more of that than I do the RESF.

                                                                                                                  1. 7

                                                                                                                    Sorry, I think I should have made the context more obvious. I mean, let me start with this one, because I’d also like to clarify that a) I think Rust is good and b) that, as far as this particular debate is concerned, I think writing new things in Rust rather than C or especially C++ is a good idea in almost every case:

                                                                                                                    (Do you even agree that it is a straw man?)

                                                                                                                    What, that experienced software developers who know and understand Rust are effectively claiming that Rust is magic security/reliability dust? Oh yeah, I absolutely agree that it’s bollocks, I’ve seen very few people who know Rust and have more than a few years of real-life development experience in a commercial setting making that claim with a straight face. There are exceptions but that’s true of every technology.

                                                                                                                    But when it comes to the strike force part, here’s the thing:

                                                                                                                    If someone made this conflation in a Rust space, for example, folks would be very quick to correct them that Rust doesn’t solve all security problems.

                                                                                                                    …on the other hand, for a few years now it feels like outside Rust spaces, you can barely mention an OS kernel or a linker or a window manager or (just from a few days ago!) a sound daemon without someone showing up saying ugh, C, yeah, this is completely insecure, I wouldn’t touch it with a ten-foot pole. Most of the time it’s at least plausible, but sometimes it’s outright ridiculous – you see the “not written in Rust” complaint stuck on software that has to run on platforms Rust doesn’t even support, or that was started ten years ago and so on.

                                                                                                                    Most of them aren’t credible by your own standards or mine, of course, but they’re part of the Rust community whether they’re representative of the “authoritative” claims made by the Rust developers or not.

                                                                                                                    1. 4

                                                                                                                      Fair enough. Thanks for the reply!

                                                                                                                      1. 4

                                                                                                                        …on the other hand, for a few years now it feels like outside Rust spaces, you can barely mention an OS kernel or a linker or a window manager or (just from a few days ago!) a sound daemon without someone showing up saying ugh, C, yeah, this is completely insecure, I wouldn’t touch it with a ten-foot pole. Most of the time it’s at least plausible, but sometimes it’s outright ridiculous – you see the “not written in Rust” complaint stuck on software that has to run on platforms Rust doesn’t even support, or that was started ten years ago and so on.

                                                                                                                        As I mentioned in my below comment on this article, this is a good thing. I want people who decide to write a novel sound daemon in C to see those sorts of comments, and (ideally) rethink the decision to write a novel C program to begin with. Again, this doesn’t necessarily imply that Rust is the right choice of language for any given project, but it’s a strong contender right now.

                                                                                                                        1. 4

                                                                                                                          Even now though, there still is significant tension between “don’t use C” and “make it portable”. Especially if you’re targetting embedded, or unknown platforms. C is still king of the hill as far as portability goes.

                                                                                                                          What we really want is dethrone C at its own game: make something that eventually becomes even more portable. That’s possible: we could target C as a backend, and we could formally specify the language so it’s clear what’s a compiler bug (not to mention the possibility of writing formally verified compilers). Rust isn’t there yet.

                                                                                                                          1. 6

                                                                                                                            One of the (many) reasons I don’t use C and use Rust instead is because it’s easier to write portable programs. I believe every Rust program I’ve written also works on Windows, and that has nearly come for free. Certainly a lot cheaper than if I had written it in C. I suppose people use “portable” to mean different things, but without qualification, your dichotomy doesn’t actually seem like a dichotomy. I suppose the dichotomy is more, “don’t use C” and “make it portable to niche platforms”?

                                                                                                                            1. 3

                                                                                                                              I think we (as in both me and the parent poster) were talking about different kinds of portability. One of the many reasons why most of the software I work on is (still) in C rather than Rust is that, while every Rust program I’ve written works on Windows, lots of the ones I need have to work on architectures that are, at best, Tier 2. Proposing that we ship something compiled with a toolchain that’s only “guaranteed to build” would at best get me laughed at.

                                                                                                                              1. 9

                                                                                                                                Yes. The point I’m making is that using the word “portable” unqualified is missing the fact that Rust lets you target one of the most popular platforms in the world at a considerably lower cost in lots of common cases. It makes the trade off being made more slanted than what folks probably intend by holding up “portability” as a ubiquitously good thing. Well, if we’re going to do that, we should acknowledge that there is a very large world beyond POSIX and embedded, and that world is primarily Windows.

                                                                                                                                1. 5

                                                                                                                                  For the record, if I were writing desktop GUI applications or games, of course the only relevant platforms are Windows, Linux, and MacOSX. Or Android and iOS, if the application is meant for palmtops. From there “portability” just means I chose middleware that have backends for all the platforms I care about. Rust, with its expanded standard library, does have an edge.

                                                                                                                                  If however I’m writing a widely applicable library (like a crypto library), then Rust suddenly don’t look so good any more. Because I know for a fact that many people still work on platforms that Rust doesn’t support yet. Not to mention the build dependency on Rust itself. So either I still use C, and I have more reach, or I use Rust, and I have more safety (not by much if I test my C code correctly).

                                                                                                                                  Well, if we’re going to do that, we should acknowledge that there is a very large world beyond POSIX and embedded, and that world is primarily Windows.

                                                                                                                                  Of course, my C library is also going to target Windows. Not doing so would defeat the point.

                                                                                                                                  1. 6

                                                                                                                                    I don’t think I strongly disagree with anything here. It’s just when folks say things like this

                                                                                                                                    C is still king of the hill as far as portability goes.

                                                                                                                                    I would say, “welllll I’m not so sure about that, because I can reach a lot more people with less effort using Rust than I can with C.” Because if I use C, I now need to write my own compatibility layer between my application and the OS in order to support a particularly popular platform: Windows.

                                                                                                                                    And of course, this depends on your target audience, the problem you’re solving and oodles of other things, as you point out. But there’s a bit of nuance here because of how general the word “portable” is.

                                                                                                                                    1. 3

                                                                                                                                      Yeah, I was really talking about I/O free libraries. I believe programs should be organised in 3 layers:

                                                                                                                                      • At the bottom, you have I/O free libraries, that depend on nothing but the compiler and maybe the standard library. That lack of dependency can make them extremely portable, and easy to integrate to existing projects. The lack of I/O makes them easy to test, so they have the potential to be very reliable, even if they’re written in an unsafe language.
                                                                                                                                      • In the middle, you have, the I/O compatibility layer. SDL, Qt, Libuv, Rust’s stdlib, even hand written, take your pick. That one cannot possibly be portable, because it has to depend on the quirks of the underlying platform. But it can have several backends, which make the users of this compatibility layer quite portable.
                                                                                                                                      • At the top, you have the application, that depends on the I/O free library and the compatibility layer. It cannot target platforms the compatibility layers doesn’t target, but at least is should be fairly small (maybe 10 times smaller than the I/O free libraries?), so if a rewrite is needed it shouldn’t be that daunting.

                                                                                                                                      I believe C is still a strong contender for the bottom layer. There specifically, it is still the king of portability. For the middleware and the top layer however, the portability of the language means almost nothing, so it’s much harder to defend using C there.

                                                                                                                                      Also note that the I/O free libraries can easily be application specific, and not intended for wider distribution. In that case, C also loses its edge, as (i) portability matters much less, and (ii) it’s still easier to use a safe language than write a properly paranoid test suite.

                                                                                                                                  2. 0

                                                                                                                                    So does C#. Targeting popularity does not make you portable.

                                                                                                                                2. 3

                                                                                                                                  I was talking about “runs on a 16-bit micro controller as well as an 64-bit monster”. The kind where you might not have any I/O, or even a heap allocator. The kind where you avoid undefined behaviour and unspecified behaviour and implementation defined behaviour.

                                                                                                                                  Hard, but possible for some programs. Crypto libraries (without the RNG) for instance are pure computation, and can conform to that highly restricted setting. I’ll even go a bit further: I think over 95% of programs can be pure computation, and be fully separated from the rest (I/O, system calls, networking and all that).

                                                                                                                                  If you want to print stuff on a terminal, portability drops. If you want to talk to the network or draw pixels on the screen, portability in C is flat out impossible, because the required capabilities aren’t in the standard library. I hear Rust fares far better in that department.

                                                                                                                                  I suppose the dichotomy is more, “don’t use C” and “make it portable to niche platforms”?

                                                                                                                                  Open BSD has tier 3 support for Rust, which basically means no support. You assess how “niche” OpenBSD really is, especially in a security context.

                                                                                                                                  1. 8

                                                                                                                                    Yes, I would absolutely say OpenBSD is a niche platform. I generally don’t care if the stuff I write works on OpenBSD. I just don’t. I care a lot more that it runs on Windows though. If more people used OpenBSD, then I’d care more. That’s the only reason I care about Windows. It’s where the people are.

                                                                                                                                    Niche doesn’t mean unimportant.

                                                                                                                                    To pop up a level, I was making a very narrow point on a particular choice of wording. Namely, that “Rust isn’t as portable as C” is glossing over some really significant nuance depending on what you’re trying to do. If all you’re trying to do is distribute a CLI application, then Rust might not let you target as many platforms as easily as C, but it might let you reach more people with a lot less effort.

                                                                                                                              2. 4

                                                                                                                                I want people who decide to write a novel sound daemon in C to see those sorts of comments, and (ideally) rethink the decision to write a novel C program to begin with.

                                                                                                                                What in the world makes you think they haven’t considered that question and concluded that C, for all its shortcomings, was nonetheless their best option?

                                                                                                                                1. 1

                                                                                                                                  If the conclusion is C, their thinking is wrong.

                                                                                                                              3. 1

                                                                                                                                stuck on software that has to run on platforms Rust doesn’t even support

                                                                                                                                Porting Rust to a platform sounds more achievable than writing correct software in C, so the only thing ridiculous is that people think “I haven’t ported it” is a valid excuse.

                                                                                                                          2. 2

                                                                                                                            Who is doing this?

                                                                                                                            Lots of people. Search for “heartbleed C” or “heartbleed memory safety” or “heartbleed rust”.

                                                                                                                            Are there actually credible people saying, “curl would not have any CVEs if it were written in a memory safe language”?

                                                                                                                            They are not credible to me if they make such absurd claims, but they exist in very large numbers. They won’t claim that all problems would go away, but they all point out that heartbleed woulnd’t happen if openssl was written in Rust (for example). Yes, there are hundreds of such claims on the web. Thousands probably. As if a basic error like the one that led to heartbleed could only take the form of a memory safety problem.

                                                                                                                            As for credibility. I don’t find your definition very useful. There is a lot of software used by millions, much of it genuinely useful that is still badly engineered. I don’t think popularity is a good indicator for credibility.

                                                                                                                            1. 6

                                                                                                                              Can you actually show me someone who is claiming that all security vulnerabilities will be fixed by using Rust or some other memory safe language that would meet your standard of credibility if it weren’t for that statement itself?

                                                                                                                              I tried your search queries and I found nobody saying or implying something like, “using a memory safe language will prevent all CVEs.”

                                                                                                                              but they all point out that heartbleed woulnd’t happen if openssl was written in Rust (for example)

                                                                                                                              This is a very specific claim though. For the sake of argument, if someone were wrong about that specific case, that doesn’t mean they are conflating memory safety for all security vulnerabilities. That’s what I’m responding to.

                                                                                                                              As for credibility. I don’t find your definition very useful. There is a lot of software used by millions, much of it genuinely useful that is still badly engineered. I don’t think popularity is a good indicator for credibility.

                                                                                                                              So propose a new one? Sheesh. Dispense with the pointless nitpicking and move the discussion forward. My definition doesn’t require something to be popular. I think I was pretty clear in my comment what I was trying to achieve by using the word “credible.” Especially after my edit. I even explicitly said that I was trying to use it in a very broad sense. So if you want to disagree, fine. Then propose something better. Unless you have no standard of credibility. In which case, I suppose we’re at an impasse.

                                                                                                                              1. 1

                                                                                                                                I tried your search queries and I found nobody saying or implying something like, “using a memory safe language will prevent all CVEs.”

                                                                                                                                I never made such claim. You are insisting in the whole “prevent all CVEs”. That is an extreme point that I never made, nor did any other people in this thread. If you take to that extreme, then sure you are right. I never claimed that people say that Rust will magically do their laundry either. Please let’s keep the discussion to a level of reasonability so it stays fruitful.

                                                                                                                                FWIW, for “heartbleed rust”, google returns this in the first page:

                                                                                                                                • Would the Cloudbleed have been prevented if Rust was used
                                                                                                                                • How to Prevent the next Heartbleed
                                                                                                                                • Would Rust have prevented Heartbleed? Another look

                                                                                                                                All these are absurd. It is not my point to shame or blame. I have no idea who the author of the heartbleed offending code is. And in all honest we all have made mistakes. But let’s not take relativism to the absurd. Let’s be clear, it was objectively very poorly written code with a trivial error. A seasoned engineer should look at that and immediately see the problem. If you think that level of quality is less problematic when you use a ‘safer’ language, you are in for very bad surprises. It was objectively bad engineering, nothing less. The language had nothing to do with that. A problem with the same severity would have the same probability to occur in Rust, it would just take other form. The claims on the titles I quoted from my google are silly. If you jump from a plane without a parachute you also prevent the whole class of accidents that happen when the screen opens up. I am sure people understand that that is a silly claim.

                                                                                                                                This is a very specific claim though. For the sake of argument, if someone were wrong about that specific case, that doesn’t mean they are conflating memory safety for all security vulnerabilities. That’s what I’m responding to.

                                                                                                                                Again, no one is claiming that rust community is conflating memory safety with “all safety vulns”. I have no clue where you got that from. But to the point, it is as specific as it is pointless, as is the parachute example.

                                                                                                                                1. 6

                                                                                                                                  I never made such claim.

                                                                                                                                  I didn’t say you did. But that’s the claim I’m responding to.

                                                                                                                                  You are insisting in the whole “prevent all CVEs”.

                                                                                                                                  I didn’t, no. I was responding to it by pointing out that it’s a straw man. It sounds like you agree. Which was my central point.

                                                                                                                                  nor did any other people in this thread

                                                                                                                                  No, they did:

                                                                                                                                  But conflating memory safety with software security or reliability is a bad idea. There’s tons of memory-safe code out there that has so many CVEs it’s not even funny.

                                                                                                                                  The rest of your comment is just so far removed from any reality that I know that I don’t even know how to engage with it. It sounds like you’re in the “humans just need to be better” camp. I’m sure you’ve heard the various arguments about why that’s not a particularly productive position to take. I don’t have any new arguments to present.

                                                                                                                                  1. 3

                                                                                                                                    No, they did:

                                                                                                                                    Specifically, I (sort of) claimed that and expanded upon it here. And I’m just going to re-emphasise what I said in that comment.

                                                                                                                                    I see from your profile that you’re a member of the Rust library team – I imagine most of the interactions you have within the Rust community are with people who are actively involved in building the Rust environment. That is, people who have the expertise (both with Rust and other aspects software development), the skill, and the free time to make substantial contributions to a game-changing technology, and who are therefore extremely unlikely to claim anything of that sort.

                                                                                                                                    So I understand why this looks like a straw man argument to you – but this is not the Rust-related interaction that many people have. I was gonna say “most” but who knows, maybe I just got dealt a bad hand.

                                                                                                                                    Most of “us” (who don’t know/use Rust or who, like me, don’t use it that much) know it via the armchair engineering crowd that sits on the sides, sneers at software like the Linux kernel and casually dismisses it as insecure just for being written in C, with the obvious undertone that writing it in Rust would make it secure. Like this or like this or like this.

                                                                                                                                    They’re not dismissing it as memory unsafe and the undertone isn’t that (re)writing it in Rust would plug the memory safety holes. When they propose that some 25 year-old piece of software be rewritten in Rust today, the idea, really, is that if you start today, you’ll have something that’s more secure, whatever the means, in like one or two years.

                                                                                                                                    That’s why there are people who want RIIR flags. Not to avoid useful discussion with knowledgeable members of the Rust community like you, but to avoid dismissive comments from the well ackshually crowd who thinks about something for all of thirty seconds and then knows exactly where and why someone is wrong about a project they’ve been working on for five years.

                                                                                                                                    1. 5

                                                                                                                                      I imagine most of the interactions you have within the Rust community are with people who are actively involved in building the Rust environment.

                                                                                                                                      Not necessarily. It depends on the day. I am also on the moderation team. So I tend to get a narrow view on library matters and a very broad view on everything else. But I also frequent r/rust (not an “official” Rust space), in addition to HN and Lobsters.

                                                                                                                                      That is, people who have the expertise (both with Rust and other aspects software development), the skill, and the free time to make substantial contributions to a game-changing technology, and who are therefore extremely unlikely to claim anything of that sort.

                                                                                                                                      Certainly. I am under no illusion about that. I don’t think you or anyone was saying “core Rust engineers have made ridiculous claim Foo.” That’s why I was asking for more data. I wanted to hear about any credible person who was making those claims.

                                                                                                                                      FWIW, you didn’t just do this with Rust. You kinda did it with Java too in another comment:

                                                                                                                                      There was a more or less general expectation (read: lots of marketing material, since Java was commercially-backed, but certainly no shortage of independent tech evangelists) that, without pointers, all problems would go away – no more security issues, no more crashes and so on.

                                                                                                                                      I mean, like, really? All problems? I might give you that there were maybe some marketing materials that, by virtue of omission, gave that impression that Java solved “all problems.” But, a “general expectation”? I was around back then too, and I don’t remember anything resembling that.

                                                                                                                                      But, like, Java did solve some problems. It came with some of its own, not all of which were as deeply explored as they are today.

                                                                                                                                      See, the thing is, when you say hyperbolic things like this, it makes your side of the argument a lot easier to make. Because making this sort of argument paints the opposing side as patently ridiculous, and this in turn removes the need to address the nuance in these arguments.

                                                                                                                                      So I understand why this looks like a straw man argument to you – but this is not the Rust-related interaction that many people have. I was gonna say “most” but who knows, maybe I just got dealt a bad hand.

                                                                                                                                      Again. If you see someone with a misconception like this—they no doubt exist—then kindly point it out. But talking about it as a sort of general phenomenon just seems so misguided to me. Unless it really is a general phenomenon, in which case, I’d expect to be able to observe at least someone building software that others use on the premise that switching to Rust will fix all of their security problems. Instead, what we see are folks like the curl author making a very careful analysis of the trade offs involved here. With data.

                                                                                                                                      Like this or like this or like this.

                                                                                                                                      RE https://news.ycombinator.com/item?id=25921917: Yup, that’s a troll comment from my perspective. If I had seen it, I would have flagged it.

                                                                                                                                      RE https://news.ycombinator.com/threads?id=xvilka: I can’t tell if they’re a troll, but they definitely post low effort comments. I’d downvote most of them if I saw them. I downvote almost any comment that is entirely, “Why didn’t you write it in X language?” Regretably, it can be a legitimate question for beginners to ask, since a beginner’s view of the world is just so narrow, nearly by definition.

                                                                                                                                      RE https://news.ycombinator.com/item?id=26398042: Kinda more of the above.

                                                                                                                                      I note that the first and third links you gave were downvoted quite a bit. So that seems like the system is working. And that there aren’t hordes of people secretly in favor of comments like that and upvoting them.

                                                                                                                                      FWIW, I don’t recognize any of these people as Rust community members. Or rather, I don’t recognize their handles. And as a moderator, I am at least passively aware of pretty much anyone that frequents Rust spaces. Because I have to skim a lot of content.

                                                                                                                                      I’m not sure why we have descended into an RESF debate. For every RESF comment you show, I could show you another anti-RESF Lobsters’ comment.

                                                                                                                                      It’s just amazing to me that folks cannot distinguish between the zeal of the newly converted and the actual substance of the idea itself. Like, look at this comment in this very thread. Calling this post “RIIR spam,” even though it’s clearly not.

                                                                                                                                      They’re not dismissing it as memory unsafe and the undertone isn’t that (re)writing it in Rust would plug the memory safety holes. When they propose that some 25 year-old piece of software be rewritten in Rust today, the idea, really, is that if you start today, you’ll have something that’s more secure, whatever the means, in like one or two years.

                                                                                                                                      But that’s very different than what you said before. It doesn’t necessarily conflate memory safety with security. That’s a more nuanced representation of the argument and it is much harder to easily knock down (if at all). It’s at least true enough that multiple groups of people with a financial stake have made a bet on that being true. A reasonable interpretation of “more secure” is “using Rust will fix most or nearly all of the security vulnerabilities that we have as a result of memory unsafety.” Can using Rust also introduce new security vulnerabilities unrelated to memory safety by virtue of the rewrite? Absolutely. But whether this is true or not, and to what extent, really depends on a number of nuanced factors.

                                                                                                                                      That’s why there are people who want RIIR flags. Not to avoid useful discussion with knowledgeable members of the Rust community like you, but to avoid dismissive comments from the well ackshually crowd who thinks about something for all of thirty seconds and then knows exactly where and why someone is wrong about a project they’ve been working on for five years.

                                                                                                                                      The “well ackshually” crowd exists pretty much everywhere. Rust perhaps has a higher concentration of them right now because it’s still new. But they’re always going to be around. I’ve been downvoting and arguing with the “well ackshually” crowd for years before I even knew what Rust was.

                                                                                                                                      If you see a dismissive comment that isn’t contributing to the discussion, regardless of whether it’s about RIIR or not, flag it. I have absolutely no problem with folks pointing out low effort RESF comments that express blind enthusiasm for a technology. Trade offs should always be accounted for. My problem is that the anti-RESF crowd is not doing just that. They are also using it as a bludgeon against almost anything that involves switching to Rust. This very post, by Curl’s author, is not some low effort RESF bullshit. (I should say that not all RESF bullshit is trolling. I’ve come across a few folks that are just new to the world of programming. So they just don’t know how to see the nuance in things yet, even if it’s explicitly stated. There’s only so much novel signal a brain can take in at any point. Unfortunately, it’s difficult to differentiate between sincere but misguided beginners and trolls. Maybe there are people other than trolls and beginners posting RESF bullshit, but I don’t actually know who they are.)

                                                                                                                                      Either way, if we get RIIR flags, then we should get anti-RIIR flags. See where that leads? Nowhere good. Because people can’t seem to differentiate between flippant comments and substance.

                                                                                                                                      Sorry I got a bit ranty, but this whole thread is just bush league IMO.

                                                                                                                                      1. 3

                                                                                                                                        This very post, by Curl’s author, is not some low effort RESF bullshit.

                                                                                                                                        No, I’m aware of that. But the RESF bullshit posters have a bit of a history with Curl: https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ .

                                                                                                                                        Every once in a while someone suggests to me that curl and libcurl would do better if rewritten in a “safe language”. Rust is one such alternative language commonly suggested. This happens especially often when we publish new security vulnerabilities.

                                                                                                                                        I try to keep away from these bush league threads myself but, uh, sometimes you just go with it, and this was one of those cases precisely because of that context.

                                                                                                                                        I’ve been slowly trying to nudge people into using Rust on embedded systems ever since I gave up on Ada, so I’m not trying to dismiss it, I have quite an active interest in it. Yet I’ve been at the receiving end of “you should rewrite that in a safe language” many times, too, like most people writing firmware. And I don’t mean on lobster.rs (which has a level-headed audience, mostly :P), I mean IRL, too. Nine times out of ten these discussions are bullshit.

                                                                                                                                        That’s because nine times out of ten they’re not carried out with people who are really knowledgeable about Rust and firmware development. E.g. I get long lectures about how it’ll vastly improve firmware reliability by eliminating double frees and dangling pointers. When I try to point out that this is true in general, and that Rust’s memory model is generally helpful in embedded systems (e.g. the borrow checker is great!) but this particular problem is a non-issue because this is an embedded system and all allocations are static and we never get a double free because we don’t even malloc! I get long lectures about how two years from now everything will be AArch64 anyway and memory space won’t be an issue.

                                                                                                                                        (Edit: to be clear – I definitely don’t support “RIIR” flags or anything of the sort, and indeed “the system” works, as in, when one of the RIIR trolls pop up, they get downvoted into oblivion, whether they’re deliberately trolling or just don’t know better. I’m just trying to explain where some of the negativity comes from, and why in my personal experience it’s often try to hold back on it even when you actually like Rust and want to use it more!)

                                                                                                                                        I mean, like, really? All problems? I might give you that there were maybe some marketing materials that, by virtue of omission, gave that impression that Java solved “all problems.” But, a “general expectation”? I was around back then too, and I don’t remember anything resembling that.

                                                                                                                                        Oh, yeah, that was my first exposure to hype, and it gave me a healthy dose of skepticism towards tech publications. I got to witness that as a part of the (budding, in my part of the world) tech journalism scene (and then, to some degree, through my first programming gigs). The cycle went basically as follows:

                                                                                                                                        There were lots of talks and articles and books on Java between ’95 and ’97-‘98 (that was somewhat before my time but that’s the material I learned Java from later) that always opened with two things: it’s super portable (JVM!) and there are no pointers, so Java programs are less likely to crash due to bad memory accesses and are less likely to have security problems.

                                                                                                                                        These were completely level-headed and obviously correct. Experienced programmers got it and even those who didn’t use Java nonetheless emulated some of the good ideas in their own environments.

                                                                                                                                        Then 2-4 years later we got hit by all the interns and lovely USENET flamers who’d grown up on stories they didn’t really understand about Java and didn’t really qualify these statements.

                                                                                                                                        So then I spent about two years politely fending off suggestions about articles on how net appliances and thin clients are using Java because it’s more secure and stable, on why everyone is moving to Java and C++ will only be used for legacy applications and so on – largely because I really didn’t understand these things well enough, but man am I glad I let modesty get the better of me. Most of my colleagues didn’t budge, either, but there was a period during which I read a “Java programs don’t crash” article every month because at least one – otherwise quite respectable – magazine would publish one.

                                                                                                                                        1. 4

                                                                                                                                          Aye. Thanks for sharing. I totally get your perspective. Talking about your projects with folks only to have to get into an exhausting debate that you’ve had umpteen times already is frustrating. Happens to me all the time too, for things outside of Rust. So I know the feeling. It happens in the form of, “why didn’t you do X instead of Y?” Depending on how its phrased, it can feel like a low brow dismissal. The problem is that that line of questioning is also a really great way of getting a better understanding of the thing you’re looking at in a way that fits into your own mental model of the world. Like for example, at work I use Elasticsearch. If I see a new project use SOLR, I’m going to be naturally curious as to why they chose it over Elasticsearch. I don’t give two poops about either one personally, but maybe they have some insight into the two that I don’t have, and updating my mental model would be nice. The problem is that asking the obvious question comes across as a dismissal. It’s unfortunate. (Of course, sometimes it is a dismissal. It’s not always asked in good faith. Sometimes it’s coupled with a healthy dose of snobbery, and those folks can just fuck right off.)

                                                                                                                                          It’s harder to do IRL, but the technique I’ve adopted is that when someone asks me questions like that, I put about as much effort into the response as they did the question. If they’re earnest and just trying to understand, then my hope is that they might ask more follow up questions, and then it might become a nice teaching moment. But most of the time, it’s not.

                                                                                                                                          I guess I would just re-iterate that my main issue with the anti-RIIR crowd is that it’s overbroad. If it were just some groaning about trolls, then fine. But it’s brought up pretty much any time Rust is brought up, even if bringing Rust up is appropriate.

                                                                                                                                          But I suppose that’s the state of the Internet these days. Tribes are everywhere and culture wars can’t be stopped.

                                                                                                                                  2. 2

                                                                                                                                    And in all honest we all have made mistakes. But let’s not take relativism to the absurd. Let’s be clear, it was objectively very poorly written code with a trivial error. A seasoned engineer should look at that and immediately see the problem. If you think that level of quality is less problematic when you use a ‘safer’ language, you are in for very bad surprises. It was objectively bad engineering, nothing less. The language had nothing to do with that. A problem with the same severity would have the same probability to occur in Rust, it would just take other form.

                                                                                                                                    What form would it take? Would it be in the “all private keys in use on the internet can be leaked”-form? Probably not, I think?

                                                                                                                                    Anyway, let’s forget about security for a minute; why wouldn’t you want the computer to automate memory management for you? Our entire job as programmers is automate things and the more things are automated, the better as it’s less work for us. This is why we write programs and scripts in the first place.

                                                                                                                                    Traditionally automated memory management has come with some trade-offs (i.e. runtime performance hits due to GCs) and Rust attempts to find a solution which automates things without these drawbacks. This seems like a good idea to me, because it’s just more convenient: I want the computer to do as much work for me as possible; that’s its job.

                                                                                                                                    Back to security: if I have a door that could be securely locked by just pressing a button vs. a door that can be securely locked by some complicated procedure, then the first door would be more secure as it’s easier to use. Sooner or later people will invariable make some mistake in the second door’s procedure. Does that mean the first door guarantees security? No, of course not. You might forget to close the window, or you might even forget to press that button. But it sure reduces the number of things you need to do for a secure locking, and the chances you get it right are higher.

                                                                                                                        2. 4

                                                                                                                          Kinda sorta. PHP is/was largely written in C itself and IIRC had its share of memory related security bugs from just feeding naughty data to PHP standard library functions.

                                                                                                                          I don’t know what PHP is like today from that point of view.

                                                                                                                          So, I take issue when you say:

                                                                                                                          I’m just arguing that “this program is written in C and therefore not trustworthy because C is an unsafe language” is, at best, silly. PHP 4 was safer than Rust and boy do I not want to go back to dealing with PHP 4 applications.

                                                                                                                          I still think it’s completely justifiable to be skeptical of a program written in C. Just because another language may also be bad/insecure/whatever does not invalidate the statement or sentiment that C is a dangerous language that honestly brings almost nothing to the table in the modern era.

                                                                                                                          1. 3

                                                                                                                            Interestingly, there’s a different language from a very similar time as C, that has more safety features, and its name is Pascal. And there was a time when they were kinda competing, as far as I understood. This was maybe especially at the time of Turbo C and Turbo Pascal, and then also Delphi. Somehow C won, with the main argument being I believe “because performance”, at least that’s how I remember it. My impression is that quite often, when faced with a performance vs. security choice, “the market” chooses performance over security. I don’t have hard data as to whether code written in Pascal was more secure than that in C; I’d be curious to see some comparison like that. I seem to have a purely anecdotal memory, than when I felt some software was remarkably stable, it tended to show up to be written in Pascal. Obviously it was still totally possible to write programs with bugs in Pascal; I think Delphi code had some characteristic kind of error messages that I saw often enough to learn to recognize them. Notably, it also actually still required manual memory management - but I believe it was better guarded against buffer overruns etc. than C.

                                                                                                                            1. 2

                                                                                                                              I thought the reasons for C’s wide adoption were Unix and the university system. I.E., the universities were turning out grads who knew Unix and C. I’ve only heard good things about the performance of Turbo Pascal.

                                                                                                                              Pascal is safer, but it was certainly possible to write buggy Pascal. Back in the early 90s I hung out on bulletin boards and played a lot of Trade Wars 2002. That was written in Turbo Pascal, and it had a few notable and widely exploited bugs over the years. One such was a signed overflow of a 16-bit integer. I won a couple Trade Wars games by exploiting those kinds of bugs.

                                                                                                                          2. 17

                                                                                                                            You are arguing that eliminating one class of bugs doesn’t make sense, because there are other classes of bugs? That reminds me of the mental gymnastics of untyped language proponents.

                                                                                                                            1. 7

                                                                                                                              This cartoon deserves an entire blog post! But I’ll just list out the gymnastic routines of statically-typed language proponents:

                                                                                                                              1. 2

                                                                                                                                I think no one cares about this.

                                                                                                                                1. 3

                                                                                                                                  Well, not when they only spend 3 minutes per link. You might have to read and reflect.

                                                                                                                                  1. 1

                                                                                                                                    The thing is that you are completely missing the point (and your kind of nerd-contrarianism doesn’t make you look as smart as you think it does).

                                                                                                                                    1. 5

                                                                                                                                      Oh! I don’t do this to look smart. I do this because I see in you the same tribalism that I once had, and I only grew past it because of evidence like the links I shared with you. I’m not trying to say that static typing is wrong; I’m trying to expand and enrich your knowledge about type theory. Once you’ve reached a certain altitude and vantage, then you’ll see that static and dynamic typing are not tribes which live in opposition, but ways of looking at the universal behaviors of computation.

                                                                                                                                      Please, read and reflect. Otherwise this entire thread was off-topic: Your first post is not a reply to its parent, but a tangent that allowed you to display your tribal affiliation. I don’t mind being off-topic as long as it provides a chance to improve discourse.

                                                                                                                                      1. 2

                                                                                                                                        The (popular) mistake you are making is that you pretend things are equal when they are not, just like shitting your pants (untyped) and trying to not shit your pants (typed) are not positions with similar merit.

                                                                                                                                  2. 1

                                                                                                                                    No those are all serious refutations of why statically-typed languages is a panacea and is a lot more insightful than a silly comic someone made to find affirmation among their Twitter followers.

                                                                                                                                    1. 1

                                                                                                                                      Can you show me where I claimed that “typed languages [are] a panacea”?

                                                                                                                                      Anyway, have fun stomping on that strawman.

                                                                                                                              2. 6

                                                                                                                                Here are the only economically viable solutions I see to the problem of “too much core infrastructure has recurring, exploitable memory unsafety bugs” problem (mainly because of C):

                                                                                                                                • Gradually update the code with annotations – something like Checked C. Or even some palatable subset/enhancement of C++.
                                                                                                                                • Distros evolve into sandboxing based on the principle of least privilege (DJB style, reusing Chrome/Mozilla sandboxes, etc.) – I think this is one of the most economically viable solutions. You still have memory unsafety but the resulting exploits are prevented (there has been research quantifying this)
                                                                                                                                • The product side of the industry somehow makes a drastic shift and people don’t use kernels and browsers anymore (very unlikely, as even the “mobile revolution” reused a ton of infrastructure from 10, 20, 30, 40 years ago, both on the iOS and Android side)
                                                                                                                                • (leaving out hardware-based solutions here since I think hardware changes slower than software)
                                                                                                                                • (I have looked at some of the C to Rust translators, and based on my own experience with translating code and manually rewriting it, I’m not optimistic about that approach. The target language has to be designed with translation in mind, or you get a big mess.)

                                                                                                                                Manually rewriting code in Rust or any other language is NOT on that list. It would be nice but I think it’s a fantasy. There’s simply too much code, and too few people to rewrite it.

                                                                                                                                Moreover with code like bash, to a first approximation there’s 1 person who understands it well enough to rewrite it (and even that person doesn’t really understand his own code from years ago, and that’s about what we should expect, given the situation).

                                                                                                                                Also, the most infamous bash vulnerability (ShellShock) was not related to memory unsafety at all. Memory unsafety is really a subset of the problem with core infrastructure.

                                                                                                                                Sometime around 2020 I made a claim that in 2030 the majority of your kernel and your browser will still be in C or C++ (not to mention most of your phone’s low level stack, etc.).

                                                                                                                                Knowing what the incentives are and the level of resources devoted to the problem, I think we’re still on track for that.

                                                                                                                                I’m honestly interested if anyone would take the opposite side: we can migrate more than 50% of our critical common infrastructure by 2030.


                                                                                                                                This says nothing about new projects written in Rust of course. For core infrastructure, the memory safety + lack of GC could make it a great choice. But to a large degree we’ll still be using old code. Software and especially low level infrastructure has really severe network effects.

                                                                                                                                1. 1

                                                                                                                                  I agree with you. It’s just not going to happen that we actually replace most of the C code that is out there. My hope, however, is that C (and C++) becomes the next COBOL in the sense that it still exists, there are still people paid to work on systems written in it, but nobody is starting new projects in it.

                                                                                                                                  Along the same lines as your first bullet point, I think a big step forward- and the best “bang for our buck” will be people doing fuzz testing on all of these old C projects. There was just recently a story making the rounds here and on HN about some bug in… sudo? maybe? that lead to a revelation of the fact that the commit on the project that caused the regression was a bugfix to a bug for which there was no test, before or after the change. So, not only did the change introduce a bug that wasn’t caught by a test that didn’t exist- we can’t even be sure that it really fixed the issue it claimed to, or that we really understood the issue, or whatever.

                                                                                                                                  My point is that these projects probably “should” be rewritten in Rust or Zig or whatever. But there’s much lower hanging fruit. Just throw these code bases through some sanitizers, fuzzers, whatever.

                                                                                                                                  1. 2

                                                                                                                                    Yeah that’s basically what OSS Fuzz has been doing since 2016. Basically throwing a little money at projects to integrate continuous fuzzing. I haven’t heard many updates on it but in principle it seems like the right thing.

                                                                                                                                    https://github.com/google/oss-fuzz

                                                                                                                                    As of January 2021, OSS-Fuzz has found over 25,000 bugs in 375 open source projects.

                                                                                                                                    The obvious question is what percent of curl’s vulnerabilities could be found this way. I googled and found this:

                                                                                                                                    https://github.com/curl/curl-fuzzer

                                                                                                                                    which doesn’t look particularly active, and doesn’t seem to show any results (?).

                                                                                                                                    Rather than talk about curl and “RIIR” (which isn’t going to happen soon even if the maintainer wants it to), it would be better to talk about if curl is doing everything it can along the other lines.

                                                                                                                                    Someone mentioned that curl is the epitome of bad 90’s C code, and I’ve seen a lot of that myself. There is a lot of diversity in the quality of C code out there, and often the sloppiest C projects have a lot of users.

                                                                                                                                    Prominent examples are bash, PHP, Apache, etc. They code fast and sloppy and are responsive to their users.

                                                                                                                                    There’s a fundamental economic problem that a lot of these discussion are missing. Possible/impossible or feasible/infeasible is one thing; whether it will actually happen is a different story.


                                                                                                                                    Bottom line is that I think there should be more talk about projects along these lines, more talk about sandboxing and principle of least privilege, and less talk about “RIIR”.

                                                                                                                                  2. 1

                                                                                                                                    Manually rewriting code in Rust or any other language is NOT on that list.

                                                                                                                                    Nah. This kinda assumes that the rewrite/replacement/whatever would happen due to technical reasons.

                                                                                                                                    It certainly wouldn’t. If a kernel/library/application gets replaced by a safer implementation, it’s for business reasons, where it just happens that the replacement is written in e. g. Rust.

                                                                                                                                    So yes, I fully expect that a certain amount of rewrites to happen, just not for the reasons you think.

                                                                                                                                  3. 3

                                                                                                                                    I mean, there is no silver bullet, right? We can all agree with that? So, therefore, “just apply more sagacious thinking” isn’t going to fix anything just as “switch to <Rust|D|C#|&C>” won’t? The focus on tools seems to miss the truth that this is a human factors problem, and a technological solution isn’t going to actually work.

                                                                                                                                    1. 2

                                                                                                                                      One of curl’s main advantages is its ubiquity; I can run it on an OpenWRT router, a 32bit ARMv7 OpenBSD machine, a POWER9 machine, and even Illumos//OpenIndiana. It’s a universal toolkit. It also runs in extremely constrained and underpowered environments.

                                                                                                                                      Do you know of a memory-safe language that fits the bill (portability and a tiny footprint)? Rust fails on the former and Java fails on the latter. Go might work (gccgo and cgo combined have a lot of targets and TinyGo can work in constrained environments), but nowhere as well as C.

                                                                                                                                      1. 3

                                                                                                                                        Java fails on [a tiny footprint]

                                                                                                                                        There is java for smartcards . . .

                                                                                                                                        Do you know of a memory-safe language that fits the bill (portability and a tiny footprint)

                                                                                                                                        Nim, ats.

                                                                                                                                      2. 2

                                                                                                                                        How would you deal with plan interference? The linked paper requires an entirely new language in order to even talk about this class of bugs!