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

["Thomas Mueller" <mueller6725%twc.com@localhost>]

from Robert Elz:

    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

What do you use instead of pkg_rolling-replace, while waiting for portupgrade and portmaster to be imported from FreeBSD ports (wishful thinking)?

What do you do when you want to update many packages?

pkg_rolling-replace was stopped when an earlier version of a package was installed, failed to do "make update" or "make replace" which I thought pkg_rolling-replace was supposed to do automatically.

Was graphics/graphite2 one of the packages seen to have problems?  Trying to configure that segfaulted and dumped core, no informative log.

My last system update dates were Jun 14 (i386) and Jun 11 (amd64), within the vulnerable time for /bin/sh bugs.

After update, I could try pkg_rolling-replace again on somewhat messed-up system to see if there is any improvement.

I have one installation, amd64, where no packages are yet installed, a strongly tempting target for John Marino's synth.

Synth is written in Ada and compiled, not a shell script, but might still be safer with /bin/sh in working order.  I wouldn't want to judge synth badly when the fault is with /bin/sh.

Tom