Your message dated Mon, 24 Jun 2024 13:24:01 +0200
with message-id <[email protected]>
and subject line Re: /bin/bash: Apparent encoding-bug in Debian patches to Bash
v5.2.15
has caused the Debian Bug report #1074164,
regarding /bin/bash: Apparent encoding-bug in Debian patches to Bash v5.2.15
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1074164: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074164
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: bash
Version: 5.2.15-2+b2
Severity: normal
File: /bin/bash
Dear Maintainer,
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
The answer to all of the above is in the reproducer below.
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
While experimenting with an exact byte reader/writer Bash function I
seem to have uncovered a
bug either introduced by the Debian patches to v5.2.15 (or perhaps
existing in a linked library?).
The below reproducer should be self-explanatory in context of
different runs. I also tried
installing v5.2.15-2+b7 from Bookworm-Proposed-Updates but the issue
persists there too.
While experimenting with an exact byte reader/writer Bash function I
seem to have uncovered a
bug either introduced by the Debian patches to v5.2.15 (or perhaps
existing in a linked library?).
The below reproducer should be self-explanatory in context of different runs.
Repeat-By:
Below is output from running the same oneliner (generating a stream
of binary bytes, and reading
them back to output the original numbers) firstly on my standard
Debian system Bash, then in other
builds and on different systems, to highlight the comparatively
unusual behaviour of the first:
$ bash -c 'declare -ai in_data=({195..190}); printf "$(printf
'\''\\x%02x'\'' "${in_data[@]}")" | { declare -ai blah=(); declare -i
byte; while LANG=C LC_ALL=C IFS= read -r -d "" -N 1 char; do printf
"%d\\n" "'\''${char}"; done; }'
195
194
193
192
255
190
$ static-bash-5.2.15-musl-1.2.5 -c 'declare -ai
in_data=({195..190}); printf "$(printf '\''\\x%02x'\''
"${in_data[@]}")" | { declare -ai blah=(); declare -i byte; while
LANG=C LC_ALL=C IFS= read -r -d "" -N 1 char; do printf "%d\\n"
"'\''${char}"; done; }'
195
194
193
192
191
190
$ static-bash-5.3-alpha-musl-1.2.5 -c 'declare -ai
in_data=({195..190}); printf "$(printf '\''\\x%02x'\''
"${in_data[@]}")" | { declare -ai blah=(); declare -i byte; while
LANG=C LC_ALL=C IFS= read -r -d "" -N 1 char; do printf "%d\\n"
"'\''${char}"; done; }'
195
194
193
192
191
190
$ ssh web
[me@web] $ bash -i
[me@web] $ uname -a
FreeBSD web 13.3-STABLE FreeBSD 13.3-STABLE stable/13-[snip] GENERIC amd64
[me@web] $ echo "${BASH_VERSION}"
5.2.26(1)-release
[me@web] $ declare -ai in_data=({195..190}); printf "$(printf
'\\x%02x' "${in_data[@]}")" | { declare -ai blah=(); declare -i byte;
while LANG=C LC_ALL=C IFS= read -r -d "" -N 1 char; do printf "%d\\n"
"'${char}"; done; }
195
194
193
192
191
190
$ ## ...with larger range the results get even weirder...
$ bash -c 'declare -ai in_data=({238..190}); printf "$(printf
'\''\\x%02x'\'' "${in_data[@]}")" | { declare -ai blah=(); declare -i
byte; while LANG=C LC_ALL=C IFS= read -r -d "" -N 1 char; do printf
"%d\\n" "'\''${char}"; done; }'
238
237
# ... properly descending sequence snipped for brevity ...
193
192
191
61438
#
-- System Information:
Debian Release: 12.5
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bash depends on:
ii base-files 12.4+deb12u5
ii debianutils 5.7-0.5~deb12u1
ii libc6 2.36-9+deb12u4
ii libtinfo6 6.4-4
Versions of packages bash recommends:
ii bash-completion 1:2.11-6
Versions of packages bash suggests:
pn bash-doc <none>
-- no debconf information
Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux pestilence 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC
Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
--- End Message ---
--- Begin Message ---
Hi,
On Mon, 24 Jun 2024 06:57:04 +0300 Rowan Thorpe <[email protected]>
wrote:
$ bash -c 'declare -ai in_data=({195..190}); printf "$(printf
'\''\\x%02x'\'' "${in_data[@]}")" | { declare -ai blah=(); declare -i
byte; while LANG=C LC_ALL=C IFS= read -r -d "" -N 1 char; do printf
"%d\\n" "'\''${char}"; done; }'
195
194
193
192
255
190
This test can be reduced to
$ printf "\xc3\xbf\xbe" | { while LC_ALL=C read -N 1 byte; do printf "%d
%q\n" "'${byte}" "$byte"; done; }
195 $'\303'
255 $'\277' ← 255 instead of 191
190 $'\276'
The issue with this code is that LC_ALL=C is set only for `read`;
`printf` will still run with the outside locale.
Setting LC_ALL=C fixes the problem:
$ export LC_ALL=C; printf "\xc3\xbf\xbe" | { while read -N 1 byte; do
printf "%d %q\n" "'${byte}" "$byte"; done; }
195 $'\303'
191 $'\277'
190 $'\276'
or
$ printf "\xc3\xbf\xbe" | { while LC_ALL=C read -N 1 byte; do LC_ALL=C
printf "%d %q\n" "'${byte}" "$byte"; done; }
195 $'\303'
191 $'\277'
190 $'\276'
The perceived issue is due to the fact that the leading single-quote in
the printf format string is locale- and codeset-sensitive:
If the leading character is a single-quote […], the value shall be
the numeric value in the underlying codeset of the character
following the single-quote […]
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
Regards,
--
Gioele Barabucci
--- End Message ---
