Date: Sun, 18 Jun 2017 07:16:55 +0000 From: "Thomas Mueller" <mueller6...@twc.com> 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