git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Jeff King <peff@peff.net>
Cc: John Szakmeister <john@szakmeister.net>,
	Kyle Neath <kneath@gmail.com>,
	git@vger.kernel.org
Subject: Re: The imporantance of including http credential caching in 1.7.7
Date: Fri, 09 Sep 2011 10:05:48 +0200	[thread overview]
Message-ID: <4E69C8DC.7060008@drmicha.warpmail.net> (raw)
In-Reply-To: <20110908191842.GB16064@sigill.intra.peff.net>

Jeff King venit, vidit, dixit 08.09.2011 21:18:
> On Thu, Sep 08, 2011 at 11:02:11AM -0400, John Szakmeister wrote:
> 
>> On Thu, Sep 8, 2011 at 9:17 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>> [snip]
>>> It would be interesting to know what we can rely on in the user group
>>> you're thinking about (which I called ssh-challenged). Setting up ssh
>>> keys is too complicated. Can we require a working gpg setup? They do
>>> want to check sigs, don't they?
>>
>> I don't think you can require a working gpg setup (at least for not
>> addressing the ssh-challenged group).
> 
> Agreed. Anything harder than ssh keys is right out the window, because
> they're always the alternative these people could be using (but can't or
> don't want to).

Sue, the question was: What is easy enough? I hoped that people would be
using gpg to check signed tags, and that there might be a simple,
convenient gnupg installer for Win and Mac which ties into the
respective wallet systems or provides one they use already.

> We could make our own gpg-based password wallet system, but I think it's
> a really bad idea, for two reasons:
> 
>   1. It's reinventing the wheel. Which is bad enough as it is, but is
>      doubly bad with security-related code, because it's very easy to
>      screw something up when you're writing a lot of new code.

So please let's not deploy credential-store...

>   2. It's inconvenient for users. Nobody wants a separate wallet system
>      with its own master password. They want to integrate with the
>      wallet system they're already using. Which is generally going to be
>      way nicer _anyway_, because it's going to be part of the OS and do
>      helpful things like unlock the secret store using their login
>      credentials.

On 1.+2.: The idea/hope was to use an existing wallet system which
people use for gnupg already to store their passphrase. If that is not
used then my suggestion does not help much (the issue of widespread
deployment), though it still is a secure version of credential-store for
those who want a desktop-independent secure credential store.

>>> So: What credential store/password wallet/etc. can we rely on for this
>>> group? Is gpg fair game?
>>
>> I think there probably need to be providers for using Keychain under
>> the Mac, gnome-keyring and kwallet under Linux, and probably something
>> using the wincrypt API under Windows.  I don't think there's a
>> one-store-fits-all solution here, unfortunately. :-(
> 
> Exactly. That's why the helpers communicate via pipes. They don't have
> to be included with core git at all; you should be able to just drop a
> third-party git-credential-foo into your PATH.
> 
>> I'm actually tempted try and work on a couple of those myself.
> 
> Please do! I mentioned a few people working on helpers elsewhere in this
> thread, so you may want to see what they've done and/or coordinate to
> avoid duplicate effort. Let me know if you have trouble finding the
> appropriate threads in the list archive.

It seemed appropriate to leverage GitHub for this:

https://github.com/gitigit/git/wiki/Git-Credentials-Hub

Feel free to add!

Cheers,
Michael

  reply	other threads:[~2011-09-09  8:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-07  5:33 The imporantance of including http credential caching in 1.7.7 Kyle Neath
2011-09-07  7:46 ` Sverre Rabbelier
2011-09-07  8:11   ` Kyle Neath
2011-09-07 11:21 ` Junio C Hamano
2011-09-07 12:56 ` Michael J Gruber
2011-09-07 20:14   ` Kyle Neath
2011-09-07 21:08     ` Junio C Hamano
2011-09-07 23:01     ` Philip Oakley
2011-09-07 23:38       ` Junio C Hamano
2011-09-08 13:17     ` Michael J Gruber
2011-09-08 15:02       ` John Szakmeister
2011-09-08 19:18         ` Jeff King
2011-09-09  8:05           ` Michael J Gruber [this message]
2011-09-09  8:12             ` Miles Bader
2011-09-09 18:27             ` Jeff King
2011-09-08 19:10   ` Jeff King
2011-09-09  8:06     ` Michael J Gruber
2011-09-09 10:15       ` Ted Zlatanov
2011-09-09 10:32         ` John Szakmeister
2011-09-09 10:48           ` Erik Faye-Lund
2011-09-09 10:54             ` John Szakmeister
2011-09-09 13:33               ` Ted Zlatanov
2011-09-09 13:31           ` Ted Zlatanov
2011-09-09 18:34       ` Jeff King

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=4E69C8DC.7060008@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=john@szakmeister.net \
    --cc=kneath@gmail.com \
    --cc=peff@peff.net \
    /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).