Call for testing: OpenSSH 7.8

[Michael]

On 21/08/2018 17:24, Ingo Schwarze wrote:
> Hi Steffen,
>
> 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).
Actually, :p, en_US stands for iso-8859-1 :wink:
>   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.
>
> Yours,
>   Ingo



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180821/3c7722a2/attachment.asc>