summaryrefslogtreecommitdiff
path: root/doc/design/assistant/blog
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2012-09-11 16:16:11 -0400
committerGravatar Joey Hess <joey@kitenet.net>2012-09-11 16:16:11 -0400
commitd0bcdd1726f8cf9ed1bc9ef578a5a1c839f82366 (patch)
tree21139c0c9420940d22114ffeb5153fa8d3654712 /doc/design/assistant/blog
parent4d592aaec2dd73e0244182872ad5f7ac270a73df (diff)
blog for the day
Diffstat (limited to 'doc/design/assistant/blog')
-rw-r--r--doc/design/assistant/blog/day_79__pairing_finished.mdwn33
1 files changed, 33 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.