[I changed the subject line because this is quite a tangent from the
original thread]

On Wed, May 15, 2024 at 7:50 PM Nikolaos Chatzikonstantinou <
nchatz...@gmail.com> wrote:

>
> How about GNU does a call to arms for an alternative Rust
> implementation of its coreutils? There's still hungry Rust devs out
> there willing to write a lot of code to prove themselves.
>

A Rust-based coreutils implementation would do nothing for find, since it's
not part of coreutils.   In this email I'm mainly going to discuss
findutils.  I'm not a maintainer of coreutils and can't speak for the folks
who are, really.  Although I am a maintainer of findutils, I'm not the only
one, and so what I'm writing here is just a personal opinion, not the
response from the "findutils maintainer team" at all.

I haven't looked at this for a long time, but when I did look at the
coreutils implementation, I was left with the impression that the team's
engineering trade-offs favoured using standard Rust library interfaces over
native operating system (i.e. FFI) interfaces.

For security above all reasons, findutils has preferred native interfaces
and gnulib's implementations/wrappers.   The advantage of using gnulib for
things like fts is that findutils is not the only consumer, and we're very
likely to notice issues with it even in weird corner cases.  I find it a
bit hard to imagine a Rust-based implementation correctly implementing GNU
find's "-regex" without using gnulib as the regex implementation, for
example.

Find in particular needs to be able to work correctly in odd situations
where even library implementers would often just shrug and say those cases
are not in-scope.  For example,

   - Where the current directory is above the root directory "/"
   - Where the current directory contains an infinite loop of hard links
   - Where the file system being searched is an active target of symlink
   race attacks
   - Where the current user lacks the search permission for the current
   directory (but does not lack read permission)
   - Where the current user lacks the read permission for the current
   directory (but does not lack search permission)
   - Where entries in /etc/fstab exist  for which a stat or statvfs call
   will hang forever

 If a Rust-based-find team was serious about making a 100% drop-in backward
compatible find implementation that would prioritise working securely and
correctly on the GNU system over other considerations, then there's a
discussion worth having.

Flipping back to coreutils for a moment, the Rust-coreutils folks are
aiming for feature compatibility, but that's not the same thing as being a
completely faithful drop-in replacement.  Maintainers of GNU core tools
(not just coreutils, other things too) are very, very careful about
breaking their callers[*].  There are cases with find, for example, where
the deprecation-to-removal timeline is 5 years+ (example: -perm +...).
 I'm struggling to imagine that the Rust coreutils folks will really buy
into this kind of approach.  They're using Clap as the command-line parser
for example.  Now, actually I like Clap and there are projects where I've
used it.   But it's a stretch to imagine that it's going to parse arguments
in precisely the same way as getopt_long() in all cases.   So I find it
hard to imagine that the two suites will ever be close enough in behaviour
for either team to consider them aligned.   Though of course I can imagine
some (obviously not all: nothing is ever "all") distributions electing to
switch even without this kind of drop-in-replacement compatibility.

[*] probably my most memorable mistake was in making `find . -name foo
-maxdepth 2` generate a warning message.   A mistake even though the stdout
output is identical.

Please don't get the idea though that I'm against Rust.  I think that, yes,
new tools should often be written in it.  But that's a very different
question from replacing an existing tool, because compatibility is a hard
problem.

James.

Reply via email to