collinfunk

Hi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually.

I just want to mention that I disagree with the section titled "Rule: Resolve Paths Before Comparing Them". Generally, it is better to make calls to fstat and compare the st_dev and st_ino. However, that was mentioned in the article. A side effect that seems less often considered is the performance impact. Here is an example in practice:

  $ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
  $ while cd $(yes a/ | head -n 1024 | tr -d '\n'); do :; done 2>/dev/null
  $ echo a > file
  $ time cp file copy

  real 0m0.010s
  user 0m0.002s
  sys 0m0.003s
  $ time uu_cp file copy

  real 0m12.857s
  user 0m0.064s
  sys 0m12.702s

I know people are very unlikely to do something like that in real life. However, GNU software tends to work very hard to avoid arbitrary limits [1].

Also, the larger point still stands, but the article says "The Rust rewrite has shipped zero of these [memory saftey bugs], over a comparable window of activity." However, this is not true [2]. :)

[1] https://www.gnu.org/prep/standards/standards.html#Semantics [2] https://github.com/advisories/GHSA-w9vv-q986-vj7x

> There are some pretty substantial differences. Russia is on the strategic back foot here trying to figure out a way to stop NATO's advance.

His rationale for invading Ukraine was to "demilitarise and denazify" it. The NATO point seems largely be invented by people who dislike NATO in the west.

> They've only turned to violence after long attempts at resolving the tension diplomatically and the US has been implacable.

I hope the "tension" you are referring to was not the little green men taking over Crimea and the Donbas in 2014.

> Putin's actually been pretty hesitant in his escalations so far; he's 70 and has a long history of trying to avoid war.

This is a totally unseriousness statement. Can you remind me what Putin was doing in Syria again?

You see zero similarities between Hitler invading Poland and Putin invading Ukraine?

Another maintainer and I follow issues and pull requests on a GitHub mirror. But email works fine for us and many other projects.

Regarding poor UX, it is difficult to dispute with that claim without a specific example. Note that a lot of the features we support are standardized by POSIX. Even if we dislike the behavior, it is better to comply with the standards so the programs don't behave differently than users expect. The sentence you quote isn't meant to put down users. These programs are often much more complex than meets the eye, and there are lots of common gotchas that people have run into (and will continue to do so) [1].

Of course we would love for these programs to be useful for everyone. However, feature requests are often incompatible with existing behavior, incompatible with other feature requests, or have existing functionality elsewhere. For those reasons we cannot accept every feature request.

[1] https://www.pixelbeat.org/docs/coreutils-gotchas.html

Well the TOCTOU issues do not require you to run untrusted scripts to be exploited. Another user on your system can use a legitimate command that you may run to make changes to files they shouldn’t be able to, or further escalate privileges.

I am one of them. The title of the substack seems fine since it mentions "if you use iTerm2".

The tweet has no mention of iTerm2 which makes it sound like an issue in 'cat', which is mildly annoying [1].

[1] https://x.com/calif_io/status/2045207168677503241

fileutils-1.0 was released in 1990 [1]. shellutils-1.0 was released in 1991 [2], and textutils-1.0 was released a month later in the same year [3].

Those three packages were combined into coreutils-5.0 in 2003 [4].

[1] https://groups.google.com/g/gnu.utils.bug/c/CviP42X_hCY/m/Ys... [2] https://groups.google.com/g/gnu.utils.bug/c/xpTRtuFpNQc/m/mR... [3] https://groups.google.com/g/gnu.utils.bug/c/iN5KuoJYRhU/m/V_... [4] https://lists.gnu.org/archive/html/info-gnu/2003-04/msg00000...

The bar for adding new options, especially short options, is quite high for coreutils. We have a (likely outdated) page of rejected requests [1]. Some of the changes people have strong feelings about...

[1] https://www.gnu.org/software/coreutils/rejected_requests.htm...

I don't think this addresses the main point of my question, though. Do you know any prominent Democrats, e.g., representatives, senators, or presidents, who have called for a Republican to be killed?

Even if one grants that it is a small minority, aren't they still voting for someone who advocates for jailing and killing political opponents?

Trump appointed him. Do you put not blame on him for choosing "uniparty birds" and "shades of grifters"? Or do you live in his colon.

It seems like they learned a lot from the Letitia James and James Comey cases, which are going great (not in the way they intended).

Haven't read it since it is down, but based on other comments, it seems to be an issue with cleartext signatures.

I haven't seen those outside of old mailing list archives. Everyone uses detached signatures nowadays, e.g. PGP/MIME for emails.

MacOS's utilities are really just FreeBSD's with some patches.

https://github.com/apple-oss-distributions/text_cmds https://github.com/apple-oss-distributions/system_cmds https://github.com/apple-oss-distributions/file_cmds https://github.com/apple-oss-distributions/adv_cmds https://github.com/apple-oss-distributions/shell_cmds https://github.com/apple-oss-distributions/misc_cmds

FreeBSD 6.0 added 'env -S'. They have adopted a few different GNU inspired options recently, which I am happy about.

Yes, linking LLVM takes up a lot of memory. The documented guidance is to allow one link job per 15 GB of RAM [1].

[1] https://llvm.org/docs/CMake.html#frequently-used-llvm-relate...

