[tor-bugs] #17719 [Tor Sysadmin Team]: Evaluate sparkleshare for internal use

[Tor Bug Tracker & Wiki]

#17719: Evaluate sparkleshare for internal use
-------------------------------+--------------------------
 Reporter:  nickm              |          Owner:  nickm
     Type:  task               |         Status:  assigned
 Priority:  High               |      Milestone:
Component:  Tor Sysadmin Team  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:                     |  Actual Points:
Parent ID:                     |         Points:
  Sponsor:                     |
-------------------------------+--------------------------

Comment (by nickm):

 Sparkleshare: preliminary analysis:

 So, sparkleshare is a program written in Mono (C#) that integrates with
 your system's filesystem UI / backends in order to expose a filesystem-
 like UI on top of an interface to a git repository.  It will happily use
 your ssh-agent key, or maintain its own ssh-rsa key for you.

 The usability is very good.


 It assumes the existence of a notification service so that different
 clients can learn when stuff is changed.  The notification service has no
 authentication or encryption; it sends messages of the form "repository
 ID, commit ID" where both are (in theory) opaque hex strings.  You can
 override the location of the notification server, or run your own.

 There is an option to turn off notifications.  This option does not appear
 to do anything on OSX, since I still see debug log messages about trying
 to connect to the notification server.  You could probably point it at
 localhost:closed_port and have it do nothing that way.  There is no UI on
 OSX to turn this option on or off; you need to edit an xml file.

 The code to run your own notification server is linux-only (because of
 epoll), and written in pure C. I found no holes in the C (which is good),
 but I only looked for 30 minutes or so (which is not enough).  Announcing
 a change seems to be O(N*M) where N is the total number of clients and M
 is the number of repositories each client is watching.   The protocol is
 trivial; I cloned it in Python in less than 2 hours.  My implementation
 should make announcements O(C), where C is the number of clients who
 actually want the announcement.

 Sparkleshare does not appear to support a socks proxy, so if you wanted to
 use it over tor, you would have to just use git by hand.  A post-update
 hook can make the main repository send out notifications.

 There is support for client-side encryption, using CBC-AES or something
 and a passphrase stored locally in plaintext.  This is probably best
 treated as a proof-of-concept.

 Gitolite integration appears to work.

 Sparkleshare wants to handle sparkleshare:// URIs and treat them as
 invitations to new sparkleshare repositories.  I would want to disable
 this anywhere we installed sparkleshare: it seems like an invitation to
 trouble.  To disable this on OSX, there is a binary you can remove.  I'm
 not yet sure about Linux or Windows.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17719#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online