The Welcome class prints a message if the server recommends a CLI version
that's newer than what the client is currently using, but only if the client
is running a "release" version, not a "local" development one. "local"
versions have a "+" in them (at least when Versioneer creates it), but
Welcome was looking for "-" as an indicator. So it was printing the warning
when it shouldn't be.
re-enable the test, and add an extra one
The comments in cmd_send/cmd_receive now enumerate the four cases where we
might notice that things are taking too long, the three cases where we say
something about it, and the two cases where it might be appropriate to give
up automatically (although we don't do that anywhere yet).
Previously, w.when_verified() was documented to fire only after a valid
encrypted message was received, but in fact it fired as soon as the shared
key was derived (before any encrypted messages are seen, so no actual
"verification" could occur yet).
This fixes that, and also adds a new w.when_key() API call which fires at the
earlier point. Having something which fires early is useful for the CLI
commands that want to print a pacifier message when the peer is responding
slowly. In particular it helps detect the case where 'wormhole send' has quit
early (after depositing the PAKE message on the server, but before the
receiver has started). In this case, the receiver will compute the shared
key, but then wait forever hoping for a VERSION that will never come. By
starting a timer when w.when_key() fires, and cancelling it when
w.when_verified() fires, we have a good place to tell the user that something
is taking longer than it should have.
This shifts responsibility for notifying Boss.got_verifier, out of Key and
into Receive, since Receive is what notices the first valid encrypted
message. It also shifts the Boss's ordering expectations: it now receives
B.happy() before B.got_verifier(), and consequently got_verifier ought to
arrive in the S2_happy state rather than S1_lonely.
* InputHelper returns full words, not just suffixes. I liked the fact that
suffixes made it impossible to violate the "all matches will start with
your prefix" invariant, but in practice it was fiddly to work with.
* add ih.when_wordlist_is_available(), so the frontend can block (after
claiming the nameplate) until it can return a complete wordlist to
readline. This helps the user experience, because readline wasn't really
built to work with completions that change over time
* make the Wordlist responsible for appending hyphens to all non-final word
completions. InputHelper remains responsible for hyphens on nameplates.
This makes the frontend simpler, but I may change it again in the future if
it helps non-readline GUI frontends.
* CodeInputter: after claiming, wait for the wordlist rather than returning
an empty list
* PGPWordList: change to match
This has the unfortunate side-effect that e.g. typing "3-yucatan-tu TAB"
shows you completions that include the entire phrase: "3-yucatan-tumor
3-yucatan-tunnel", rather than only mentioning the final word. I'd like to
fix this eventually.
I'm still undecided about whether to add this to the mailbox
properties (revealing it to attackers) or continue to require non-default
wordcounts to be provided as a --code-length= argument to the receiver. So
for now the only place that says count=2 is in the default argument on
get_completions().
This updates the unit tests to checks the system (by running 'locale -a' just
like Click does) to use a UTF-8 -safe locale. It prefers C.UTF-8 if
available, then en_US.UTF-8, then will fall back to any UTF-8 it can find.
My macOS box has en_US.UTF-8 (but not C.UTF-8), and my linux box has
C.UTF-8 (but not en_US.UTF-8). This change doesn't help normal runtime, but
ought to allow the unit tests to run on either platform correctly.
This also changes the can-I-run-wormhole check to use C.UTF-8 instead of
en_US.UTF-8, which seems necessary to hush Click on py3. See issue #127 for
more discusson.
Since input_code() sets the nameplate before setting the rest of the code,
and since the sender's PAKE will arrive as soon as the nameplate is set, we
could got_pake before got_code, and Key wasn't prepared to handle that.
