6 ms·

The sooner we can rewrite our programs in Go and Rust, the more secure we will be. Our shells, coreutils, mail readers and web browsers have to be written in sa

by _wldu 5y ago

The sooner we can rewrite our programs in Go and Rust, the more secure we will be. Our shells, coreutils, mail readers and web browsers have to be written in safer languages.

throwaway894345 5y ago
Also, far, far easier to build than all of these C programs with their own bespoke build systems and implicit dependency management. The more of the software stack that can be built by mere mortals, the better.
- rfoo 5y ago
  > far, far easier to build than all of these C programs One of my friends who work on AIX machines without direct Internet access does not share the same view, though.
  - throwaway894345 5y ago
    Why is indirect Internet access less of a problem for C than Rust/Go/etc? Seems like for modern systems, you just run a pre-populated caching proxy on your target and `cargo install` like you normally would. In C, you're manually checking versions and putting files in the right spot on disk for every stage of the build (this can be alleviated a bit if you can find pre-built binaries and so on, but even in the best case it's far behind "advanced" systems).
    - rfoo 5y ago
      > Why is indirect Internet access less of a problem for C than Rust/Go/etc? Because C codes tend to have less dependencies and shallow/more "clustered" dependency graph. To be fair, that's more or less due to dependency management being a 100% pain 0 fun experience.
      - throwaway894345 5y ago
        I agree with your characterization of the dependency graphs, but I don't see how that changes the calculus. Let's say in both cases you're copying a tarball of dependencies onto your friend's AIX machine--why is it harder to copy a tarball with a few large dependencies rather than a tarball with more small dependencies (I also posit that the Rust tarball would be smaller because you're less likely to be bringing in things you don't need--e.g., think of all the things curl does versus a straightforward HTTP lib)?
        rfoo 5y ago
        > a few large dependencies Unfortunately this does not match my experience :( Rust projects tend to depend on a lot of smaller, single-purposed (or, npm-y) dependencies, for example, Debian's ripgrep package has a X-Cargo-Built-Using saying: X-Cargo-Built-Using: rust-aho-corasick (= 0.7.10-1), rust-atty (= 0.2.14-2), rust-base64 (= 0.12.1-1), rust-bitflags (= 1.2.1-1), rust-bstr (= 0.2.12-1), rust-bytecount (= 0.6.0-1), rust-byteorder (= 1.3.4-1), rust-cfg-if-0.1 (= 0.1.10-2), rust-clap (= 2.33.3-1), rust-crossbeam-utils (= 0.7.2-2), rust-encoding-rs (= 0.8.22-1), rust-encoding-rs-io (= 0.1.6-2), rust-fnv (= 1.0.6-1), rust-globset (= 0.4.5-1), rust-grep-cli (= 0.1.5-1), rust-grep (= 0.2.7-1), rust-grep-matcher (= 0.1.4-1), rust-grep-pcre2 (= 0.1.4-2), rust-grep-printer (= 0.1.5-1), rust-grep-regex (= 0.1.8-1), rust-grep-searcher (= 0.1.7-1), rust-ignore (= 0.4.16-2), rust-itoa (= 0.4.3-1), rust-lazy-static (= 1.4.0-1), rust-libc (= 0.2.80-1), rust-log (= 0.4.11-2), rust-memchr (= 2.3.3-1), rust-memmap (= 0.7.0-1), rust-num-cpus (= 1.13.0-1), rust-pcre2 (= 0.2.3-1), rust-pcre2-sys (= 0.2.2-1), rust-regex-automata (= 0.1.8-2), rust-regex (= 1.3.7-1), rust-regex-syntax (= 0.6.17-1), rust-ryu (= 1.0.2-1), rust-same-file (= 1.0.6-1), rust-serde (= 1.0.106-1), rust-serde-json (= 1.0.41-1), rust-strsim (= 0.9.3-1), rust-termcolor (= 1.1.0-1), rust-textwrap (= 0.11.0-1), rust-thread-local (= 1.0.1-1), rust-unicode-width (= 0.1.8-1), rust-walkdir (= 2.3.1-1), rustc (= 1.48.0+dfsg1-2) Building it using cargo with Internet access is a breeze. Figuring out how to `cargo vendor` is not. And the sheer number of the dependencies makes it not practical to manually do stuff. In short, what cargo actively supports and everyone uses are great, otherwise it's disaster.
  - saghm 5y ago
    If the trade is getting proper memory safety for the 99.99% of code which never has to be built directly on a mainframe without internet access in exchange for the code that does have to be built on mainframes without internet access a bit harder, I think I'm fine with that.
- jschwartzi 5y ago
  Autotools is the de facto build system for most of the GNU system programs. The bit about dependency management mostly fits but I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy. It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use. Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case. At least with autotools its supported by default unless the library authors did something egregious like hard coding the sysroot or toolchain paths.
  - throwaway894345 5y ago
    EDIT: Just re-read the below and realized it might sound terse and argumentative; apologies, I was typing quickly and didn't mean to be combative. :) > I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy Crumby build systems force you to figure out how to build and install dependencies (or die trying). Modern build systems allow you to figure out how to build and install dependencies. If the former is "more UNIXy" than the latter, then I strongly contend that "UNIXy" is not a desirable property. > It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use. "Centralized" is irrelevant. Go's package manager is decentralized, for example. Moreover, many folks in the C world rely heavily on centralized repositories. Further, I would be shocked if manually managing your dependencies was somehow less error prone (and thus more secure) than having an expert-developed program automatically pull and verify your dependencies. > Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case. I mean, C doesn't care about anything, much less cross compilation. It puts the onus on the developer to figure out how to cross compile. Some build system generators (e.g., CMake, Autotools) purport to solve cross compilation, but I've always had problems. Maybe I just don't possess the mental faculties or years of experience required to master these tools, but I think that supports my point. By comparison, cross compilation in Go is trivial (set `CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build` works virtually every time from any platform). I haven't done much Rust cross-compilation, but I would be surprised if it were harder than C/C++.
- lucb1e 5y ago
  Honestly I don't like the build process of most go/rust/javascript software any better than C++. It's harder to find the dependencies for building the latter, but the former has its own version of dependency hell. I have real trouble building both types of projects, though admittedly (especially when the building instructions don't work when followed to the letter) C++ a bit more than the strategy of "everything is just pulled from github, you only have to make sure you've got gigabytes of free space in ~/.cache/, a build environment that was released in the past four to nine days, and have appropriate isolation or simply not care about potentially vulnerable or compromised code being run on your system". On a rare occasion, I will find a nice and small program using only standard libraries that compiles simply with `cc my.c && ./a.out` or runs simply with `python3 my.py`, demonstrating it doesn't depend on the language to have an easy time building it, but in both categories it's the exception for some reason. I see so much software that needs only standard libraries and runs on literally any python version released in the last decade, but to run it you have to setup some environment or globally install it with setuptools or something.
  - throwaway894345 5y ago
    > everything is just pulled from github I hear this a lot, but I can't divine any substance from it. Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers? Maybe this is a red herring and your real complaint is that the Rust ecosystem is less secure than the C/++ ecosystem? > you only have to make sure you've got gigabytes of free space in ~/.cache/ I cleared my $GOCACHE relatively recently (I thought maybe I had a cache issue, but I was mistaken), but it's currently at 75M while my .cargo directory weighs 704M. If these ever really got too big I would just `go clean -cache` and move on with life. If this is one of the biggest issues with Go/Rust/etc then I think you're arguing my point for me. > a build environment that was released in the past four to nine days What does this even mean? You can compile Go or Rust programs on any Linux machine with the build tools. On the contrary, C/C++ dependencies are very tightly coupled to the build environment. > have appropriate isolation or simply not care about potentially vulnerable or compromised code being run on your system Not sure about Rust programs, but Go programs absolutely don't run arbitrary code at compile/install time. C programs on the other hand absolutely do run arbitrary code (e.g., CMake scripts, Makefiles, random bash scripts, etc). > I see so much software that needs only standard libraries and runs on literally any python version released in the last decade, but to run it you have to setup some environment or globally install it with setuptools or something. Yeah, Python package management is a trashfire; however, this is entirely because it is so tightly coupled to C dependencies (many Python libraries are thin wrappers around various C programs, each with their own bespoke build system). Python package management tries to paper over the universe of C packages and it kind of works as long as you're on a handful of well-supported distributions and your dependencies have been well-vetted and well-maintained.
throwaway984393 5y ago
A century ago, buildings were quite dangerous, and likely to kill you in all sorts of situations. Wood burns, and concrete and brick don't. Clearly wood is an "unsafe material". But just changing the material didn't result in safer buildings. Buildings made of brick and concrete still killed people. It turns out that there are a lot of factors that go into building safety. The material is one vulnerability, sure. But there's also the connection method and strength, the calculated loads, shear forces, wind, earthquakes, egress, and a billion other considerations. What resulted in better building safety was the development of building codes. Even using flammable building materials, people adapted the way they built so that the end result was much safer than before. If you told a builder you'd never buy a wooden home because wood is "unsafe", they'd laugh at you - and then sell you a bunch of "inflammable" crap you don't need.
- saghm 5y ago
  > A century ago, buildings were quite dangerous, and likely to kill you in all sorts of situations. Wood burns, and concrete and brick don't. Clearly wood is an "unsafe material". But just changing the material didn't result in safer buildings. Buildings made of brick and concrete still killed people. This will seem trite, but I think it's just literally easier to figure out how to build wooden buildings that are fire resistant than it is to write memory safe code in C/C++.
  - throwaway984393 5y ago
    Well, it did take us a few thousand years to get to safe wooden buildings... I actually don't think securing C/C++ code is that hard. It's certainly a skill you need to learn, but so is writing linked lists and qsort. I think people just aren't applying themselves. But the language seems to catch the flack rather than the programmer. From the article: The bug is that there is simply no bounds checking at all; sig and key are arbitrary-length, attacker-controlled blobs, and cx->u is a fixed-size buffer. As we can see, the programmer just made no effort to secure the code. But we still blame the language, like blaming wood for being flammable. Anyway. I'm definitely not against new languages. But I think before a program is rewritten, it should be for a reason much better than "I didn't want to secure the code".

by _wldu 5y ago

The sooner we can rewrite our programs in Go and Rust, the more secure we will be. Our shells, coreutils, mail readers and web browsers have to be written in safer languages.

throwaway894345 5y ago

Also, far, far easier to build than all of these C programs with their own bespoke build systems and implicit dependency management. The more of the software stack that can be built by mere mortals, the better.

rfoo 5y ago
> far, far easier to build than all of these C programs One of my friends who work on AIX machines without direct Internet access does not share the same view, though.
- throwaway894345 5y ago
  Why is indirect Internet access less of a problem for C than Rust/Go/etc? Seems like for modern systems, you just run a pre-populated caching proxy on your target and `cargo install` like you normally would. In C, you're manually checking versions and putting files in the right spot on disk for every stage of the build (this can be alleviated a bit if you can find pre-built binaries and so on, but even in the best case it's far behind "advanced" systems).
  - rfoo 5y ago
    > Why is indirect Internet access less of a problem for C than Rust/Go/etc? Because C codes tend to have less dependencies and shallow/more "clustered" dependency graph. To be fair, that's more or less due to dependency management being a 100% pain 0 fun experience.
    - throwaway894345 5y ago
      I agree with your characterization of the dependency graphs, but I don't see how that changes the calculus. Let's say in both cases you're copying a tarball of dependencies onto your friend's AIX machine--why is it harder to copy a tarball with a few large dependencies rather than a tarball with more small dependencies (I also posit that the Rust tarball would be smaller because you're less likely to be bringing in things you don't need--e.g., think of all the things curl does versus a straightforward HTTP lib)?
      - rfoo 5y ago
        > a few large dependencies Unfortunately this does not match my experience :( Rust projects tend to depend on a lot of smaller, single-purposed (or, npm-y) dependencies, for example, Debian's ripgrep package has a X-Cargo-Built-Using saying: X-Cargo-Built-Using: rust-aho-corasick (= 0.7.10-1), rust-atty (= 0.2.14-2), rust-base64 (= 0.12.1-1), rust-bitflags (= 1.2.1-1), rust-bstr (= 0.2.12-1), rust-bytecount (= 0.6.0-1), rust-byteorder (= 1.3.4-1), rust-cfg-if-0.1 (= 0.1.10-2), rust-clap (= 2.33.3-1), rust-crossbeam-utils (= 0.7.2-2), rust-encoding-rs (= 0.8.22-1), rust-encoding-rs-io (= 0.1.6-2), rust-fnv (= 1.0.6-1), rust-globset (= 0.4.5-1), rust-grep-cli (= 0.1.5-1), rust-grep (= 0.2.7-1), rust-grep-matcher (= 0.1.4-1), rust-grep-pcre2 (= 0.1.4-2), rust-grep-printer (= 0.1.5-1), rust-grep-regex (= 0.1.8-1), rust-grep-searcher (= 0.1.7-1), rust-ignore (= 0.4.16-2), rust-itoa (= 0.4.3-1), rust-lazy-static (= 1.4.0-1), rust-libc (= 0.2.80-1), rust-log (= 0.4.11-2), rust-memchr (= 2.3.3-1), rust-memmap (= 0.7.0-1), rust-num-cpus (= 1.13.0-1), rust-pcre2 (= 0.2.3-1), rust-pcre2-sys (= 0.2.2-1), rust-regex-automata (= 0.1.8-2), rust-regex (= 1.3.7-1), rust-regex-syntax (= 0.6.17-1), rust-ryu (= 1.0.2-1), rust-same-file (= 1.0.6-1), rust-serde (= 1.0.106-1), rust-serde-json (= 1.0.41-1), rust-strsim (= 0.9.3-1), rust-termcolor (= 1.1.0-1), rust-textwrap (= 0.11.0-1), rust-thread-local (= 1.0.1-1), rust-unicode-width (= 0.1.8-1), rust-walkdir (= 2.3.1-1), rustc (= 1.48.0+dfsg1-2) Building it using cargo with Internet access is a breeze. Figuring out how to `cargo vendor` is not. And the sheer number of the dependencies makes it not practical to manually do stuff. In short, what cargo actively supports and everyone uses are great, otherwise it's disaster.
- saghm 5y ago
  If the trade is getting proper memory safety for the 99.99% of code which never has to be built directly on a mainframe without internet access in exchange for the code that does have to be built on mainframes without internet access a bit harder, I think I'm fine with that.
jschwartzi 5y ago
Autotools is the de facto build system for most of the GNU system programs. The bit about dependency management mostly fits but I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy. It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use. Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case. At least with autotools its supported by default unless the library authors did something egregious like hard coding the sysroot or toolchain paths.
- throwaway894345 5y ago
  EDIT: Just re-read the below and realized it might sound terse and argumentative; apologies, I was typing quickly and didn't mean to be combative. :) > I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy Crumby build systems force you to figure out how to build and install dependencies (or die trying). Modern build systems allow you to figure out how to build and install dependencies. If the former is "more UNIXy" than the latter, then I strongly contend that "UNIXy" is not a desirable property. > It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use. "Centralized" is irrelevant. Go's package manager is decentralized, for example. Moreover, many folks in the C world rely heavily on centralized repositories. Further, I would be shocked if manually managing your dependencies was somehow less error prone (and thus more secure) than having an expert-developed program automatically pull and verify your dependencies. > Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case. I mean, C doesn't care about anything, much less cross compilation. It puts the onus on the developer to figure out how to cross compile. Some build system generators (e.g., CMake, Autotools) purport to solve cross compilation, but I've always had problems. Maybe I just don't possess the mental faculties or years of experience required to master these tools, but I think that supports my point. By comparison, cross compilation in Go is trivial (set `CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build` works virtually every time from any platform). I haven't done much Rust cross-compilation, but I would be surprised if it were harder than C/C++.
lucb1e 5y ago
Honestly I don't like the build process of most go/rust/javascript software any better than C++. It's harder to find the dependencies for building the latter, but the former has its own version of dependency hell. I have real trouble building both types of projects, though admittedly (especially when the building instructions don't work when followed to the letter) C++ a bit more than the strategy of "everything is just pulled from github, you only have to make sure you've got gigabytes of free space in ~/.cache/, a build environment that was released in the past four to nine days, and have appropriate isolation or simply not care about potentially vulnerable or compromised code being run on your system". On a rare occasion, I will find a nice and small program using only standard libraries that compiles simply with `cc my.c && ./a.out` or runs simply with `python3 my.py`, demonstrating it doesn't depend on the language to have an easy time building it, but in both categories it's the exception for some reason. I see so much software that needs only standard libraries and runs on literally any python version released in the last decade, but to run it you have to setup some environment or globally install it with setuptools or something.
- throwaway894345 5y ago
  > everything is just pulled from github I hear this a lot, but I can't divine any substance from it. Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers? Maybe this is a red herring and your real complaint is that the Rust ecosystem is less secure than the C/++ ecosystem? > you only have to make sure you've got gigabytes of free space in ~/.cache/ I cleared my $GOCACHE relatively recently (I thought maybe I had a cache issue, but I was mistaken), but it's currently at 75M while my .cargo directory weighs 704M. If these ever really got too big I would just `go clean -cache` and move on with life. If this is one of the biggest issues with Go/Rust/etc then I think you're arguing my point for me. > a build environment that was released in the past four to nine days What does this even mean? You can compile Go or Rust programs on any Linux machine with the build tools. On the contrary, C/C++ dependencies are very tightly coupled to the build environment. > have appropriate isolation or simply not care about potentially vulnerable or compromised code being run on your system Not sure about Rust programs, but Go programs absolutely don't run arbitrary code at compile/install time. C programs on the other hand absolutely do run arbitrary code (e.g., CMake scripts, Makefiles, random bash scripts, etc). > I see so much software that needs only standard libraries and runs on literally any python version released in the last decade, but to run it you have to setup some environment or globally install it with setuptools or something. Yeah, Python package management is a trashfire; however, this is entirely because it is so tightly coupled to C dependencies (many Python libraries are thin wrappers around various C programs, each with their own bespoke build system). Python package management tries to paper over the universe of C packages and it kind of works as long as you're on a handful of well-supported distributions and your dependencies have been well-vetted and well-maintained.

throwaway984393 5y ago

A century ago, buildings were quite dangerous, and likely to kill you in all sorts of situations. Wood burns, and concrete and brick don't. Clearly wood is an "unsafe material". But just changing the material didn't result in safer buildings. Buildings made of brick and concrete still killed people. It turns out that there are a lot of factors that go into building safety. The material is one vulnerability, sure. But there's also the connection method and strength, the calculated loads, shear forces, wind, earthquakes, egress, and a billion other considerations. What resulted in better building safety was the development of building codes. Even using flammable building materials, people adapted the way they built so that the end result was much safer than before. If you told a builder you'd never buy a wooden home because wood is "unsafe", they'd laugh at you - and then sell you a bunch of "inflammable" crap you don't need.

saghm 5y ago
> A century ago, buildings were quite dangerous, and likely to kill you in all sorts of situations. Wood burns, and concrete and brick don't. Clearly wood is an "unsafe material". But just changing the material didn't result in safer buildings. Buildings made of brick and concrete still killed people. This will seem trite, but I think it's just literally easier to figure out how to build wooden buildings that are fire resistant than it is to write memory safe code in C/C++.
- throwaway984393 5y ago
  Well, it did take us a few thousand years to get to safe wooden buildings... I actually don't think securing C/C++ code is that hard. It's certainly a skill you need to learn, but so is writing linked lists and qsort. I think people just aren't applying themselves. But the language seems to catch the flack rather than the programmer. From the article: The bug is that there is simply no bounds checking at all; sig and key are arbitrary-length, attacker-controlled blobs, and cx->u is a fixed-size buffer. As we can see, the programmer just made no effort to secure the code. But we still blame the language, like blaming wood for being flammable. Anyway. I'm definitely not against new languages. But I think before a program is rewritten, it should be for a reason much better than "I didn't want to secure the code".