From: Avery Pennarun <apenwarr@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
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 18:51:03 -0500 [thread overview]
Message-ID: <32541b131001131551m38ff02acpdd08d9f0562ac84d@mail.gmail.com> (raw)
In-Reply-To: <20100113230023.GA9171@Knoppix>
On Wed, Jan 13, 2010 at 6:00 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Wed, Jan 13, 2010 at 05:03:45PM -0500, Avery Pennarun wrote:
>> 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.
Perhaps I'm being dense, but I don't understand what you mean by
either of those.
>> 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).
Unfortunately revealing information like that is a compromise; it
helps attackers as well as legitimate users. It's the same reason
login prints "invalid username or password" instead of choosing
between "invalid username" and "invalid password."
If you reveal more information than ssh, you'll be accused of being
less secure. And since the purpose of your protocol is security, this
is a problem.
>> *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.
I don't understand that answer. Couldn't ssh be patched to do
whatever you want? Particularly if it's just better (optional)
diagnostics, you'd think someone would accept the patch for that.
>> Will I have to generate and manage yet another new set of
>> keys to use the new system?
>
> Yes.
Ouch.
>> (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://...
I'm just looking for a justification for why I *shouldn't* like ssh
more. Is the only reason the fact that it might be easier to
initially configure the key exchange?
Avery
next prev parent reply other threads:[~2010-01-13 23:51 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
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 [this message]
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=32541b131001131551m38ff02acpdd08d9f0562ac84d@mail.gmail.com \
--to=apenwarr@gmail.com \
--cc=a.krey@gmx.de \
--cc=git@vger.kernel.org \
--cc=ilari.liusvaara@elisanet.fi \
--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).