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

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Jan 13, 2010, 23:00 UTC
Message-ID: <20100113230023.GA9171@Knoppix>
In-Reply-To: <32541b131001131403u162bc6ebpd551ed19aadde7fb@mail.gmail.com>

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://.

Show 5 quoted lines

> 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