Re: [RFC 0/2] Git-over-TLS (gits://) client side support

[Ilari Liusvaara <ilari.liusvaara@elisanet.fi>]

On Wed, Jan 13, 2010 at 05:03:45PM -0500, Avery Pennarun wrote:
> On Wed, Jan 13, 2010 at 4:04 PM, Ilari Liusvaara
> 
> This is still not very illuminating.  How do you know your replacement
> will not have these same failure modes? 

No client-side fallbacks, key auth works pseudonymously. That takes
care of them pretty well.

> If you solve your main
> annoyances with ssh, how do you know you won't introduce any new
> annoying failure modes? 

Ensuring that at least some information make back to client (presuably
enough to figure out the problem).

And then there are few failure modes that can't be helped no matter what
I do (like mistaking protocol for P2P, git:// suffers from that as well).

> *Why* can't ssh be fixed to solve the  problem?

Client side fallbacks (may be desired or not!), service not being
able to intervene on wheither to allow client or not in case of
keypair auth.

>  Will I have to generate and manage yet another new set of
> keys to use the new system?

Yes. 

> You seem to be positioning your implementation as a competitor to
> *all* of ssh, https, and straight TLS (including stunnel),

Only to smart http://, smart https:// and ssh://. 

> and
> moreover, presenting it as superior to all three.  This is surely
> possible (they all suck differently), but it's going to be hard to
> convince people.  And if your new security protocol *only* works with
> git, it loses points automatically against other solutions. 

The general design would be applicable to applications besides git, but
this implementation is git-specific.

And making it work like stunnel? On server-side that could work, but
not on client side (and it would take quite extensive changes to 
git-daemon).

> (Even if
> ssh is hard to set up, I've *already set it up*, so any new
> alternative starts with an immediate negative score.)

Well, if you like SSH more, then use ssh://...

-Ilari