summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/design/assistant/blog/day_79__pairing_finished.mdwn33
-rw-r--r--doc/design/assistant/pairing.mdwn7
2 files changed, 40 insertions, 0 deletions
diff --git a/doc/design/assistant/blog/day_79__pairing_finished.mdwn b/doc/design/assistant/blog/day_79__pairing_finished.mdwn
new file mode 100644
index 000000000..ca4bbc125
--- /dev/null
+++ b/doc/design/assistant/blog/day_79__pairing_finished.mdwn
@@ -0,0 +1,33 @@
+Tons of pairing work, which culminated today in pairing fully working for
+the very first time. And it works great! Type something like "my
+hovercraft is full of eels" into two git annex webapps on the same LAN
+and the two will find each other, automatically set up ssh keys, and sync
+up, like magic. Magic based on math.
+
+* Revert changes made to `authorized_keys` when the user cancels
+ a pairing response. Which could happen if the machine that sent the
+ pairing request originally is no longer on the network.
+* Some fixes to handle lossy UDP better. Particularly tricky at the end
+ of the conversation -- how do both sides reliably know when a
+ conversation is over when it's over a lossy wire? My solution is just
+ to remember some conversatons we think are over, and keep saying
+ "this conversation is over" if we see messages in that conversation.
+ Works.
+* Added a UUID that must be the same in related pairing messages.
+ This has a nice security feature: It allows detection of brute-force
+ attacks to guess the shared secret, after the first wrong guess!
+ In which case the pairing is canceled and a warning printed.
+* That led to a thorough security overview, which I've added to
+ the [[pairing]] page. Added some guards against unusual attacks,
+ like console poisioning attacks. I feel happy with the security
+ of pairing now, with the caveats that only I have reviewed it (and
+ reviewing your own security designs is never ideal), and that the
+ out-of-band shared secret communication between users is only as good
+ as they make it.
+* Found [a bug](https://github.com/yesodweb/yesod/issues/421)
+ in Yesod's type safe urls. At least, I think it's a bug. Worked around it.
+* Got very stuck trying to close the sockets that are opened to send
+ multicast pairing messages. Nothing works, down to and including calling
+ C `close()`. At the moment I have a socket leak. :(
+ I need to understand the details of multicast sockets better to fix this.
+ Emailed the author of the library I'm using for help.
diff --git a/doc/design/assistant/pairing.mdwn b/doc/design/assistant/pairing.mdwn
index fb4f4dd8f..d09c644ee 100644
--- a/doc/design/assistant/pairing.mdwn
+++ b/doc/design/assistant/pairing.mdwn
@@ -74,3 +74,10 @@ is escaped before going to the browser.
.. seems it just doesn't support IPv6. The pairing code in git-annex
does support ipv6, apart from this, it's just broadcasting the messages
that fails. (Pairing over mixed networks is fine.)
+* If there are three assistants on the network, and 2 pair, the third is
+ left displaying a "Pair request from foo" alert, until it's close.
+ Or, if the user clicks the button to pair, it'll get to the
+ "Pairing in progress" alert, which will show forever (until canceled).
+
+ It should be possible for third parties to tell when pairing is done,
+ but it's actually rather hard since they don't necessarily share the secret.