Bug#754596: libc6 package upgrade sends ISO-2022 escape sequences to a terminal which doesn't support them (PuTTY in UTF-8 mode)
Package: libc6
Version: 2.19-5
Severity: minor
I don't know if libc6 is where the actual problem lies, but I don't
experience this bug with any other package; so I'll start here.
If the actual problem lies with some other package, feel free to
reassign this bug report to the guilty package once you have figured
out where the actual problem lies.
The Debian system uses a UTF-8 locale (en_US.UTF-8). The system
administrator (root) is logged in to the system via a remote SSH
client. In this case, the client is PuTTY, a very popular open
source SSH client for Windows. (Ports are available to other platforms,
but that's beside the point.) PuTTY is configured as recommended
for use with a Debian system which uses a UTF-8 locale. (See
https://lists.debian.org/debian-user/2014/07/msg00592.html
for details.)
As pointed out in the above link, PuTTY does not support the ISO-2022
escape sequences traditionally used to draw lines and boxes when
operating in UTF-8 mode. (See also
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/utf8-plus-vt100.html
for the official word on this.)
The problem occurs when libc6 must be upgraded during "apt-get upgrade"
or "apt-get dist-upgrade". I see a screen which looks like this:
-----
lqqqqqqqqqqqqqqqqqqqqqqqqu Configuring libc6:s390x tqqqqqqqqqqqqqqqqqqqqqqqqk
x Running services and programs that are using NSS need to be restarted, x
x otherwise they might not be able to do lookup or authentication any more x
x (for services such as ssh, this can affect your ability to login). x
x Please review the following space-separated list of init.d scripts for x
x services to be restarted now, and correct it if needed. x
x x
x Note: restarting sshd/telnetd should not affect any existing x
x connections. x
x x
x Services to restart for GNU libc library upgrade: x
x x
x vsftpd exim4 cron atd____________________________________________________ x
x x
x <Ok> x
x x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
-----
As you can see, PuTTY was sent the traditional ISO-2022 box-drawing escape
sequences to draw the box, which does not work when PuTTY is operating in
UTF-8 mode. These need to be converted into equivalent UTF-8 sequences to
look right. I wish to emphasize that libc6 is the *only* package which does
this. Every other package which displays a screen like this is smart enough
to send the proper UTF-8 sequences to draw the box. For example, on a recent
upgrade of libssl1.0.0 I got this:
-----
┌─────────────────────┤ Configuring libssl1.0.0:s390x ├─────────────────────┐
│ This release of OpenSSL fixes some security issues. Services will not │
│ use these fixes until they are restarted. Please note that restarting │
│ the SSH server (sshd) should not affect any existing connections. │
│ │
│ Please check the list of detected services that need to be restarted and │
│ correct it, if needed. The services names must be identical to the │
│ initialization script names in /etc/init.d and separated by spaces. No │
│ services will be restarted if the list is empty. │
│ │
│ Any service that later fails unexpectedly after this upgrade should be │
│ restarted. It is recommended to reboot this host to avoid any │
│ SSL-related trouble. │
│ │
│ Services to restart to make them use the new libraries: │
│ │
│ vsftpd ssh exim4_________________________________________________________ │
│ │
│ <Ok> │
│ │
└───────────────────────────────────────────────────────────────────────────┘
-----
If the bug is not in package libc6, then why is libc6 the *only* package
which doesn't use the proper box-drawing technique? Note that when using
a terminal which *does* support ISO-2022 escape sequences in UTF-8 mode,
such as the Linux console or xterm, the box looks fine. It's only when
using a terminal which does *not* support ISO-2022 escape sequences in UTF-8
mode that we have a problem.
Personally, I believe that supporting ISO-2022 escape sequences in UTF-8
mode represents a standards violation (see
http://www.cl.cam.ac.uk/~mgk25/unicode.html#term). But that's beside the
point. The point is that PuTTY does *not* support ISO-2022 escape sequences
in UTF-8 mode, and due to the terminal type definition of xterm-utf8,
ncurses knows this. Yet it is being sent untranslated ISO-2022 escape
sequences somehow. But only when upgrading package libc6. Not when upgrading
any other package. Very strange.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: