Call for testing: OpenSSH 7.8

[Steffen Nurpmeso]

Hello.

Ingo Schwarze wrote in <20180821152425.GE11494 at athene.usta.de>:
 |Steffen Nurpmeso wrote on Tue, Aug 21, 2018 at 04:57:30PM +0200:
 |
 |> Don't be too serious about that, 'am being 100% sure you know,
 |
 |I did not.
 |
 |> but having been stung by "concise" (and because my MUA had to
 |> implement n_iconv_name_is_ascii()) i want to point out that the
 |> IANA character sets define more aliases for US-ASCII, already in
 |> RFC 1345.  Here in reverse MIME preference order:
 |> 
 |> static char const * const names[] = {"csASCII", "cp367", "IBM367",
 |>   "us", "ISO646-US", "ISO_646.irv:1991", "ANSI_X3.4-1986",
 |>   "iso-ir-6", "ANSI_X3.4-1968", "ASCII", "US-ASCII"};
 |
 |But as far as i know, nothing requires nl_langinfo(CODESET) to
 |adhere to RFC 1345, and as a matter of fact, on some systems,
 |it does not (Solaris, NetBSD).  So even including the full list
 |you are providing above would be insufficient.
 |
 |On the other hand, using the full list *in addition* to what's
 |actually required provides no benefit, but poses gratuitous
 |additional risk of misidentification, in particular with names
 |as generic as "us".  We were just told that AIX returns en_US
 |for ASCII and EN_US for UTF-8 (or was it the other way round?
 |That's hard to remember).  Who knows what other systems out
 |there might return "us" for?
 |
 |Given the lack of standardization of nl_langinfo(3), adding the
 |return values that actually matter in practice, and nothing else,
 |seems like the way to go, in my opinion.

Of course; i have seen the actual commit in the meantime, sorry
for the noise.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)