Re: Weirdness in /bin/sh of 8.0

[Izaac <izaac%setec.org@localhost>]

On Tue, Aug 14, 2018 at 10:47:16PM +0000, maya%netbsd.org@localhost wrote:
> I for one strongly appreciate that:
> - /bin/sh now has great test coverage

Agreed.

> - Said testsuite runs without a complaint from sanitizers
>   (all ~400 test cases!)

... agreed.

> - I can now apply patches that were blocked due to the
>   aforementioned sh bug, that was existing in older netbsd sh too.
>   It was:
>   https://gnats.netbsd.org/52687 -- the bug

This was not a bug.  Christos is 10-% correct in his initial reply.  If
you expect a different behaviour, you do not understand UNIX file
descriptors or the operation of command interpreters.

>   https://gnats.netbsd.org/52684 -- Patch blocked by bug, becuase then
>   it would always warn that "pkg" is not found.

So your solution is not to search the PATH for the binary, but to change
the very nature of file descriptor handling in one of the most
fundamental utilities at the core of BSD UNIX?

That is madness.

> - kre has been helping with every single sh-related oddity within
>   pkgsrc, even when they weren't always problems in sh.

Laudable on his part.  But none are problems in sh.  Period.
Generations which came before you accomplished greater feats with the
same or lessor utility.  You have a very high bar to clear if you want
to claim that their tool has been broken all this time.

> I've seen cases of people having to deal with code that was supposedly
> working perfectly fine and then not touched for a long time. It's not
> pretty. We had sh bugs. kre is fixing them.

Again this assertion.  Where is the mountain of /bin/sh core files?
Where are the less-than-ten-line example scripts which demonstrate
aberrant behavior?  Nowhere I can find.

This notion of "there are bugs" is a thin, poorly conceived cover to
justify one man's hobby-tinkering at the expense of the entire user
base.

> Nobody is stopping you from running older /bin/sh on newer netbsd. It
> will even run with no modification whatsoever. Just swap out the binary.

I grow very tired of hearing this dismissal.

First, we have absolutely no system provided means by which to
accomplish this.  There is no system utility versioning, let alone
pinning.  The variety of items which much be altered to accomplish it,
e.g. libraries (because for some unfathomable reason our /bin/sh isn't
statically linked), mtree, veriexec, etc., is broad and fraught with
potential for error.  It is an elaborate hack.

Second, the maintenance of such a hack is expensive.  Anyone
accomplishing such a thing (especially of such a core utility at the
heart of an expansive web of dependencies) is de facto off the release
train.  Their desire to continue upgrade is reduced significantly.  This
leads to version lock-in, atrophy, and eventual abandonment of the
platform.

Third, and most important, why is the onus upon me?  Every change is a
risk, diminishes confidence, and instigates a recalculation of
cost/benefit.  In other words, changes create work for administrators.
What is the benefit associated with this new shell to justify the cost
of re-evaluation and re-certification?  Is there a security-related fix?
Are these legitimate bugs which prevent the operation of the NetBSD
system?  Is there some feature which makes it worthwhile?  I can
identify none of these -- and yet I am compelled as a user interest in
upgrade to accept this risk and cost.  That is wrong.

The burden is instead upon the one making the changes, causing the
increased risk, diminishing confidence, and generating work for others
to justify his actions.

> In pkgsrc for other operating systems we have to swap out their
> "perfectly working" /bin/sh, that result in subtle and time-consuming
> bugs.

There is an awful lot wrong with pkgsrc upon which you cannot blame the
target environment.

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__