On Sun, Feb 23, 2020 at 05:01:03AM -0700, Theo de Raadt wrote:
> Stefan Sperling <s...@stsp.name> wrote:
> 
> > I don't understand why the installer would matter. Nothing would actually
> > change for the installer. We're sure as hell not going to add UTF-8 there.
> > The installer's ifconfig would just deal in hex all the way as it does 
> > today.
> > During install finding the right network could be tricky, but that's not a
> > new problem. Upgrades would just work once hostname.if contains the right 
> > hex.
> 
> In upgrade mode, the installer must be able to do the same work as
> /etc/netstart -- the installer has a re-implimentation to parse and act
> upon hostname.* files.  If that behaves different because ifconfig doesn't
> act the same way, upgrade won't work right in some circumstances.  There's
> a small chance your change in behaviour for ifconfig doesn't matter but
> I am quite sceptical.

Our expectations with respect to the contents of hostname.if remain unchanged.
With and without this diff, using a network with non-ASCII characters requires
adding a hex SSID in hostname.if. Nobody wants the complexity of UTF-8 SSIDs
inside netstart, the installer, or on the argument list of ifconfig.

This diff only intends to provide a hint (decoded UTF-8 SSID) when scan
results are displayed by ifconfig in a fully installed UTF-8 enabled system.

Not showing a decoded form means users may somehow try to obtain a decoded
form to tell which networks they are looking at. And they might end up doing
this in an ad-hoc unsafe way that doesn't filter control sequences.
The diff allows ifconfig to do the decoding safely and only display data when
it is actually printable, much like it filters out non-printable ASCII.

In the default "C" locale, nothing changes. It's all hex, because there is
no way to decode the data safely outside the UTF-8 locale. And this is also
the world the installer remains in when it parses ifconfig scan output.

Reply via email to