Re: HEADS-UP: /bin/sh memory management bug fixes committed

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 18 Jun 2017 07:16:55 +0000
    From:        "Thomas Mueller" <mueller6725%twc.com@localhost>
    Message-ID:  <D4.70.03935.CE826495@dnvrco-omsmta01>

  | I guess bugs in sh could affect a run with pkg_rolling-replace
  | and other updates using pkgsrc?

I've never used pkg_rolling_replace so I'm not sure exactly what it
does - if it is one of the versions that fetches and installs binary
packages that have been compiled elsewhere, then I think you can feel
safe enough with that - it might be possible that sometimes it (that is p_r_r)
will fail to operate correctly because of a shell bug, but if it does the
result will be a package not installed, not a broken one installed.

If it is a method to build packages from pkgsrc (and any other way
of building locally from source) then the usual effect of the broken
shell would be to stop the package building - very few packages install
sh scripts (let alone ones generated on the fly) so the shell has very
little influence on anything beyond configuring the package.

But packages that failed to build (several were seen to have problems)
were certainly possible.

Anything that is just compiled C (or C++ or python, etc) code which
built and installed correctly is not going to have a problem, the shell
is an important program, but it isn't *that* important, the compilers,
linkers, etc, all work just the same whatever the shell is doing.

  | I suppose strange things can happen?

Yes.

  | Am I advised to rebuild my system (i386 and amd64) using build.sh
  | after "cvs up -dP -A"?

If it built correctly, then no, that should not be needed (not that it should
do any harm - several other updates have been done in the past wee, re-building
would get you newer versions of other systems).

But I would advise you to install (at least) a new /bin/sh

The (or an) easy way to do that, is just to go to src/bin/sh
(after that has been updated)

	cd .../usr/bin/sh
	mkdir /tmp/sh
	cp -rp . /tmp/sh
	cd /tmp/sh
	USETOOLS=no  make
		(then after it succeeds, < 2 mins probably, as root)
	cp sh /bin/sh.new
	mv /bin/sh /bin/sh.save && mv /bin/sh.new /bin/sh
		(you could install the updated sh.1 if you want,
			but that is not important)
		(then back as a normal user)
	cd /tmp
	rm -fr sh

(the copy to /tmp rigmarole is just to avoid messing up /usr/src, as this
way of building puts .o files (etc) in the current directory.)

Be careful with the two commands executed as root, leaving the system
without a working (or mostly working) /bin/sh is not a good state to have.
The rest you can do as many times as you need until it is all right.

  | I will still have the dubious /bin/sh from just this past week.

Unless you have replaced it today, if you installed a version more recent
than June 7 (I think it was, just under 2 weeks ago) then yes, it is
likely broken (actually, any from any time in the past would be broken
this same way - the changes made it more likely that the bug would manifest
itself, they did not cause it.)   The other bugs that I actually added
2 weeks ago were much more blatant, if you (or some script) did the thing
that caused a problem, it would simply break badly, very little chance for
any subtle errors with those ones.

  | Or should I rebuild twice, the second time being with the new /bin/sh,
  | or is that overkill?

Overkill.   If the system is working, there's no need to rebuild it, sh
bugs might have prevented it building, but are very unlikely to cause it
to appear to successfully build, and yet be corrupted.

Note that the worst of the bugs was a very rare one, it took exactly the
right set of circumstances to set it off - for most uses, the shell would
work just fine.

kre