Leaks personal details / email addresses

[mcorb]

gittorrentd uses 'git config user.name/user.email' to support the full p2p mode of operation, uploading both real name and email address to the BitTorrent tracker.

This is problematic on a few counts:

1. It currently ignores GIT_AUTHOR_NAME and other environment variables that are meant to override it. In my case it submitted a confidential work email address, including division and employer details that should never have been visible to third-parties.

2. The typical user of the gittorrentd command will be mirroring third-party repositories. Identity/key features are only useful for repository authors, and should probably be off by default. Mirroring repos ought to be totally anonymous by default.

3. ISPs filter and log torrent streams, looking for the tiniest scraps of identifiable metadata. Posting your users' real names and email addresses in a BitTorrent transaction is giving away easy lawsuit targets if their neighbour happens to be sharing dubious torrents through the same wifi.

So, I'd suggest putting the publish_mutable_key() behind a command line flag like "--publish". That way the GitHub mirroring will still work and the user can actively consent to associating their personal details with the mirrored repositories using the flag, if that's what they really want.

[cjb]

@mcorb Thanks for the report. I agree with you, so I just pushed an update that removes name/email altogether until we can think about this more. (It still publishes a mutable key, but without identifying values.)

[mcorb]

I concur that removing the code entirely is the best course of action for now. Thanks for the quick patch and point release.

[phuicy]

How about hashing them instead of removing them? so that there is the possibility of identifying pushes, but safe.

[mcorb]

@phuicy It would be prudent to first implement pushes to get a better idea of how things will fit together.

Hashes aren't a strong solution in this space. A desktop computer could hash every public committer ID known to GitHub in a matter of seconds and use that to look up the 'secret' identity trivially, so it wouldn't add much.

I think @cjb wrote about more advanced techniques of identity proof in his blog -- perhaps I'm feeling a little edgy because my details got leaked (my fault, I didn't use a sandbox or throwaway account and this is pre-alpha code), but I'm really comfortable delaying identity work a little bit and helping out with the more interesting problems that need to be solved first on the transport and pack efficiency side, after which the solutions will be clearer.

[phuicy]

That would require a publicly access-able username and email first. So whats the issue.
If you wanted to hide your id you still could!

Although, I agree it should be delayed until pushes have been sorted.