A lot of the complexity is to handle localized date formats on systems that support them. Most other implementations of 'date' do not do this.

The easiest way to see this is in US locales, which use 12-hour clocks in GNU 'date' but not other implementations:

  $ date -d '13:00'
  Sat Nov  1 01:00:00 PM PDT 2025
  $ uu_date -d '13:00'
  Sat Nov  1 13:00:00 2025

I added a test case for that recently, since it is a nice usability feature [1].

[1] https://github.com/coreutils/coreutils/commit/1066d442c2c023...

2 GNU coreutils maintainers, including myself, monitor the issues and PRs on a GitHub mirror that we have [1]. Generally the mailing list is preferred though, since more people follow it.

[1] https://github.com/coreutils/coreutils

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.ht... [2] https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.ht...

Minor correction, but that bug was never in any "official" coreutils release. The bug was in a multi-byte character patch that many distributions use (and still use). There have been other CVEs in that patch [1].

But the worst you can do is crash 'sort' with that. Note that uutils also has crashes. Here is one due to unbounded recursion:

  $ ./target/release/coreutils mkdir -p `python3 -c 'print("./" + "a/" * 32768)'`
  Segmentation fault (core dumped)

Not saying that both issues don't deserve fixing. But I wouldn't really panic over either of them.

[1] https://lwn.net/Articles/535735/

> 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.

> While half of the language design of C is questionable and outright dangerous, making its functions locale-sensitive by all popular OSes was an avoidable mistake. Yet everybody did that. Just the existence of this behavior is a reason I would like to get rid of anything GNU-based in the systems I develop today.

POSIX requires that many functions account for the current locale. I'm not sure why you are blaming GNU for this.

Note that uutils does not work if the file does not fit into memory.

With GNU coreutils:

   $ base64 /dev/zero | head -c 1 | wc -c
   1

With uutils doing the same would exhaust your systems memory until either it freezes or oomd kills the process.

Ah, I should have guessed from the program name. :)

I thought I remember Go having pretty optimized assembly for crypto routines. But I have not used the language much. If you have your source code uploaded somewhere I'd be interested to have a look to see what I am missing out on.

Interesting, there must be something wrong here. Here is a benchmark using the same commit and default options other than adjusting '--with-openssl=[yes|no]':

  $ dd if=/dev/random of=input bs=1000 count=$(($(echo 10G | numfmt --from=iec) / 1000))
  10737418+0 records in
  10737418+0 records out
  10737418000 bytes (11 GB, 10 GiB) copied, 86.3693 s, 124 MB/s
  $ time ./src/sha256sum-libcrypto input 
  b3e702bb55a109bc73d7ce03c6b4d260c8f2b7f404c8979480c68bc704b64255  input

  real 0m16.022s
  $ time ./src/sha256sum-nolibcrypto input 
  b3e702bb55a109bc73d7ce03c6b4d260c8f2b7f404c8979480c68bc704b64255  input

  real 0m39.339s

Perhaps there is something wrong with the detection on your system? As in, you do not have this at the end of './configure':

  $ grep -F 'HAVE_OPENSSL_' lib/config.h
  #define HAVE_OPENSSL_MD5 1
  #define HAVE_OPENSSL_MD5_H 1
  #define HAVE_OPENSSL_SHA1 1
  #define HAVE_OPENSSL_SHA256 1
  #define HAVE_OPENSSL_SHA3 1
  #define HAVE_OPENSSL_SHA512 1
  #define HAVE_OPENSSL_SHA_H 1

Yep, from a Void Linux container it appears that they do not link to libcrypto:

  $ ldd /usr/bin/cksum
   linux-vdso.so.1 (0x00007fb354763000)
   libc.so.6 => /usr/lib64/libc.so.6 (0x00007fb354549000)
   /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fb354765000)

For context, I am a committer to GNU Coreutils. We have used OpenSSL by default for a few years now [1]. Previously it was disabled by default because the OpenSSL license is not compatible with the GPL license [2]. This was resolved when they switched to the Apache License, Version 2.0 in OpenSSL 3.0.0.

If the Void people wanted to enable OpenSSL, they would probably just need to add openssl (or whatever they package it as) to the package dependencies.

[1] https://github.com/coreutils/coreutils/commit/0d77e1b7ea2840... [2] https://www.gnu.org/licenses/license-list.html#OpenSSL

What distribution do you use?

GNU Coreutils uses the OpenSSL implementation of hashes by default, but some distributions have disabled it using './configure --with-openssl=no'. Debian used to do this, but now links to OpenSSL.

You would not be able to find the first commit. The repositories for Fileutils, Shellutils, and Texutils do not exist, at least anywhere that I can find. They were merged as Coreutils in 2003 in a CVS repository. A few years later, it was migrated to git.

If anyone has original Fileutils, Shellutils, or Textutils archives (released before the ones currently on GNU's ftp server), I would be interested in looking at them. I looked into this recently for a commit [1].

[1] https://www.mail-archive.com/coreutils@gnu.org/msg12529.html

You can also hide it in the sidebar. I did that and forgot it existed for the most part.

He also sued The Des Moines Register because they released a poll that he did not like [1]. It is sad that people defend this.

[1] https://www.nytimes.com/2024/12/17/us/politics/trump-sues-de...