4 ms·

> This is freebsd-rustdate, a reimplementation of freebsd-update. > In usage, it’s expected to be similar, but not identical to freebsd-update. Doesn't reimpl

> This is freebsd-rustdate, a reimplementation of freebsd-update. > In usage, it’s expected to be similar, but not identical to freebsd-update. Doesn't reimplementing it to not be identical, defeat the point of reimplementing it? (since it can't be used as a drop-in replacement)

youwot0 2y ago
The ability to rewrite incompatible subsets of basic Unix utilities is where Rust truly shines.
- jchw 2y ago
  At the very least, the uutils project seems to be making good progress on becoming a "true" drop-in replacement for the GNU coreutils that will pass the GNU test suites and treat compatibility issues as bugs. Honestly though, as time goes on, I'm not sure if rewriting UNIX utilities to be memory-safe actually gets you that much. I mean, having multiple implementations of something as important as the coreutils is good: nobody complains about the co-existence of e.g. BSD and GNU utilities, and IMO there's really no reason to feel any different about RiiR rewrites. That said, I can't really figure out what attack model would really make memory safety a particular priority. In most cases you would be isolating things that require these sorts of utilities using namespaces/jails/etc, and I wonder if memory bugs in the coreutils is actually a serious attack vector. Of course in this case (FreeBSD-rustdate) it's literally for performance reasons rather than safety, so everything sort of makes sense (not necessarily using Rust for safety per-se, but for robust threading. That does make sense.)
  - iforgotpassword 2y ago
    I think libmagic (the file util) might be a good target for this. I think it had security issues in the past and considering how it contains a gazillion random parser for weird file formats, surely there is a good chance there are some more. But nobody would ever run file on a random file you just downloaded, would you? ;)
    - jchw 2y ago
      Yeah, something like that would probably be quite good. That said, I think even if you do have a nice memory-safe implementation of libmagic/file, it's probably a good idea to still use seccomp/namespacing/etc. to jail it when using it in security critical contexts. Those features don't really incur much cost so it's a free extra layer of security, and you still get the robustness bonus of guaranteed memory safety.
  - adamnemecek 2y ago
    It’s not just memory safety, it’s also hackability. Idk how I would go about adding a feature to ls (both GNU and BSD). I have a concrete idea of how I would go about adding a feature to the Rust implementation.
    - jchw 2y ago
      That doesn't sound very compelling: C is still a much more popular language than Rust and a lot simpler too. I realize the latter is somewhat subjective, but it's blatant enough that I'm willing to assert it confidently. If you want to know how to add a feature to ls in GNU coreutils, you don't have to look very far. The whole program is in src/ls.c. It's pretty large due to the amount of options, but it's pretty simple code all things considered. If you look at a program with less switches, like mkdir, it's even easier. https://github.com/coreutils/coreutils/blob/master/src/mkdir.c https://github.com/coreutils/coreutils/blob/master/src/mkdir... So what about FreeBSD? Well, not only does it have an official GitHub mirror, but it even accepts "simple" pull requests, apparently. And the implementation of ls is a bit more approachable, since BSD utilities typically don't have as much functionality. https://github.com/freebsd/freebsd-src/blob/main/bin/ls/ls.c https://github.com/freebsd/freebsd-src/blob/main/bin/ls/ls.c I don't think Rust is going to make things significantly more accessible. It does indeed draw people in and maybe make them less fearful versus C, but in practice a lot of the reason why contributing to these large projects is scary is nothing to do with the language and more to do with the arduous requirements of any project that is as complicated and widely used as they are. For example, does Rust actually make kernel development more accessible? Maybe not: > Despite more novice developers being attracted by Rust to the kernel community, we have found their commits are mainly for constructing Rust-relevant toolchains as well as Rust crates alone; they do not, however, take part in kernel code development. By contrast, 5 out of 6 investigated drivers (as seen in Table 5) are mainly contributed by authors from the Linux community. This implies a disconnection between the young and the seasoned developers, and that the bar of kernel programming is not lowered by Rust language. https://www.usenix.org/conference/atc24/presentation/li-hongyu https://www.usenix.org/conference/atc24/presentation/li-hong... So if you want to add a feature to ls, maybe you shouldn't wait for operating systems to switch to Rust alternatives. But when you think about it, it is not surprising that adding a feature to ls is not easy. I mean, you really wouldn't want new features being added to utilities like ls without a ton of care and thought put in, and that is true no matter what language the utility is written in. The difficulty of contributing to some projects has very, very little to do with the actual process of writing code.
  - Brian_K_White 2y ago
    I think it's worthwhile just to get better correctness, regardless of security. There is some project to write or re-write a cad engine in rust which I think is valuable not for any security reasons but just to get a less buggy cad engine, including easier to keep less buggy as work goes on for years. I wouldn't have thought freebsd-update was very high on the list of things in desperate need of an overhaul, but I'm willing to grant if the people working on it think it's worth their time, then it probably is.
    - johnisgood 2y ago
      > I think it's worthwhile just to get better correctness, regardless of security. Yeah, well, the Rust version of coreutils had lots of funny logic errors involving security.
      - Brian_K_White 2y ago
        Undeniable. However the fact that you can make a bad wall out of good bricks, and even a good wall out of bad bricks with enough care and effort and ingenuity, is orthogonal to the fact that good bricks are better than bad bricks.
        johnisgood 2y ago
        I mean, yeah, I agree, but is it really worth it? Should I use a Rust rewrite of coreutils that is in its infancy just because it is written in Rust and not C? If it was written in Ada / SPARK and it was formally verified, then yeah, I would definitely go for that rewrite of coreutils, but this is not the case with Rust.

