3 ms·

You don't attack coreutils. You attack the scripts. In this case it was an update script that failed because of an incompatibility. It's not too hard at all

by ajross 1y ago

You don't attack coreutils. You attack the scripts. In this case it was an update script that failed because of an incompatibility. It's not too hard at all to imagine one failing in an exploitable way. Honestly, Rust-related hilarity aside, this project was a terrible, terrible idea. Unix shell environments have always been ad hoc and poorly tested, and anything that impacts compatibility is going to break historical code that may literally be decades old. See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.

johnny22 1y ago
and yet coreutils continues to receive updates in ways that could break things.
collinfunk 1y ago
> See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks. The 'fgrep' and 'egrep' didn't throw errors, it would just send a warning to standard error before behaving as expected. Those commands were never standardized, and everyone is better off using 'grep -F' and 'grep -E' respectively.
- ajross 1y ago
  > didn't throw errors, it would just send a warning to standard error Noted without comment. Except to say that I've had multiple scripts of my own break via "just" discovering garbage in the output streams. > Those commands were never standardized "Those commands" were present in v7 unix in 1979!
  - larusso 1y ago
    I think he means POSIX. Didn’t check but in some cases posix only covers some options a tool provides not all. It’s a hard lesson I learned while keeping shell scripts portable between Linux and macOS.
    - collinfunk 1y ago
      Yep. I was slightly incorrect in my original message, though. SUSv2 (1997) specified egrep and fgrep but marked them LEGACY. POSIX.1-2001 removed them. The only place that that doesn't support 'grep -E' and 'grep -F' nowadays is Solaris 10. But if you are still using that you will certainly run into many other missing options. [1] https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.html https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.ht... [2] https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.html https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.ht...
      - ajross 1y ago
        "GNU grep implemented a change that breaks pre-existing scripts using a 46 year old API, but it's OK because the required workaround works everywhere but Solaris 10" seems like not a great statement of engineering design to me.
        1718627440 1y ago
        "GNU grep added a warning to inform you of the deprecation which happened 28 years ago, but only to stderr, and still works like you expect", does to me.
        ajross 1y ago
        Meh. Look, it broke code. "Still works like you expect" is 100% false. The deprecation argument is at least... arguable. It was indeed retired from POSIX. But needless deprecation is itself a smell in a situation where you can't audit all the code that uses it. Don't do that. It breaks stuff. It broke the updates in the linked article too. If you have an API, leave it there absent extremely strong arguments for its removal.
JuniperMesos 1y ago
This is not a rousing endorsement of the Unix shell environment. Maybe that should be rewritten in something else too (probably not Rust, Rust is probably not a good choice for this - but something that is designed in such a way that it is easy to test would be nice!).
- viraptor 1y ago
  There's nothing about rust that makes things hard to test. Actually the embedded test framework makes it easier than C. But what really matters is the public interface of those tools and that's got an extensive test suite available. It doesn't matter which language is used internal for those tests to run.
  - JuniperMesos 1y ago
    I meant that Rust is probably not a good choice for a new shell scripting environment, not that Rust is hard to test. I was responding to the claim "Unix shell environments have always been ad hoc and poorly tested", which is a bad thing and is worth fixing in and of itself.
    - viraptor 1y ago
      > not a good choice for a new shell scripting environment Why?
- ajross 1y ago
  > This is not a rousing endorsement of the Unix shell environment. It's surely not. The question wasn't how to rewrite the shell environment to be more "endorseable", though. The point is that we have a half century (!) long history of writing code to this admittedly fragile environment, with no way to audit usage or even find all the existing code (literally many of the authors are retired or dead). So... it's just not a good place to play games with "Look Ma, I rewrote /usr/bin/date and it's safe now!" Mess with your own new environments, not the ones that run the rest of the world please.

by ajross 1y ago

johnny22 1y ago

and yet coreutils continues to receive updates in ways that could break things.

collinfunk 1y ago

> See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks. The 'fgrep' and 'egrep' didn't throw errors, it would just send a warning to standard error before behaving as expected. Those commands were never standardized, and everyone is better off using 'grep -F' and 'grep -E' respectively.

ajross 1y ago
> didn't throw errors, it would just send a warning to standard error Noted without comment. Except to say that I've had multiple scripts of my own break via "just" discovering garbage in the output streams. > Those commands were never standardized "Those commands" were present in v7 unix in 1979!
- larusso 1y ago
  I think he means POSIX. Didn’t check but in some cases posix only covers some options a tool provides not all. It’s a hard lesson I learned while keeping shell scripts portable between Linux and macOS.
  - collinfunk 1y ago
    Yep. I was slightly incorrect in my original message, though. SUSv2 (1997) specified egrep and fgrep but marked them LEGACY. POSIX.1-2001 removed them. The only place that that doesn't support 'grep -E' and 'grep -F' nowadays is Solaris 10. But if you are still using that you will certainly run into many other missing options. [1] https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.html https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.ht... [2] https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.html https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.ht...
    - ajross 1y ago
      "GNU grep implemented a change that breaks pre-existing scripts using a 46 year old API, but it's OK because the required workaround works everywhere but Solaris 10" seems like not a great statement of engineering design to me.
      - 1718627440 1y ago
        "GNU grep added a warning to inform you of the deprecation which happened 28 years ago, but only to stderr, and still works like you expect", does to me.
        ajross 1y ago
        Meh. Look, it broke code. "Still works like you expect" is 100% false. The deprecation argument is at least... arguable. It was indeed retired from POSIX. But needless deprecation is itself a smell in a situation where you can't audit all the code that uses it. Don't do that. It breaks stuff. It broke the updates in the linked article too. If you have an API, leave it there absent extremely strong arguments for its removal.

JuniperMesos 1y ago

This is not a rousing endorsement of the Unix shell environment. Maybe that should be rewritten in something else too (probably not Rust, Rust is probably not a good choice for this - but something that is designed in such a way that it is easy to test would be nice!).

viraptor 1y ago
There's nothing about rust that makes things hard to test. Actually the embedded test framework makes it easier than C. But what really matters is the public interface of those tools and that's got an extensive test suite available. It doesn't matter which language is used internal for those tests to run.
- JuniperMesos 1y ago
  I meant that Rust is probably not a good choice for a new shell scripting environment, not that Rust is hard to test. I was responding to the claim "Unix shell environments have always been ad hoc and poorly tested", which is a bad thing and is worth fixing in and of itself.
  - viraptor 1y ago
    > not a good choice for a new shell scripting environment Why?
ajross 1y ago
> This is not a rousing endorsement of the Unix shell environment. It's surely not. The question wasn't how to rewrite the shell environment to be more "endorseable", though. The point is that we have a half century (!) long history of writing code to this admittedly fragile environment, with no way to audit usage or even find all the existing code (literally many of the authors are retired or dead). So... it's just not a good place to play games with "Look Ma, I rewrote /usr/bin/date and it's safe now!" Mess with your own new environments, not the ones that run the rest of the world please.