diff options
| -rw-r--r-- | doc/bugs/Can__39__t_rename___34__here__34___repository.mdwn | 2 | ||||
| -rw-r--r-- | doc/bugs/Hangs_on_creating_repository_when_using_--listen.mdwn | 9 | ||||
| -rw-r--r-- | doc/design/assistant/xmpp.mdwn | 37 |
3 files changed, 42 insertions, 6 deletions
diff --git a/doc/bugs/Can__39__t_rename___34__here__34___repository.mdwn b/doc/bugs/Can__39__t_rename___34__here__34___repository.mdwn index 99c46c92f..af3330670 100644 --- a/doc/bugs/Can__39__t_rename___34__here__34___repository.mdwn +++ b/doc/bugs/Can__39__t_rename___34__here__34___repository.mdwn @@ -28,3 +28,5 @@ Trying to rename the "here" repository fails # End of transcript or log. """]] + +> Made text field for this repository disabled. The current repository has no remote name to edit. [[done]] --[[Joey]] diff --git a/doc/bugs/Hangs_on_creating_repository_when_using_--listen.mdwn b/doc/bugs/Hangs_on_creating_repository_when_using_--listen.mdwn index 54bf27710..913e02cd5 100644 --- a/doc/bugs/Hangs_on_creating_repository_when_using_--listen.mdwn +++ b/doc/bugs/Hangs_on_creating_repository_when_using_--listen.mdwn @@ -35,3 +35,12 @@ WebApp crashed: unable to bind to local socket # End of transcript or log. """]] + +> The problem is that, when a port is specified, it is used for each web +> server started, and the process of making a new repository unavoidably +> requires it to start a second web server instance. This would also affect +> switching between existing repositories in the webapp. I don't see +> any way to make it not crash here, except for ignoring the port it was told +> to use when something else is already listening there. --[[Joey]] + +[[!tag /design/assistant]] diff --git a/doc/design/assistant/xmpp.mdwn b/doc/design/assistant/xmpp.mdwn index 8dadfaf97..627a2229a 100644 --- a/doc/design/assistant/xmpp.mdwn +++ b/doc/design/assistant/xmpp.mdwn @@ -9,6 +9,28 @@ who share a repository, that is stored in the [[cloud]]. See <http://git-annex.branchable.com/design/assistant/blog/day_114__xmpp/#comment-aaba579f92cb452caf26ac53071a6788> * Support registering with XMPP provider from within the webapp, as clients like pidgin are able to do. +* Add an encryption layer that does not rely on trusting the XMPP server's + security (currently it's encrypted only to the server, not end-to-end). + There are a few options for how to generate the key for eg, + AES encryption: + * Do a simple Diffie-Hellman shared key generation when starting each XMPP + push session. Would not protect the users from active MITM by the + XMPP server, but would prevent passive data gathering attacks from + getting useful data. Since the key is ephemeral, would provide + Forward Security. + * Do D-H key generation, but at pairing, not push time. Allows for an + optional confirmation step, using eg, BubbleBabble to compare the + keys out of band. ("I see xebeb-dibyb-gycub-kacyb-modib-pudub-sefab-vifuc-bygoc-daguc-gohec-kuxax .. do you too?") + * Prompt both users for a passphrase when XMPP pairing, and + use SPEKE (or similar methods like J-PAKE) to generate a shared key. + Avoids active MITM attacks. Makes pairing harder, especially pairing + between one's own devices, since the passphrase has to be entered on + all devices. Also problimatic when pairing more than 2 devices, + especially when adding a device to the set later, since there + would then be multiple different keys in use. + * Rely on the user's gpg key, and do gpg key verification during XMPP + pairing. Problimatic because who wants to put their gpg key on their + phone? Also, require the users be in the WOT and be gpg literate. ## design goals @@ -109,9 +131,10 @@ status with a chat message, directed at the sender: ### security -Data git-annex sends over XMPP will be visible to the XMPP -account's buddies, to the XMPP server, and quite likely to other interested -parties. So it's important to consider the security exposure of using it. +Data git-annex sends over XMPP will be visible to the XMPP account's +buddies, and to the XMPP server (and any attacker who has access to the +XMPP server). So it's important to consider the security exposure of using +it. Even if git-annex sends only a single bit notification, this lets attackers know when the user is active and changing files. Although the assistant's other @@ -121,9 +144,11 @@ As soon as git-annex does anything unlike any other client, an attacker can see how many clients are connected for a user, and fingerprint the ones running git-annex, and determine how many clients are running git-annex. -If git-annex sent the UUID of the remote it pushed to, this would let -attackers determine how many different remotes are being used, -and map some of the connections between clients and remotes. +An attacker can observe the UUIDs used for pushes and pairing, and determine +how many different remotes are being used. An attacker could replay push notification messages, reusing UUIDs it's observed. This would make clients pull repeatedly, perhaps as a DOS. + +The XMPP server, or an attacker with access to it can reconstruct the git +repository from data sent in pushes, in part or in whole. |