5108d4b364
Amusingly, I am not really using xmpp ping for pairing. I forgot to put in the ping tag! And when I did, it stopped working, on Google Talk. Seems it handles client to client pings, at least using the same JID, without actually sending them to the end client. My mistake avoided this, and seems to work, so I've left it as-is for now, with just the git-annex tag in an IQ message. Also tested on prosody.
66 lines
2.9 KiB
Markdown
66 lines
2.9 KiB
Markdown
The git-annex assistant uses XMPP to communicate between peers that
|
|
cannot directly talk to one-another. A typical scenario is two users
|
|
who share a repository, that is stored in the [[cloud]].
|
|
|
|
### TODO
|
|
|
|
* Prevent idle disconnection. Probably means sending or receiving pings,
|
|
but would prefer to avoid eg pinging every 60 seconds as some clients do.
|
|
* XMPP pairing
|
|
* git pushes over XMPP (needed for pairing, but also awesome on their own)
|
|
|
|
## design goals
|
|
|
|
1. Avoid user-visible messages. dvcs-autosync uses XMPP similarly, but
|
|
sends user-visible messages. Avoiding user-visible messages lets
|
|
the user configure git-annex to use his existing XMPP account
|
|
(eg, Google Talk).
|
|
|
|
2. Send notifications to buddies. dvcs-autosync sends only self-messages,
|
|
but that requires every node have the same XMPP account configured.
|
|
git-annex should support that mode, but it should also send notifications
|
|
to a user's buddies. (This will also allow for using XMPP for pairing
|
|
in the future.)
|
|
|
|
3. Don't make account appear active. Just because git-annex is being an XMPP
|
|
client, it doesn't mean that it wants to get chat messages, or make the
|
|
user appear active when he's not using his chat program.
|
|
|
|
## protocol
|
|
|
|
To avoid relying on XMPP extensions, git-annex communicates
|
|
using presence messages. These always mark it as extended away.
|
|
To this, it adds its own tag as [extended content](http://xmpp.org/rfcs/rfc6121.html#presence-extended).
|
|
The xml namespace is "git-annex" (not an URL because I hate wasting bandwidth).
|
|
|
|
To indicate it's pushed changes to a git repo with a given UUID, a client uses:
|
|
|
|
<git-annex xmlns='git-annex' push="uuid[,uuid...]" />
|
|
|
|
Multiple UUIDs can be listed when multiple clients were pushed. If the
|
|
git repo does not have a git-annex UUID, an empty string is used.
|
|
|
|
For pairing over XMPP, git-annex uses IQ messages, also containing a
|
|
git-annex tag. The id attribute of the iq tag contains the pairing
|
|
information.
|
|
|
|
### 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.
|
|
|
|
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
|
|
syncing activities can somewhat mask this.
|
|
|
|
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 could replay push notification messages, reusing UUIDs it's
|
|
observed. This would make clients pull repeatedly, perhaps as a DOS.
|