When we send a directory, we build a temporary zipfile to linearize the
contents for transmission. We store this zipfile inside a
SpooledTemporaryFile, which will hold everything in RAM (for speed) until it
reaches some size threshold, then moves everything over to disk (to avoid
crashing your program as it runs out of memory).
Unfortunately SpooledTemporaryFile doesn't have a default threshold size: if
you don't specify one, it will never switch to the disk-based mode, and
`wormhole send large_directory/` will just use up all your RAM until it
crashes.
I've been using this wrong for five years, since the very beginning of
wormhole's ability to send directories. How embarrassing!
This applies the simple fix: provide a `max_size=` argument, setting the
threshold to 10 MB.
Thanks to @blitz for the report (and my apologies to everyone else who
reported this earlier, to whom I said it was fixed by using
SpooledTemporaryFile, when clearly it was not).
closes#379
These docs were first written back when we had both a blocking and a
non-blocking API. I removed all the blocking code a long time ago, leaving on
the Twisted-based non-blocking API, but I forgot to update the docs to match,
which is why some of the text didn't make much sense.
This test was incorrectly exercising a member of the endpoint record returned
by `Manager.get_endpoints()`. In the test environment, the `.listen` Endpoint
is actually a Mock, so calling e.g. `listen()` on `endpoints.listen` returns
another Mock instead of a Deferred. Twisted's `assertNoResult` used to
tolerate this silently, but as of Twisted-19.10 it throws an error, causing
the test to fail.
The fix is to assert that the record has attributes with the right names, but
not assume they behave like normal Endpoints, and not call `.listen()` on
them.
closes#366
Specifically, this lets the `wormhole tx` side send the VERSIONS message
before input() happens, allowing the `wormhole rx` side to compute and
display the Verifier. This only matters when the receiver sends both PAKE and
VERSIONS in the same turn, which only happens when tab-completion allowed
them to learn the Nameplate early and thus receive the sender's PAKE early.
In the other cases, the receiver sends PAKE and VERSIONS on separate turns,
so the sender doesn't get into this situation.
The bug this fixes is when both sides use --verify, and the receiver uses
tab-completion, then the sender shows the Verifier and waits for
confirmation, but the receiver doesn't show the Verifier until *after* the
sender confirms. So the two users don't have enough information to compare.
Many thanks to Jacek Politowski (@jpolnetpl) for the catch and initial
investigation.
closes#349
Add half-close to dilation API. Fix several bugs exposed by application-level
testing.
refs #344 but doesn't close it yet: I want to call `p.connectionLost()` after
both directions have been closed down
The previous implementation would call the control/receiving Protocol
completely backwards: dataReceived first, then connectionLost, then finally
connectionMade. Which didn't work at all, of course.
When I made it possible to override APPID with a CLI argument (issue #113), I
forgot to also change this w.derive_key() (issue #339). We don't really need
to include APPID in that purpose string at all (the ideal code would be just
`w.derive_key("transit-key", length)`), but we're stuck with it now. Both
sides must use the same derivation process, and it would be pretty
expensive/complicated to negotiate the process ahead of time (and this code
is scheduled to be obsoleted by Dilation anyways).
I added a note to the two sites that use it, and put a local copy of the
APPID there. We should treat that copy as an arbitrary magic string that must
be included for compatibility with existing deployments (potential
file-transfer peers), which is coincidentally similar to the default `APPID`.
closes#339
