From: Michael J Gruber <git@drmicha.warpmail.net>
To: Kyle Neath <kneath@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: The imporantance of including http credential caching in 1.7.7
Date: Thu, 08 Sep 2011 15:17:03 +0200 [thread overview]
Message-ID: <4E68C04F.9060804@drmicha.warpmail.net> (raw)
In-Reply-To: <CAFcyEthuf49_kOmoLmoSSbNJN+iOBpicP4-eFAV5wL5_RffwGg@mail.gmail.com>
Kyle Neath venit, vidit, dixit 07.09.2011 22:14:
> Junio C Hamano <gitster@pobox.com> wrote:
>> If this were a new, insignificant, and obscure feature in a piece of
>> software with mere 20k users, it may be OK to release a new version with
>> the feature in an uncooked shape.
>
> For the sake of my paycheck, I should certainly hope not! I'm not at all
> suggesting we merge what we have in. However, I do think this feature is
> important enough to delay the release. I trust in the judgement of the core
> members to know when something is ready for inclusion in master.
>
> Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> So, it's been a year or more that you've been aware of the importance of
>> this issue (from your/github's perspective), and we hear about it now,
>> at the end of the rc phase.
>
> I apologize if it sounds like that. I've been discussing this situation with
> many people (including Jeff King) for a very long time now, and it was my
> understanding that the credential caching was done and simply waiting for a
> new release. This is the first I've heard that it will not be included in
> 1.7.7, so I'm voicing my opinion now. Admittedly, late in the game - and I
> apologize for that.
OK, I've calmed down :)
> I'd be happy to help in any capacity I can. Unfortunately I'm no C hacker, and
> I've accepted that as a character flaw (it's something I'm working on). I'm
> afraid I can't be of much help with the actual code. What I can provide is an
> alternate viewpoint to the core team. A viewpoint of someone who's spent 3
> years trying to make git easier for newcomers.
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?
What I have in mind is a very simple, but secure version of Jeff's
credential-store, respectively his example, somewhat like:
---%<---
STORAGE=$HOME/.credentials
for i in "$@"; do
case "$i" in
--unique=*)
unique=${i#--unique=} ;;
esac
done
key=$(git config get credential.gpgkey) # or error out
if ! test -e "$STORAGE/$unique"; then
mkdir -m 0700 "$STORAGE"
git credential-getpass "$@" | gpg -ear $key >"$STORAGE/$unique"
fi
gpg <"$STORAGE/$unique"
---%<---
Or that in C, probably using Junio's gpg-lib. That would be secure and
useful *if* we can rely on people having a convenient gpg setup
(gpg-agent or such).
So: What credential store/password wallet/etc. can we rely on for this
group? Is gpg fair game?
Michael
next prev parent reply other threads:[~2011-09-08 13:17 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 [this message]
2011-09-08 15:02 ` John Szakmeister
2011-09-08 19:18 ` Jeff King
2011-09-09 8:05 ` Michael J Gruber
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=4E68C04F.9060804@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.