mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
git-annex/doc/design/assistant/xmpp.mdwn

114 lines
4.4 KiB
Text
Raw Normal View History

add xmpp page
2012-10-25 00:05:45 +00:00
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.
update
2012-10-27 04:57:53 +00:00
* XMPP pairing
send git-annex tag in initial presence Will be used for finding other git-annex clients for pairing
2012-10-28 21:07:29 +00:00
* git pushes over XMPP (needed for pairing, but also awesome on their own)
add xmpp page
2012-10-25 00:05:45 +00:00
## 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
switch to silent chat messages for XMPP pairing Along the way, significantly cleaned up Assistant.XMPP, and made XMPP message decoding more efficient.
2012-11-05 19:40:56 +00:00
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).
add xmpp page
2012-10-25 00:05:45 +00:00
The xml namespace is "git-annex" (not an URL because I hate wasting bandwidth).
clean up protocol docs
2012-11-05 19:52:03 +00:00
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:
add xmpp page
2012-10-25 00:05:45 +00:00
only use one push attribute When pushing to multiple UUIDs, combine them all into a single push attribute.
2012-10-25 17:29:18 +00:00
<git-annex xmlns='git-annex' push="uuid[,uuid...]" />
add xmpp page
2012-10-25 00:05:45 +00:00
only use one push attribute When pushing to multiple UUIDs, combine them all into a single push attribute.
2012-10-25 17:29:18 +00:00
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.
add xmpp page
2012-10-25 00:05:45 +00:00
clean up protocol docs
2012-11-05 19:52:03 +00:00
To query if other git-annex clients are around, a presence message is used,
containing:
switch to directed presence for pair requests Testing between Google Talk and prosody, the directed IQ messages were not received. Google Talk probably only relays them between clients using the same account. I first tried even more directed presence, with each client JID being sent a separate presence, but that didn't work on Google Talk, particularly it was ignored when one client sent it to another client using the same account. So, presence directed at the user@host of the client to pair with. Tested working between Google Talk and prosody (in both directions), as well as between two clients with the same account on Google Talk, and two clients with the same account on prosody. Only problem with this form of directed presence is that if I also use it for git pushes, more clients than are interested in a push's data will receive it. So I may need some better approach, or a hybrid between directed IQ and directed presence.
2012-11-04 01:19:59 +00:00
clean up protocol docs
2012-11-05 19:52:03 +00:00
<git-annex xmlns='git-annex' query="" />
For pairing, a chat message is sent, containing:
<git-annex xmlns='git-annex' pairing="PairReq|PairAck|PairDone uuid" />
update xmpp protocol 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.
2012-11-03 23:18:26 +00:00
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
### git push over XMPP
xmpp push control flow It might even work, although nothing yet triggers XMPP pushes. Also added a set of deferred push messages. Only one push can run at a time, and unrelated push messages get deferred. The set will never grow very large, because it only puts two types of messages in there, that can only vary in the client doing the push.
2012-11-08 20:44:23 +00:00
To request that a remote push to us, a chat message can be sent.
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
hooked up XMPP git push send/receive (but not yet control flow)
2012-11-08 18:02:37 +00:00
<git-annex xmlns='git-annex' pushrequest="uuid" />
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
xmpp push control flow It might even work, although nothing yet triggers XMPP pushes. Also added a set of deferred push messages. Only one push can run at a time, and unrelated push messages get deferred. The set will never grow very large, because it only puts two types of messages in there, that can only vary in the client doing the push.
2012-11-08 20:44:23 +00:00
The push request is typically sent directed at the account associated
with the remote, not to a specific client. So it can result in multiple
responses.
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
When a peer is ready to send a git push, it sends:
hooked up XMPP git push send/receive (but not yet control flow)
2012-11-08 18:02:37 +00:00
<git-annex xmlns='git-annex' startingpush="uuid" />
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
xmpp push control flow It might even work, although nothing yet triggers XMPP pushes. Also added a set of deferred push messages. Only one push can run at a time, and unrelated push messages get deferred. The set will never grow very large, because it only puts two types of messages in there, that can only vary in the client doing the push.
2012-11-08 20:44:23 +00:00
If that's a response to a pushrequest, it'll be directed at only the client
that requested the push. If a push request is being initiated, it'll be sent
to the account assicated with the remote.
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
The receiver runs `git receive-pack`, and sends back its output in
xmpp push control flow It might even work, although nothing yet triggers XMPP pushes. Also added a set of deferred push messages. Only one push can run at a time, and unrelated push messages get deferred. The set will never grow very large, because it only puts two types of messages in there, that can only vary in the client doing the push.
2012-11-08 20:44:23 +00:00
one or more chat messages, directed to a specific client:
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
data types and xml generation/parsing for xmpp push
2012-11-07 20:59:18 +00:00
<git-annex xmlns='git-annex' rp="">
007b27ca394d26a05d9b6beefa1b07da456caa2157d7 refs/heads/git-annex report-status delete-refs side-band-64k quiet ofs-delta
</git-annex>
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
xmpp push control flow It might even work, although nothing yet triggers XMPP pushes. Also added a set of deferred push messages. Only one push can run at a time, and unrelated push messages get deferred. The set will never grow very large, because it only puts two types of messages in there, that can only vary in the client doing the push.
2012-11-08 20:44:23 +00:00
The sender replies with the data from `git push`, in
one or more chat messages, directed to the receiver:
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
data types and xml generation/parsing for xmpp push
2012-11-07 20:59:18 +00:00
<git-annex xmlns='git-annex' sp="">
data
</git-annex>
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
When `git receive-pack` edits, the receiver indicates its exit
xmpp push control flow It might even work, although nothing yet triggers XMPP pushes. Also added a set of deferred push messages. Only one push can run at a time, and unrelated push messages get deferred. The set will never grow very large, because it only puts two types of messages in there, that can only vary in the client doing the push.
2012-11-08 20:44:23 +00:00
status with a chat message, directed at the sender:
add xmppgit command; roughed out xmpp push protocol and design
2012-11-06 04:52:35 +00:00
<git-annex xmlns='git-annex' rpdone="0" />
add xmpp page
2012-10-25 00:05:45 +00:00
### 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.
Reference in a new issue Copy permalink