[PATCH] Adding support of backslash escapes to wpa_passphrase program

[Jouni Malinen]

On Thu, Oct 22, 2015 at 04:03:25PM -0700, Josh Lehan wrote:
> I noticed that the wpa_passphrase program does not accept backslash escapes,
> making it difficult to enter text with arbitrary characters.  Here is a
> patch, to add that feature.

I guess it depends on one's view point.. This patch seems to make some
existing cases more difficult to use, e.g., if the passphrase happens to
contain '\'. Furthermore, this breaks the passphrase length validation
step when entering \\\\\\\\ as the passphrase gets accepted and results
in this:

./wpa_passphrase foo
# reading passphrase from stdin
\\\\\\\\
network={
    ssid="foo"
    #psk="\\\\\\\\"
    psk=1e0fd9c7daa277cfa48c73e2d681d0758e1075087d2a234785823a103733810c
}

while the existing behavior for that exact same input is:

# reading passphrase from stdin
\\\\\\\\
network={
    ssid="foof"
    #psk="\\\\\\\\"
    psk=549cc182d3e87bb40db9d16f57b028abca3bee42c69fbfa8b2de84480efbd242
}

In other words, a different PSK.. This is certainly undesired.

> This also allows a convenient 1:1 mapping of the network name strings
> received from the output of "wpa_cli scan_results" or "wpa_cli bss": the
> network name string can be copied verbatim to wpa_passphrase, and its
> backslash escapes will now be processed correctly.
> 
> It also protects the wpa_supplicant.conf file output.  If users have a
> network name with a quotation mark in it, or other mischevious characters,
> things can rapidly go to \xf0\x9f\x92\xa9.  This avoids such breakage, by
> providing the ssid in hex digits format if necessary, as is done for the
> psk.  A commented-out ssid will also be provided as human-readable text to
> accompany it, like the psk.

That #psk="<printf encoded>" is very confusing since uncommenting it
would result in completely different string being parsed. At minimum,
that would need to be psk=P"<print encoded>" which is the encoding for
printf encoded strings in the configuration file.

Anyway, I don't think I can apply this taken into account it changes the
currently expected behavior to something different and can result in
user confusion when there is a sudden change in behavior between
versions.

-- 
Jouni Malinen                                            PGP id EFC895FA