youwot0 2y ago

The ability to rewrite incompatible subsets of basic Unix utilities is where Rust truly shines.

jchw 2y ago
At the very least, the uutils project seems to be making good progress on becoming a "true" drop-in replacement for the GNU coreutils that will pass the GNU test suites and treat compatibility issues as bugs. Honestly though, as time goes on, I'm not sure if rewriting UNIX utilities to be memory-safe actually gets you that much. I mean, having multiple implementations of something as important as the coreutils is good: nobody complains about the co-existence of e.g. BSD and GNU utilities, and IMO there's really no reason to feel any different about RiiR rewrites. That said, I can't really figure out what attack model would really make memory safety a particular priority. In most cases you would be isolating things that require these sorts of utilities using namespaces/jails/etc, and I wonder if memory bugs in the coreutils is actually a serious attack vector. Of course in this case (FreeBSD-rustdate) it's literally for performance reasons rather than safety, so everything sort of makes sense (not necessarily using Rust for safety per-se, but for robust threading. That does make sense.)
- iforgotpassword 2y ago
  I think libmagic (the file util) might be a good target for this. I think it had security issues in the past and considering how it contains a gazillion random parser for weird file formats, surely there is a good chance there are some more. But nobody would ever run file on a random file you just downloaded, would you? ;)
  - jchw 2y ago
    Yeah, something like that would probably be quite good. That said, I think even if you do have a nice memory-safe implementation of libmagic/file, it's probably a good idea to still use seccomp/namespacing/etc. to jail it when using it in security critical contexts. Those features don't really incur much cost so it's a free extra layer of security, and you still get the robustness bonus of guaranteed memory safety.
- adamnemecek 2y ago
  It’s not just memory safety, it’s also hackability. Idk how I would go about adding a feature to ls (both GNU and BSD). I have a concrete idea of how I would go about adding a feature to the Rust implementation.
  - jchw 2y ago
    That doesn't sound very compelling: C is still a much more popular language than Rust and a lot simpler too. I realize the latter is somewhat subjective, but it's blatant enough that I'm willing to assert it confidently. If you want to know how to add a feature to ls in GNU coreutils, you don't have to look very far. The whole program is in src/ls.c. It's pretty large due to the amount of options, but it's pretty simple code all things considered. If you look at a program with less switches, like mkdir, it's even easier. https://github.com/coreutils/coreutils/blob/master/src/mkdir.c https://github.com/coreutils/coreutils/blob/master/src/mkdir... So what about FreeBSD? Well, not only does it have an official GitHub mirror, but it even accepts "simple" pull requests, apparently. And the implementation of ls is a bit more approachable, since BSD utilities typically don't have as much functionality. https://github.com/freebsd/freebsd-src/blob/main/bin/ls/ls.c https://github.com/freebsd/freebsd-src/blob/main/bin/ls/ls.c I don't think Rust is going to make things significantly more accessible. It does indeed draw people in and maybe make them less fearful versus C, but in practice a lot of the reason why contributing to these large projects is scary is nothing to do with the language and more to do with the arduous requirements of any project that is as complicated and widely used as they are. For example, does Rust actually make kernel development more accessible? Maybe not: > Despite more novice developers being attracted by Rust to the kernel community, we have found their commits are mainly for constructing Rust-relevant toolchains as well as Rust crates alone; they do not, however, take part in kernel code development. By contrast, 5 out of 6 investigated drivers (as seen in Table 5) are mainly contributed by authors from the Linux community. This implies a disconnection between the young and the seasoned developers, and that the bar of kernel programming is not lowered by Rust language. https://www.usenix.org/conference/atc24/presentation/li-hongyu https://www.usenix.org/conference/atc24/presentation/li-hong... So if you want to add a feature to ls, maybe you shouldn't wait for operating systems to switch to Rust alternatives. But when you think about it, it is not surprising that adding a feature to ls is not easy. I mean, you really wouldn't want new features being added to utilities like ls without a ton of care and thought put in, and that is true no matter what language the utility is written in. The difficulty of contributing to some projects has very, very little to do with the actual process of writing code.
- Brian_K_White 2y ago
  I think it's worthwhile just to get better correctness, regardless of security. There is some project to write or re-write a cad engine in rust which I think is valuable not for any security reasons but just to get a less buggy cad engine, including easier to keep less buggy as work goes on for years. I wouldn't have thought freebsd-update was very high on the list of things in desperate need of an overhaul, but I'm willing to grant if the people working on it think it's worth their time, then it probably is.
  - johnisgood 2y ago
    > I think it's worthwhile just to get better correctness, regardless of security. Yeah, well, the Rust version of coreutils had lots of funny logic errors involving security.
    - Brian_K_White 2y ago
      Undeniable. However the fact that you can make a bad wall out of good bricks, and even a good wall out of bad bricks with enough care and effort and ingenuity, is orthogonal to the fact that good bricks are better than bad bricks.
      - johnisgood 2y ago
        I mean, yeah, I agree, but is it really worth it? Should I use a Rust rewrite of coreutils that is in its infancy just because it is written in Rust and not C? If it was written in Ada / SPARK and it was formally verified, then yeah, I would definitely go for that rewrite of coreutils, but this is not the case with Rust.