Call for testing: OpenSSH 7.8

Ingo Schwarze schwarze at usta.de
Mon Aug 20 00:18:47 AEST 2018


Hi,

Damien Miller wrote on Sun, Aug 19, 2018 at 06:30:47PM +1000:
> On Sat, 18 Aug 2018, Michael Felt (aixtools) wrote:

>> Irrc the default on AIX. is iso-18559-15 (hope i have all the numbers
>> right. In any case not utf-8.

> The numbers are ... not right:
> 
> https://www.iso.org/obp/ui/#iso:std:iso:18559:dis:ed-1:v1:en
> ISO 18559 - Dentistry — Extraoral spatulas
> for mixing dental cements
> 
> Maybe ISO 8559-1?

More likely ISO 8559-15, but whatever.

> If it's basically ASCII then we could add it to the check
> in utf8.c:dangerous_locale() and the test will probably pass.

I dislike that idea.

Sure, in theory, it would be possible and safe to add a long list
of all character encodings to that function which satisfy both of
the following conditions: (1) they do not carry internal state and
(2) they contain ASCII as a subset.

But i don't think it's worth the effort because such character
encodings (with the exception of UTF-8) have been moribund for
years.  Also, such a list would not only be ugly, but also hard to
maintain because it would require the OpenSSH maintainers to judge
the properties of unfamiliar character sets.  That hardship would
make maintenance error-prone.  On top of that, all we can check is
the CODESET string returned from nl_langinfo(3), and those strings
are not specified by any standard.  The more strings you whitelist
here, the higher the risk that some string that means a safe encoding
on one given system accidentally means a different, unsafe encoding
on some other system you never thought (or even heard) about.

I think the current whitelist is probably more or less safe, even
though the strcmp(loc, "646") looks a bit dubious - are we really
sure that there is no system out there using that for an unsafe
encoding? - and thinking about it again, i'm no longer all that
happy with the strcmp(loc, "") either - a broken (or even merely
unusual!) nl_langinfo(3) implementation could easily return that,
tricking OpenSSH into unsafe encoding behaviour.

In any case, i don't like the idea of adding yet more strings to
the list.

Yours,
  Ingo


More information about the openssh-unix-dev mailing list