[Toybox] patch: add built-in versions of sha-2 family hash functions

Denys Vlasenko vda.linux at googlemail.com
Sat Jun 19 11:50:29 UTC 2021


On Tue, Jun 15, 2021 at 3:01 PM Rob Landley <rob at landley.net> wrote:
> The pending follow-up question to my previous email beyond "do you want this
> feature" was "are you willing to add it yourself, or do you want me to
> refamiliarize myself with busybox cut.c and whatever libbb sharp edges I hit
> enough to knock up a patch". I felt the odds of you implementing it yourself
> were higher if I DIDN'T offer a patch in the email, but if the busybox project
> only wants the feature if I provide a patch, yes I can provide that patch.

I would be quite happy if someone posts a patch.

> (You may remember I had a dim view of the FSF _before_ the Second Coming of RMS.
> Now that they've warmly embraced his post-#metoo self back into their ranks, I
> don't think I'm cynical ENOUGH about them.)
>
> >> and assumed it would be easier if both busybox
> >> and toybox already supported the same syntax.
> >
> > Yeah...
> >
> > What I worry about is gratuitous divergences we create.
>
> Hence us asking busybox if they wanted the new options, yes.

Yes, I would accept new options.

My point is, I would be happier with new options if coreutils
people would be at least semi-positive about having these
options as well. With the same option letters and syntax.

The situation of "oh no, fork XYZ added essentially the same
functionality too...but with other option letters, and they
count fields from 0, not from 1... and they used OUR option
letter for something entirely different! ARGH"
is irritatingly repeating itself, as if we never learn.


> So rather than add missing features (or fix incompatibilities) in the
> implementation busybox already had, you added a second implementation (alongside
> the other one, without removing it),

Yes. Because now we have users of this other, incompatible implementation,
and if they upgrade bbox and their scripts break, they will be rightly
pissed off.

This is one facet of the incompatibility landmines: they are so
innocuous-looking
in their infancy. "I can add this useful option, what can possibly go wrong?
People who don't need it will simply not use it!"

Right now, with these proposed options, we are doing EXACTLY this.


> with no additions to the test suite or
> other documentation of the use cases motivating its addition, reasons you had
> already forgotten by the time I noticed and asked ~3 years later.

Trying to recall... I found my old posts about nc:
https://seclists.org/nmap-dev/2010/q1/44
https://seclists.org/nmap-dev/2010/q1/42
https://sourceforge.net/p/netcat/bugs/37/

TL;DR: (at the time of me writing these comments in 2010,) OpenBSD, GNU
and Nmap's reimplementations of nc were *mutually* incompatible. Not only
they broke trivial use cases like "nc -l -p PORT", they broke them
in different ways!

This should not be happening. People who code Unix utilities should not
be this oblivious to what happens in real world when people try to use
their tools. I get it that some developers were never wearing
an admin hat in their careers, but still...


More information about the busybox mailing list