105 lines
4 KiB
Markdown
105 lines
4 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 (which always mark it as extended away),
|
|
and chat messages (with empty body tags, so clients don't display them).
|
|
|
|
To these messages, 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 message
|
|
that should be sent to all buddies and other clients using the account (no
|
|
explicit pairing needed), it uses a broadcast presence message containing:
|
|
|
|
<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.
|
|
|
|
To query if other git-annex clients are around, a presence message is used,
|
|
containing:
|
|
|
|
<git-annex xmlns='git-annex' query="" />
|
|
|
|
For pairing, a chat message is sent, containing:
|
|
|
|
<git-annex xmlns='git-annex' pairing="PairReq|PairAck|PairDone uuid" />
|
|
|
|
### git push over XMPP
|
|
|
|
To request that a peer push to us, a chat message can be sent:
|
|
|
|
<git-annex xmlns='git-annex' pushrequest="uuid" />
|
|
|
|
When a peer is ready to send a git push, it sends:
|
|
|
|
<git-annex xmlns='git-annex' startingpush="uuid" />
|
|
|
|
The receiver runs `git receive-pack`, and sends back its output in
|
|
one or more chat messages:
|
|
|
|
<git-annex xmlns='git-annex' rp="">
|
|
007b27ca394d26a05d9b6beefa1b07da456caa2157d7 refs/heads/git-annex report-status delete-refs side-band-64k quiet ofs-delta
|
|
</git-annex>
|
|
|
|
The sender replies with the data from `git push` (which does not need
|
|
to actually be started until this point):
|
|
|
|
<git-annex xmlns='git-annex' sp="">
|
|
data
|
|
</git-annex>
|
|
|
|
When `git receive-pack` edits, the receiver indicates its exit
|
|
status:
|
|
|
|
<git-annex xmlns='git-annex' rpdone="0" />
|
|
|
|
### 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.
|