On 2022-01-06 at 17:03 -0500, Chet Ramey wrote: > On 1/3/22 6:02 PM, Ángel wrote: > > > Or, an even simpler one (assuming a utf-8 locale, like almost > > everyone uses these days): > > $ printf "%511s\xc3\xa4" | ./bash -c 'a="$(echo a)"; d=$(cat); echo > > "$d"' | sed 's/^ *//' > > Ö� > > > > where it should have output: > > ä > > Even with this reproducer, I was unable to get it to happen on RHEL7 with > an unpatched bash-5.1 (en_US.UTF-8, de_DE.UTF-8). I was never able to get > it to happen using Frank's test case. It doesn't seem easy to > reproduce.
Apparently it doesn't like being reproduced. > > As for patching the systems, I think this deserves being patched even > > on stable distros. Albeit I would prefer that Chet released an official > > patch first. > > I did. The question is what the distros do with it. The example Frank > used -- Debian stable -- was 8 patches behind when he sent the report, and > is 12 behind now. Whether or not we think patches `deserve' to be applied > by the distros doesn't seem to count for much. > > Chet I saw it. Thanks, Chet. Yes, it's now the distros that should do their part. Our own assessments should probably match in most cases, but the maintainer might disagree and consider certain changes not worth applying according to their own policies. A few days ago ftp.gnu.org wasn't showing a tarball for 5.1.12, the last one was 5.1.8 one. Even if that confused them, bash 5.1 in debian stable is still at patchset 4. Debian testing was updated, though, and the last patches are already in sid. I haven't make my mind^W^W^W^W have looked at the other patches and this one (patch 14) seems the most critical. Patchset 9 as well if the crash happens in the systemd version shipped in Debian stable. Regards
