Call for testing: OpenSSH 7.8

[Damien Miller]

On Sun, 19 Aug 2018, Ingo Schwarze wrote:

> > 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.

Well, the alternative is that OpenSSH basically doesn't work properly
systems that use one of those codesets, so I'm happy to take the
risk for codesets that seem prima facie safe. 

-d