Debian Bug report logs - #337041
openssh: ssh doesn't retain the IUTF8 flag

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: openssh: ssh doesn't retain the IUTF8 flag

Date: Wed, 2 Nov 2005 12:25:54 +0100

Package: openssh
Severity: normal

When I do a ssh from a terminal with IUTF8 flag set, this flag is
no longer set on the other side. The easiest way to test this is
to do a ssh to localhost.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13.4-20051012
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Message #10 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Vincent Lefevre <vincent@vinc17.org>, 337041@bugs.debian.org

Subject: Re: Bug#337041: openssh: ssh doesn't retain the IUTF8 flag

Date: Wed, 2 Nov 2005 18:13:32 +0000

On Wed, Nov 02, 2005 at 12:25:54PM +0100, Vincent Lefevre wrote:
> When I do a ssh from a terminal with IUTF8 flag set, this flag is
> no longer set on the other side. The easiest way to test this is
> to do a ssh to localhost.

Sorry, I'm not familiar with the IUTF8 flag; as far as I know, the
terminal emulator I generally use (pterm) doesn't support it. What
terminal are you using?

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #15 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: Colin Watson <cjwatson@debian.org>

Cc: 337041@bugs.debian.org

Subject: Re: Bug#337041: openssh: ssh doesn't retain the IUTF8 flag

Date: Wed, 2 Nov 2005 20:22:37 +0100

On 2005-11-02 18:13:32 +0000, Colin Watson wrote:
> Sorry, I'm not familiar with the IUTF8 flag; as far as I know, the
> terminal emulator I generally use (pterm) doesn't support it. What
> terminal are you using?

xterm, with the patch I posted here:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319237

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Message #20 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: ietf-ssh@netbsd.org

Cc: Vincent Lefevre <vincent@vinc17.org>, 337041@bugs.debian.org

Subject: IUTF8 pseudo-terminal mode

Date: Sat, 31 Dec 2005 16:05:59 +0000

