git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: Andreas Krey <a.krey@gmx.de>,
	Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
	git@vger.kernel.org
Subject: Re: [RFC 0/2] Git-over-TLS (gits://) client side support
Date: Wed, 13 Jan 2010 23:04:14 +0200	[thread overview]
Message-ID: <20100113210414.GA8535@Knoppix> (raw)
In-Reply-To: <32541b131001131213m75b4baefsc70a4cbf3c8431c8@mail.gmail.com>

On Wed, Jan 13, 2010 at 03:13:40PM -0500, Avery Pennarun wrote:
> On Wed, Jan 13, 2010 at 3:06 PM, Ilari Liusvaara
> 
> Lots of people use it.  That was my point.  If it weren't important,
> web browser makers wouldn't bother putting it in; God knows they leave
> out a lot of other stuff that I'd like.

There are two kinds of "important". Actually important for users and
important for managers.
 
The latter tends to be implemented with much less real world need. And
one can usually tell which of those it was from usability of feature.

> >> Furthermore, how many people who really want ssh-style keypairs (and
> >> thus refuse to use X.509 and PKI) can't just use ssh as their git
> >> transport?  I don't actually understand what the goal is here.
> >
> > As said, I got fed up with failure modes of SSH.
> 
> I think this is the answer that needs clarification.  What failure
> modes are these?  ssh doesn't seem to fail for me.  And github.com
> seems to be working rather well with a huge number of users and ssh
> authentication.

Those failure modes tend to be show up at setup phase. But when they
show up, at worst I have seen ones that took hours to debug because
of multitude of possible causes and no good information on what's
wrong.

And don't get me started about multi-key setups.

SSH uses fixed sets of keys, which has inherent failure modes. And ssh
server tends to be worse than the client (Github can avoid the server
failure modes since they control the SSH server).

But not even github can avoid all the failure modes.

> If you're upset at the failure modes of ssh, is it possible to fix ssh
> instead of introducing Yet Another Tunneling Protocol?

No, those failure modes can't be solved in SSH.

-Ilari

  reply	other threads:[~2010-01-13 21:04 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-13 13:19 [RFC 0/2] Git-over-TLS (gits://) client side support Ilari Liusvaara
2010-01-13 13:19 ` [RFC 1/2] Git-over-TLS (gits://) client side support (part 1 of 2) Ilari Liusvaara
2010-01-13 13:19 ` [RFC 2/2] Git-over-TLS (gits://) client side support (part 2 " Ilari Liusvaara
2010-01-13 13:25   ` Alex Riesen
2010-01-13 13:39 ` [RFC 0/2] Git-over-TLS (gits://) client side support Nguyen Thai Ngoc Duy
2010-01-13 13:57   ` Ilari Liusvaara
2010-01-13 14:12     ` Andreas Krey
2010-01-13 14:47       ` Ilari Liusvaara
2010-01-13 16:17         ` Andreas Krey
2010-01-13 17:36           ` Ilari Liusvaara
2010-01-13 18:35             ` Andreas Krey
2010-01-13 19:18               ` Ilari Liusvaara
2010-01-13 19:30                 ` Avery Pennarun
2010-01-13 20:06                   ` Ilari Liusvaara
2010-01-13 20:13                     ` Avery Pennarun
2010-01-13 21:04                       ` Ilari Liusvaara [this message]
2010-01-13 22:03                         ` Avery Pennarun
2010-01-13 22:06                           ` Shawn O. Pearce
2010-01-13 23:00                           ` Ilari Liusvaara
2010-01-13 23:51                             ` Avery Pennarun
2010-01-14  8:51                               ` Ilari Liusvaara
2010-01-14 20:46                                 ` Avery Pennarun
2010-01-14 23:08                                   ` Ilari Liusvaara
2010-01-13 19:40                 ` Andreas Krey
2010-01-13 20:47                   ` Ilari Liusvaara
2010-01-13 19:11     ` Avery Pennarun
2010-01-13 20:00       ` Ilari Liusvaara
2010-01-13 20:13 ` Edward Z. Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100113210414.GA8535@Knoppix \
    --to=ilari.liusvaara@elisanet.fi \
    --cc=a.krey@gmx.de \
    --cc=apenwarr@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).