Re: Corrupted multibyte characters in command substitutions

[Ángel]

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