Opened 5 years ago

Closed 4 years ago

#17719 closed task (implemented)

Evaluate sparkleshare for internal use

Reported by: nickm Owned by: nickm
Priority: High Milestone:
Component: Internal Services/Tor Sysadmin Team Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


We want to migrate all our internal SVN repositories to git too. (Like, the ones that the accountants use.) But to do that effectively, we need a UI experience that doesn't scare nontechnical users and doesn't frustrate technical ones. Sparkleshare has been suggested.

Child Tickets

Change History (3)

comment:1 Changed 5 years ago by nickm

Owner: changed from tpa to nickm
Status: newassigned

I am taking on this task, and will report my results here. :)

comment:2 Changed 5 years ago 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.

comment:3 Changed 4 years ago by nickm

Resolution: implemented
Status: assignedclosed

Evaluation done.

I think the problems above indicate that this isn't such a great idea.

Note: See TracTickets for help on using tickets.