Recent versions of the Linux kernel support an IUTF8 flag (see
http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the
character-erase function in cooked mode to handle UTF-8 characters
correctly. I would like to allow this mode to be preserved by SSH, but
there is no assignment for it at present.

Could this line be added to the appropriate place in
draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create
this assignment? 42 seems like a reasonable place for it.

          42    IUTF8       Assume input characters are UTF-8 encoded.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #25 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Bill Sommerfeld <sommerfeld@sun.com>

To: Colin Watson <cjwatson@debian.org>

Cc: ietf-ssh@NetBSD.org, Vincent Lefevre <vincent@vinc17.org>, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 02 Jan 2006 17:29:40 -0500

On Sat, 2005-12-31 at 11:05, Colin Watson wrote:
> Recent versions of the Linux kernel support an IUTF8 flag (see
> http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the
> character-erase function in cooked mode to handle UTF-8 characters
> correctly. I would like to allow this mode to be preserved by SSH, but
> there is no assignment for it at present.
> 
> Could this line be added to the appropriate place in
> draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create
> this assignment? 42 seems like a reasonable place for it.
> 
>           42    IUTF8       Assume input characters are UTF-8 encoded.

as others have suggested, it's already too late to modify -connect and
-assignednumbers.

So what needs to happen to get this standardized is for someone to write
an internet-draft documenting this extension and advance it as either a
working group item or as an individual submission.

In response to later messages:
> While setting LANG et al is indeed useful, it's not enough to make the
> kernel's terminal driver do the right thing when erasing characters in
> cooked mode. That's why the termios flag was invented.

I think Nicolas was implying that a request from the client to use a
UTF8 locale would cause the server to set up the pseudoterminal it
creates/allocates/... appropriately for the requested locale.  But
that's perhaps at odds with the existing strategy within the protocol of
making termios-level details visible on the wire.

						- Bill

Message #30 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Nicolas Williams <Nicolas.Williams@sun.com>

To: Bill Sommerfeld <sommerfeld@sun.com>

Cc: Colin Watson <cjwatson@debian.org>, ietf-ssh@NetBSD.org, Vincent Lefevre <vincent@vinc17.org>, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 2 Jan 2006 16:43:58 -0600

On Mon, Jan 02, 2006 at 05:29:40PM -0500, Bill Sommerfeld wrote:
> In response to later messages:
> > While setting LANG et al is indeed useful, it's not enough to make the
> > kernel's terminal driver do the right thing when erasing characters in
> > cooked mode. That's why the termios flag was invented.
> 
> I think Nicolas was implying that a request from the client to use a
> UTF8 locale would cause the server to set up the pseudoterminal it
> creates/allocates/... appropriately for the requested locale.  But
> that's perhaps at odds with the existing strategy within the protocol of
> making termios-level details visible on the wire.

I think I was a bit more explicit about this, but, yes, this would be a
hack, and very POSIX-specific (and I was explicit about that too).  But
such a hack would also probably make most users happy :^/ at the expense
of elegance and code complexity for SSHv2 servers running on POSIXy
platforms.

SSHv2's pty negotiation could certainly improve in this regard, I don't
deny it!

But I suspect saying "UTF-8" is not enough here.  What options are
there?  Should the pty driver reject non-UTF-8 sequences?  Should it
normalize?  Pass input through raw?  I suspect most users wouldn't want
much of a pty UTF-8 input mechanism as their clients, presumably, have a
decent UTF-8 input method already -- but then, maybe they don't.

I definitely think this should be a WG work item, if nothing else to
ensure it gets more eyeballs because I18N requires care.

Nico
-- 

Message #35 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Jeffrey Hutzelman <jhutz@cmu.edu>

To: Nicolas Williams <Nicolas.Williams@sun.com>, Bill Sommerfeld <sommerfeld@sun.com>

Cc: Colin Watson <cjwatson@debian.org>, ietf-ssh@NetBSD.org, Vincent Lefevre <vincent@vinc17.org>, 337041@bugs.debian.org, Jeffrey Hutzelman <jhutz@cmu.edu>

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 02 Jan 2006 18:20:50 -0500

On Monday, January 02, 2006 04:43:58 PM -0600 Nicolas Williams 
<Nicolas.Williams@sun.com> wrote:

> On Mon, Jan 02, 2006 at 05:29:40PM -0500, Bill Sommerfeld wrote:
>> In response to later messages:
>> > While setting LANG et al is indeed useful, it's not enough to make the
>> > kernel's terminal driver do the right thing when erasing characters in
>> > cooked mode. That's why the termios flag was invented.
>>
>> I think Nicolas was implying that a request from the client to use a
>> UTF8 locale would cause the server to set up the pseudoterminal it
>> creates/allocates/... appropriately for the requested locale.  But
>> that's perhaps at odds with the existing strategy within the protocol of
>> making termios-level details visible on the wire.
>
> I think I was a bit more explicit about this, but, yes, this would be a
> hack, and very POSIX-specific (and I was explicit about that too).  But
> such a hack would also probably make most users happy :^/ at the expense
> of elegance and code complexity for SSHv2 servers running on POSIXy
> platforms.
>
> SSHv2's pty negotiation could certainly improve in this regard, I don't
> deny it!
>
> But I suspect saying "UTF-8" is not enough here.  What options are
> there?  Should the pty driver reject non-UTF-8 sequences?  Should it
> normalize?  Pass input through raw?  I suspect most users wouldn't want
> much of a pty UTF-8 input mechanism as their clients, presumably, have a
> decent UTF-8 input method already -- but then, maybe they don't.
>
> I definitely think this should be a WG work item, if nothing else to
> ensure it gets more eyeballs because I18N requires care.

The original request wasn't really about standardizing handling of UTF-8 in 
SSH data streams.  That's really outside the scope of the protocol -- 
unlike telnet, SSH doesn't provide a "virtual terminal"; it connects the 
shell running on the server to the user's real terminal, and experience has 
shown this is basically the right thing to do.

The request here was to enable SSH to pass a platform-specific TTY mode bit 
which it doesn't currently handle.  The bit in question causes the tty 
driver on Linux systems to behave in a particular way; specifically, it 
tells the driver that the user is typing in UTF-8, and that when the user 
types the ERASE character, the driver should remove a complete character 
(possibly a multi-byte UTF-8 sequence) from the input buffer.

One could argue that an SSH server running on such a system should look at 
the configured locale and configure the PTY appropriately, and that's 
probably even a good idea.  However, a user using 'stty' to change terminal 
modes at the remote end of an ssh connection has an expectation that the 
change will propagate to the local terminal as much as possible, and the 
point of defining a bit for IUTF8 is to help make that possible.

-- Jeff

Message #40 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Nicolas Williams <Nicolas.Williams@sun.com>

To: Jeffrey Hutzelman <jhutz@cmu.edu>

Cc: Bill Sommerfeld <sommerfeld@sun.com>, Colin Watson <cjwatson@debian.org>, ietf-ssh@NetBSD.org, Vincent Lefevre <vincent@vinc17.org>, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 2 Jan 2006 17:30:34 -0600

On Mon, Jan 02, 2006 at 06:20:50PM -0500, Jeffrey Hutzelman wrote:
> The original request wasn't really about standardizing handling of UTF-8 in 
> SSH data streams.  That's really outside the scope of the protocol -- 
> unlike telnet, SSH doesn't provide a "virtual terminal"; it connects the 
> shell running on the server to the user's real terminal, and experience has 
> shown this is basically the right thing to do.

Well, yes, but I'm not entirely sure one wouldn't want to negotiate
additional behaviours -- I'm not saying one should as I've not really
thought this through.

> The request here was to enable SSH to pass a platform-specific TTY mode bit 
> which it doesn't currently handle.  The bit in question causes the tty 
> driver on Linux systems to behave in a particular way; specifically, it 
> tells the driver that the user is typing in UTF-8, and that when the user 
> types the ERASE character, the driver should remove a complete character 
> (possibly a multi-byte UTF-8 sequence) from the input buffer.

Got it.

> One could argue that an SSH server running on such a system should look at 
> the configured locale and configure the PTY appropriately, and that's 
> probably even a good idea.  However, a user using 'stty' to change terminal 
> modes at the remote end of an ssh connection has an expectation that the 
> change will propagate to the local terminal as much as possible, and the 
> point of defining a bit for IUTF8 is to help make that possible.

Did you switch local/remote here?

Nico
-- 

Message #45 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: Jeffrey Hutzelman <jhutz@cmu.edu>

Cc: Nicolas Williams <Nicolas.Williams@sun.com>, Bill Sommerfeld <sommerfeld@sun.com>, Colin Watson <cjwatson@debian.org>, ietf-ssh@NetBSD.org, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 12 May 2008 02:00:56 +0200

On 2006-01-02 18:20:50 -0500, Jeffrey Hutzelman wrote:
> One could argue that an SSH server running on such a system should look 
> at the configured locale and configure the PTY appropriately, and that's  
> probably even a good idea.

What "configured locale"? The user may use a locale which is not the
default one at the system level. Perhaps you mean that the SSH client
should propagate the locale (more precisely, the charmap) to the
remote side, so that the SSH server can use it (in which case the
server should make this information available at the user level too,
as it can be useful to set up the LC_CTYPE environment variable).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #50 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Nicolas Williams <Nicolas.Williams@sun.com>

To: Vincent Lefevre <vincent@vinc17.org>

Cc: Jeffrey Hutzelman <jhutz@cmu.edu>, Bill Sommerfeld <sommerfeld@sun.com>, Colin Watson <cjwatson@debian.org>, ietf-ssh@NetBSD.org, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Sun, 11 May 2008 21:00:55 -0500

On Mon, May 12, 2008 at 02:00:56AM +0200, Vincent Lefevre wrote:
> On 2006-01-02 18:20:50 -0500, Jeffrey Hutzelman wrote:
> > One could argue that an SSH server running on such a system should look 
> > at the configured locale and configure the PTY appropriately, and that's  
> > probably even a good idea.
> 
> What "configured locale"? The user may use a locale which is not the

Whatever the locale for that channel/session/whatever.

> default one at the system level. Perhaps you mean that the SSH client
> should propagate the locale (more precisely, the charmap) to the

SunSSH 1.1 does (by having the client set per-channel LANG/LC_*
environment variables).

It's less than perfect: the client has no idea what a client-side locale
maps to on the server side.

Also, it's not just character sets that matter, but language for
localization of messages, date formats, etc...

Nico
-- 

Message #55 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: Nicolas Williams <Nicolas.Williams@sun.com>

Cc: Jeffrey Hutzelman <jhutz@cmu.edu>, Bill Sommerfeld <sommerfeld@sun.com>, Colin Watson <cjwatson@debian.org>, ietf-ssh@NetBSD.org, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 12 May 2008 10:07:47 +0200

On 2008-05-11 21:00:55 -0500, Nicolas Williams wrote:
> On Mon, May 12, 2008 at 02:00:56AM +0200, Vincent Lefevre wrote:
> > default one at the system level. Perhaps you mean that the SSH client
> > should propagate the locale (more precisely, the charmap) to the
> 
> SunSSH 1.1 does (by having the client set per-channel LANG/LC_*
> environment variables).

I meant in a way that always works in practice.

> It's less than perfect: the client has no idea what a client-side
> locale maps to on the server side.

Yes, that's the problem: it's not always possible to rebuild a correct
LC_CTYPE on the remote side, e.g. if LC_CTYPE is "en_US", one doesn't
have information about the charset on the remote side.

> Also, it's not just character sets that matter, but language for
> localization of messages, date formats, etc...

Well, localization of messages and date formats are just a user choice.
If they are different on the remote side, this isn't really a problem.
Concerning the character set, the remote one must be compatible with
the local one, at least when a terminal is used (ditto for the IUTF8
pseudo-terminal mode). Otherwise the user can't view or edit non-ASCII
characters correctly.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #60 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Vincent Lefevre <vincent@vinc17.org>

Cc: Nicolas Williams <Nicolas.Williams@sun.com>, Jeffrey Hutzelman <jhutz@cmu.edu>, Bill Sommerfeld <sommerfeld@sun.com>, ietf-ssh@NetBSD.org, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 12 May 2008 10:18:50 +0100

On Mon, May 12, 2008 at 10:07:47AM +0200, Vincent Lefevre wrote:
> On 2008-05-11 21:00:55 -0500, Nicolas Williams wrote:
> > On Mon, May 12, 2008 at 02:00:56AM +0200, Vincent Lefevre wrote:
> > > default one at the system level. Perhaps you mean that the SSH client
> > > should propagate the locale (more precisely, the charmap) to the
> > 
> > SunSSH 1.1 does (by having the client set per-channel LANG/LC_*
> > environment variables).

OpenSSH, as configured in Debian, does this too.

> I meant in a way that always works in practice.
> 
> > It's less than perfect: the client has no idea what a client-side
> > locale maps to on the server side.
> 
> Yes, that's the problem: it's not always possible to rebuild a correct
> LC_CTYPE on the remote side, e.g. if LC_CTYPE is "en_US", one doesn't
> have information about the charset on the remote side.

Locale names are indeed opaque as far as POSIX is concerned, so there's
no portable way to pick them apart. But even if locale names are in
principle identical (i.e. client and server running the same release of
the same operating system), there's a further problem. With glibc,
locale definitions are quite large (thus inconvenient to distribute in
pre-generated form) and take some time to generate, so it's fairly
common for distributions to set things up so that you only generate the
locale definitions you need. The locale you're using on the client may
simply not exist on the server.

Now, in some ways this does end up invoking undefined behaviour; you're
asking for a locale that doesn't exist. Messages will of course end up
being output in the C locale, and so on. But it is *terribly* useful to
at least get the character encoding right, as otherwise you get hopeless
garbage on the screen and it may well not be very obvious what the
problem is.

This is compounded by the fact that there is no equivalent of "C" for
UTF-8 in glibc: that is, there's no way to say "I just want a basically
unlocalised system that happens to use the UTF-8 encoding for
everything". Thus even people who don't care about localisation have to
select something like en_US.UTF-8 or en_GB.UTF-8, and any time they ssh
to a server that doesn't have those locales generated they end up with
screwed-up output from full-screen terminal applications.

> > Also, it's not just character sets that matter, but language for
> > localization of messages, date formats, etc...
> 
> Well, localization of messages and date formats are just a user choice.
> If they are different on the remote side, this isn't really a problem.
> Concerning the character set, the remote one must be compatible with
> the local one, at least when a terminal is used (ditto for the IUTF8
> pseudo-terminal mode). Otherwise the user can't view or edit non-ASCII
> characters correctly.

Absolutely.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #65 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Nicolas Williams <Nicolas.Williams@sun.com>

To: Vincent Lefevre <vincent@vinc17.org>

Cc: Jeffrey Hutzelman <jhutz@cmu.edu>, Bill Sommerfeld <sommerfeld@sun.com>, Colin Watson <cjwatson@debian.org>, ietf-ssh@NetBSD.org, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 12 May 2008 09:35:46 -0500

On Mon, May 12, 2008 at 10:07:47AM +0200, Vincent Lefevre wrote:
> On 2008-05-11 21:00:55 -0500, Nicolas Williams wrote:
> > SunSSH 1.1 does (by having the client set per-channel LANG/LC_*
> > environment variables).
> 
> I meant in a way that always works in practice.

It tends to, though only by dint of luck.

> > It's less than perfect: the client has no idea what a client-side
> > locale maps to on the server side.
> 
> Yes, that's the problem: it's not always possible to rebuild a correct
> LC_CTYPE on the remote side, e.g. if LC_CTYPE is "en_US", one doesn't
> have information about the charset on the remote side.

There should be a way.  SSHv2 already negotiates languages.  A
negotiation of charsets per-channel wouldn't be too difficult to add.

> > Also, it's not just character sets that matter, but language for
> > localization of messages, date formats, etc...
> 
> Well, localization of messages and date formats are just a user choice.

Yes, but the user doesn't want to be making that choice all the time.

What if the user reads three languages and doesn't know which the remote
server has localizations for?  What if the user doesn't have "dot files"
on the server?  It'd be nice if the client and server could just settle
on a locale that meets the user's needs with no additional input from
the user.

> If they are different on the remote side, this isn't really a problem.

Yes it is.

> Concerning the character set, the remote one must be compatible with
> the local one, at least when a terminal is used (ditto for the IUTF8
> pseudo-terminal mode). Otherwise the user can't view or edit non-ASCII
> characters correctly.

I agree with the first point, but not necessarily with the second (the
client can always put the local terminal into raw mode and let the
server-side IUTF8 mode take over).

Nico
-- 

Message #70 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: Nicolas Williams <Nicolas.Williams@sun.com>

Cc: Jeffrey Hutzelman <jhutz@cmu.edu>, Bill Sommerfeld <sommerfeld@sun.com>, Colin Watson <cjwatson@debian.org>, ietf-ssh@NetBSD.org, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 12 May 2008 18:25:33 +0200

On 2008-05-12 09:35:46 -0500, Nicolas Williams wrote:
> What if the user reads three languages and doesn't know which the remote
> server has localizations for?  What if the user doesn't have "dot files"
> on the server?

There's also the problem that if the user shell is bash, the .bashrc
(or .bash_profile) isn't always read (fortunately, Debian's bash doesn't
have this problem).

> It'd be nice if the client and server could just settle on a locale
> that meets the user's needs with no additional input from the user.

If full locale negociation could be added to SSH, this would be great.

> > If they are different on the remote side, this isn't really a problem.
> 
> Yes it is.

Well, less than the charset problem. BTW, I generally want some of my
locales to be defined locally on each machine. For instance, I use
LC_TIME=en_DK (to have ISO-8601 dates) under Linux, but this locale
doesn't exist under Mac OS X; worse than that, if I try to use it
under Mac OS X, it makes a terrible mess.

> > Concerning the character set, the remote one must be compatible with
> > the local one, at least when a terminal is used (ditto for the IUTF8
> > pseudo-terminal mode). Otherwise the user can't view or edit non-ASCII
> > characters correctly.
> 
> I agree with the first point, but not necessarily with the second (the
> client can always put the local terminal into raw mode and let the
> server-side IUTF8 mode take over).

I don't understand, or is it just that this isn't implemented in
OpenSSH yet?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Message #77 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: Colin Watson <cjwatson@debian.org>

Cc: ietf-ssh@netbsd.org, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 4 Feb 2013 16:02:20 +0100

On 2005-12-31 16:05:59 +0000, Colin Watson wrote:
> Recent versions of the Linux kernel support an IUTF8 flag (see
> http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the
> character-erase function in cooked mode to handle UTF-8 characters
> correctly. I would like to allow this mode to be preserved by SSH, but
> there is no assignment for it at present.
> 
> Could this line be added to the appropriate place in
> draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create
> this assignment? 42 seems like a reasonable place for it.
> 
>           42    IUTF8       Assume input characters are UTF-8 encoded.
> 
> Thanks,

The problem is still there in the Debian packages from openssh 6.0p1-3.
There is a workaround, which is to set the IUTF8 flag from the .ssh/rc
file when need be, but this needs to detect the locales via LC_* env
variables (e.g. by using "locale charmap"), which are not necessarily
correctly passed (e.g. due to Debian bug 313317 / OpenSSH bug 1346).

Note: the cooked mode itself doesn't mind about the value of the LC_*
env variables; this is just a terminal problem.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #92 received at 337041@bugs.debian.org (full text, mbox, reply):

From: Jeffrey Hutzelman <jhutz@cmu.edu>

To: Vincent Lefevre <vincent@vinc17.net>

Cc: jhutz@cmu.edu, Colin Watson <cjwatson@debian.org>, ietf-ssh@NetBSD.org, 337041@bugs.debian.org

Subject: Re: IUTF8 pseudo-terminal mode

Date: Mon, 04 Feb 2013 14:43:55 -0500

On Mon, 2013-02-04 at 16:02 +0100, Vincent Lefevre wrote:
> On 2005-12-31 16:05:59 +0000, Colin Watson wrote:
> > Recent versions of the Linux kernel support an IUTF8 flag (see
> > http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the
> > character-erase function in cooked mode to handle UTF-8 characters
> > correctly. I would like to allow this mode to be preserved by SSH, but
> > there is no assignment for it at present.
> > 
> > Could this line be added to the appropriate place in
> > draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create
> > this assignment? 42 seems like a reasonable place for it.
> > 
> >           42    IUTF8       Assume input characters are UTF-8 encoded.
> > 
> > Thanks,
> 
> The problem is still there in the Debian packages from openssh 6.0p1-3.

Yes, I'm sure it is.  The requested number was not added to the draft,
because it was too late to do so before publication.  A few days later,
Bill Sommerfeld, who was WG chair at the time, posted the following:

> So what needs to happen to get this standardized is for someone to write
> an internet-draft documenting this extension and advance it as either a
> working group item or as an individual submission.

That remains the case today.  The registration policy for that registry
is "IETF Consensus", which means that getting a new number assigned
requires publishing an RFC.  For this sort of thing, that could happen
relatively quickly, once someone writes an internet-draft.

-- Jeff

Message #97 received at 337041@bugs.debian.org (full text, mbox, reply):

From: David Madore <david+bugs@madore.org>

To: 337041@bugs.debian.org

Cc: IETF SECSH WG <ietf-ssh@NetBSD.org>, Colin Watson <cjwatson@debian.org>, Vincent Lefevre <vincent@vinc17.net>

Subject: patch adding IUTF8 support to OpenSSH

Date: Fri, 29 Mar 2013 18:05:03 +0100

[Message part 1 (text/plain, inline)]

Attached is a(n absolutely trivial) patch that adds the IUTF8 terminal
mode (with code 42) to OpenSSH.  Prebuilt Debian packages for those
architectures I was able to build for, for testing and stable
distributions, are available in <URL:
ftp://quatramaran.ens.fr/pub/madore/misc/openssh-with-iutf8/
 >.

It works for me (transmits the IUTF8 mode when both the server and
client are patched, and, of course, does not break when only one of
them is).  I would love to see some independent confirmation, though.

I understand that the Debian maintainer's position is that this patch
will not be applied until the value is standardized.  So this patch is
submitted for testing purposes.

I have written a separate email to the authors of RFC 4250 to ask for
their guidance on how to get things moving on the standardization
front, although I fear a chickend-and-egg problem.  I am willing to
try writing an Internet draft if nobody else will, but without some
weight to back it up I'm afraid it won't go far.

Happy hacking,

-- 
     David A. Madore
   ( http://www.madore.org/~david/ )

[iutf8-ttymode.patch (text/x-diff, attachment)]

Message #102 received at 337041-close@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: 337041-close@bugs.debian.org

Subject: Bug#337041: fixed in openssh 1:7.3p1-1

Date: Sun, 07 Aug 2016 22:48:14 +0000

Source: openssh
Source-Version: 1:7.3p1-1

We believe that the bug you reported is fixed in the latest version of
openssh, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 337041@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Colin Watson <cjwatson@debian.org> (supplier of updated openssh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 07 Aug 2016 22:45:26 +0100
Source: openssh
Binary: openssh-client openssh-client-ssh1 openssh-server openssh-sftp-server ssh ssh-krb5 ssh-askpass-gnome openssh-client-udeb openssh-server-udeb
Architecture: source
Version: 1:7.3p1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
Description:
 openssh-client - secure shell (SSH) client, for secure access to remote machines
 openssh-client-ssh1 - secure shell (SSH) client for legacy SSH1 protocol
 openssh-client-udeb - secure shell client for the Debian installer (udeb)
 openssh-server - secure shell (SSH) server, for secure access from remote machines
 openssh-server-udeb - secure shell server for the Debian installer (udeb)
 openssh-sftp-server - secure shell (SSH) sftp server module, for SFTP access from remot
 ssh        - secure shell client and server (metapackage)
 ssh-askpass-gnome - interactive X program to prompt users for a passphrase for ssh-ad
 ssh-krb5   - secure shell client and server (transitional package)
Closes: 337041 396295 407088 536031
Changes:
 openssh (1:7.3p1-1) unstable; urgency=medium
 .
   * New upstream release (http://www.openssh.com/txt/release-7.3):
     - SECURITY: sshd(8): Mitigate a potential denial-of-service attack
       against the system's crypt(3) function via sshd(8).  An attacker could
       send very long passwords that would cause excessive CPU use in
       crypt(3).  sshd(8) now refuses to accept password authentication
       requests of length greater than 1024 characters.
     - SECURITY: ssh(1), sshd(8): Fix observable timing weakness in the CBC
       padding oracle countermeasures.  Note that CBC ciphers are disabled by
       default and only included for legacy compatibility.
     - SECURITY: ssh(1), sshd(8): Improve operation ordering of MAC
       verification for Encrypt-then-MAC (EtM) mode transport MAC algorithms
       to verify the MAC before decrypting any ciphertext.  This removes the
       possibility of timing differences leaking facts about the plaintext,
       though no such leakage has been observed.
     - ssh(1): Add a ProxyJump option and corresponding -J command-line flag
       to allow simplified indirection through a one or more SSH bastions or
       "jump hosts".
     - ssh(1): Add an IdentityAgent option to allow specifying specific agent
       sockets instead of accepting one from the environment.
     - ssh(1): Allow ExitOnForwardFailure and ClearAllForwardings to be
       optionally overridden when using ssh -W.
     - ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as per
       draft-sgtatham-secsh-iutf8-00 (closes: #337041, LP: #394570).
     - ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman 2K,
       4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03.
     - ssh-keygen(1), ssh(1), sshd(8): Support SHA256 and SHA512 RSA
       signatures in certificates.
     - ssh(1): Add an Include directive for ssh_config(5) files (closes:
       #536031).
     - ssh(1): Permit UTF-8 characters in pre-authentication banners sent
       from the server.
     - ssh(1), sshd(8): Reduce the syslog level of some relatively common
       protocol events from LOG_CRIT.
     - sshd(8): Refuse AuthenticationMethods="" in configurations and accept
       AuthenticationMethods=any for the default behaviour of not requiring
       multiple authentication.
     - sshd(8): Remove obsolete and misleading "POSSIBLE BREAK-IN ATTEMPT!"
       message when forward and reverse DNS don't match.
     - ssh(1): Deduplicate LocalForward and RemoteForward entries to fix
       failures when both ExitOnForwardFailure and hostname canonicalisation
       are enabled.
     - sshd(8): Remove fallback from moduli to obsolete "primes" file that
       was deprecated in 2001 (LP: #1528251).
     - sshd_config(5): Correct description of UseDNS: it affects ssh hostname
       processing for authorized_keys, not known_hosts.
     - sshd(8): Send ClientAliveInterval pings when a time-based RekeyLimit
       is set; previously keepalive packets were not being sent.
     - sshd(8): Whitelist more architectures to enable the seccomp-bpf
       sandbox.
     - scp(1): Respect the local user's LC_CTYPE locale (closes: #396295).
     - Take character display widths into account for the progressmeter
       (closes: #407088).
Checksums-Sha1:
 1696e0c90be02c5ab37c283422be50c5c9c3de67 2884 openssh_7.3p1-1.dsc
 bfade84283fcba885e2084343ab19a08c7d123a5 1522617 openssh_7.3p1.orig.tar.gz
 e384b5ef8d31c23bdab9cdd216284500ffc1f942 153400 openssh_7.3p1-1.debian.tar.xz
Checksums-Sha256:
 61e8414cb2ed2a72ee15053511d3a2f55ace4b8fb76fff2d901ec67d4a1cf5ba 2884 openssh_7.3p1-1.dsc
 3ffb989a6dcaa69594c3b550d4855a5a2e1718ccdde7f5e36387b424220fbecc 1522617 openssh_7.3p1.orig.tar.gz
 a9a96b33427697afb344d6c82078abc54da411f108b19949c9f3378b947b4971 153400 openssh_7.3p1-1.debian.tar.xz
Files:
 f4140e6c58f897bebd9db969be5c63fc 2884 net standard openssh_7.3p1-1.dsc
 dfadd9f035d38ce5d58a3bf130b86d08 1522617 net standard openssh_7.3p1.orig.tar.gz
 28764a8e122da612b35b36bcbf23b2cf 153400 net standard openssh_7.3p1-1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Colin Watson <cjwatson@debian.org> -- Debian developer

iQIVAwUBV6etsTk1h9l9hlALAQiPUQ/+IC9t/bgqKFE73f34nVZZ1zuONs4+ykn6
7asE52PNycFrZ7mt3vvxrrSgDAh5ixJhWKZQP6tfhX6d4QMi3hFM0MNNpVF+eqE3
FynWWwqpkT/wEenj88hngmHSZb9heYCtXri6D1AzpKYbsQFEIQkMPO48mllxBmbj
aQVjm5UKbfZrFjrayNE4XC0Aqkhlc2HOPKTtNexZb4xantsAkJcyE/oDztI8rbcn
56cTxiMpsHmJ8dlO6tvZTYwOqwso7S+H/A3u3923mKfswyrHpIjCYjq9eAQuDlCD
mjSUWdQIW0YlQ/Hfws2lX8mUopw8eKwCWovrF0y/XHZTXqtU+3jkWlliZCjJYh0o
6u9FntqHlP7nuVLsw8Ek/4QfB2uvuckMBaAt+2EoWtCJfvS/1SxyHkXSXpGPpLhO
WtmwYVLRlv0a5adUXLgbAPJKDh6k2XTXpyoif4gZHU+zfLCHt8PE98heZCCou7QN
GN7H/WuF6LxooWqUv7fERyjG5wAGt3DH+aUoExPY++uovLlo7jLE94XtSyEV67yL
Qa3Ek57IBXaMhMGLJmV5v/Ut5xRd58YuCvDIGsFqwTTKfjzXGO05qLqgUogJftgJ
JEGXDqSwUplEaQUzOR86CGKXeNcUMRe2RkVbBqj7bxguL6/NI5rf7DMtApqiTlgx
UT1nfn54N9M=
=DYzz
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.