[tor-dev] Git hosting changes, git:// support discontinued

[Jason Cooper]

On Mon, Dec 01, 2014 at 05:49:35AM +0100, Sebastian Hahn wrote:
> Hi Jason,
> 
> On 30 Nov 2014, at 23:32, Jason Cooper <tor at lakedaemon.net> wrote:
> > On Sun, Nov 30, 2014 at 06:48:09PM +0100, Sebastian Hahn wrote:
> >> Access via https:// has been provided for years, and should continue
> >> to work without any hiccups.
> > 
> > No issue there for folks that prefer the extra layer.
> 
> My point is basically that there's no reason not to always use the extra
> layer.

Agreed.

> >> If there are questions or concerns, let's here them.
> > My problem with cancelling access via git:// is that the alternative
> > (https) trains new users to think they need to trust the server.  The
> > fact is they don't.  They need to trust the person identifying himself
> > as Nick Mathewson who holds the private key for 8D29319A.
> 
> We don't just have tor.git up there, a lot of repos don't include a
> single signed commit or even tag.

Yes, this is sad.  And something I'm slowly working on.

> You're right that trusting the server is nothing a good dev should do,
> but I'm also not worried about our demographic here.

Yes, and this is something that came to mind as I thought about it more.
*I* like to pull git trees and build from scratch.  But apparently
that's not the norm any more (am I dating myself? :-P)  I gave up on
attending the local Unix/Linux group because they asked a room of ~35
"Linux fans" who had ever built their own kernel.  Not a single hand...

So, yeah, we probably aren't training end users by requiring https://,
because end users, sadly, are leet when they know how to do 'apt-get
install ...'  vice the Software Center.

> On a tangent, referring to keys by their short (or long, for that
> matter) keyid is not a good idea. How to verify Nick actually has the
> blessing of the Tor project (or any subset of people therein, etc) to
> sign tags is yet another problematic area without a real solution.

Yes, using the 32bit identifier certainly is prone to collisions, but we
also aren't attempting to validate that key in this thread.  At the 2013
Kernel Summit, Linus advised using 12 characters for abbreviated commit
hashes over the current norm of 7.  Same problem, different aspect.

$ git config --add core.abbrev 12 #if you were curious

I know some folks like to use google hangouts to validate keys.  Not
that google is secure in any way, but the level of difficulty to
intercept and modify an interactive audio/video stream makes it almost
as good as face to face.  Any live, interactive stream will do, if it's
user-to-user encrypted, that's even better.

The one problem PGP keys *don't* have is the centralized authority
infrastructure.  Honestly, I much prefer the difficulty of validating
PGP keys over the lack of control and forced trust you get with the CA
system.

> In conclusion: Yes, don't trust the server. I sleep a lot better
> pretending that people don't trust it.

Agreed.

> > I'd much prefer they be taught not to trust the path *or* the server.
> > 
> > Please consider restoring git:// access.
> 
> I have considered it, but my conclusion remains not to do it for now.
> Further discussion is invited.

No problem.  Thanks for hashing it over with me.

thx,

Jason.