diff options
author | Joey Hess <joey@kitenet.net> | 2012-09-11 16:16:11 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2012-09-11 16:16:11 -0400 |
commit | d0bcdd1726f8cf9ed1bc9ef578a5a1c839f82366 (patch) | |
tree | 21139c0c9420940d22114ffeb5153fa8d3654712 /doc/design/assistant/blog | |
parent | 4d592aaec2dd73e0244182872ad5f7ac270a73df (diff) |
blog for the day
Diffstat (limited to 'doc/design/assistant/blog')
-rw-r--r-- | doc/design/assistant/blog/day_79__pairing_finished.mdwn | 33 |
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. |