6 messages, 3 authors, 2016-06-15 · open the first message on its own page
From: Rémi Vanicat <hidden>
Date: 2016-06-15 22:51:32
Hello, When git is asking for a password (for example for pushing over https) it call the $GIT_ASKPASS script with only "Password: " as a an argument, so when one have several remote, it might not know which one is asking the password. It would be interesting also to plug some sort of password-safe unto git, or some "git-agent". -- Rémi Vanicat
From: Ted Zlatanov <hidden>
Date: 2016-06-15 22:51:32
On Fri, 01 Jul 2011 15:59:09 +0200 Rémi Vanicat [off-list ref] wrote: RV> When git is asking for a password (for example for pushing over https) RV> it call the $GIT_ASKPASS script with only "Password: " as a an argument, RV> so when one have several remote, it might not know which one is asking RV> the password. Seconded, I run into this all the time. A configurable prompt with %h for the host, etc. would be really nice. RV> It would be interesting also to plug some sort of password-safe unto RV> git, or some "git-agent". This would also be really nice. ~/.netrc is not a great place to put passwords for the HTTP transport. In GNU Emacs we have ~/.authinfo.gpg with the same content as ~/.netrc but encrypted by GPG and thus more secure (the user is either prompted for the password, if the file is encrypted symmetrically, or the user simply loads their private key into the GPG agent). I believe all this can be done with the GPGME library. There's also the Secrets API on newer Gnome and KDE installs, which has a pretty nice D-Bus interface. But is this a libcurl feature request? Or can a Git plugin (an alternate HTTPS transport maybe?) handle it? Thanks Ted
From: Ted Zlatanov <hidden>
Date: 2016-06-15 22:51:35
On Fri, 01 Jul 2011 12:04:02 -0500 Ted Zlatanov [off-list ref] wrote: TZ> On Fri, 01 Jul 2011 15:59:09 +0200 Rémi Vanicat [off-list ref] wrote: RV> It would be interesting also to plug some sort of password-safe unto RV> git, or some "git-agent". TZ> This would also be really nice. ~/.netrc is not a great place to put TZ> passwords for the HTTP transport. In GNU Emacs we have ~/.authinfo.gpg TZ> with the same content as ~/.netrc but encrypted by GPG and thus more TZ> secure (the user is either prompted for the password, if the file is TZ> encrypted symmetrically, or the user simply loads their private key into TZ> the GPG agent). I believe all this can be done with the GPGME library. TZ> There's also the Secrets API on newer Gnome and KDE installs, which has TZ> a pretty nice D-Bus interface. TZ> But is this a libcurl feature request? Or can a Git plugin (an TZ> alternate HTTPS transport maybe?) handle it? Ping? I'd like to work on this if it seems like a feasible feature. Thanks Ted
From: Jeff King <hidden>
Date: 2016-06-15 22:51:35
On Thu, Jul 14, 2011 at 09:05:50AM -0500, Ted Zlatanov wrote:
On Fri, 01 Jul 2011 12:04:02 -0500 Ted Zlatanov [off-list ref] wrote: TZ> On Fri, 01 Jul 2011 15:59:09 +0200 Rémi Vanicat [off-list ref] wrote: RV> It would be interesting also to plug some sort of password-safe unto RV> git, or some "git-agent". TZ> This would also be really nice. ~/.netrc is not a great place to put TZ> passwords for the HTTP transport. In GNU Emacs we have ~/.authinfo.gpg TZ> with the same content as ~/.netrc but encrypted by GPG and thus more TZ> secure (the user is either prompted for the password, if the file is TZ> encrypted symmetrically, or the user simply loads their private key into TZ> the GPG agent). I believe all this can be done with the GPGME library. TZ> There's also the Secrets API on newer Gnome and KDE installs, which has TZ> a pretty nice D-Bus interface. TZ> But is this a libcurl feature request? Or can a Git plugin (an TZ> alternate HTTPS transport maybe?) handle it? Ping? I'd like to work on this if it seems like a feasible feature.
Check out: https://github.com/peff/git/commits/jk/http-auth which provides an interface for getting credentials from external helpers. I need to write docs for a few of the top commits before posting the patches to the list, but other than that, it should be fairly solid and usable. And I'd love to get feedback from somebody trying to write a new helper for it (i.e., to tell if the interface to the helpers is good enough). -Peff
From: Ted Zlatanov <hidden>
Date: 2016-06-15 22:51:35
On Thu, 14 Jul 2011 11:00:33 -0400 Jeff King [off-list ref] wrote: JK> On Thu, Jul 14, 2011 at 09:05:50AM -0500, Ted Zlatanov wrote: TZ> This would also be really nice. ~/.netrc is not a great place to put TZ> passwords for the HTTP transport. In GNU Emacs we have ~/.authinfo.gpg TZ> with the same content as ~/.netrc but encrypted by GPG and thus more TZ> secure (the user is either prompted for the password, if the file is TZ> encrypted symmetrically, or the user simply loads their private key into TZ> the GPG agent). I believe all this can be done with the GPGME library. TZ> There's also the Secrets API on newer Gnome and KDE installs, which has TZ> a pretty nice D-Bus interface. JK> Check out: JK> https://github.com/peff/git/commits/jk/http-auth JK> which provides an interface for getting credentials from external JK> helpers. The API is good, but it's not clear from the docs how to configure credential helpers from the user side. From the tests it looks like you set GIT_ASKPASS to them, is that right? And you can also set credential.helper? Where do those helpers fit with the .netrc file? Are they called before or after or instead of the .netrc parse? Linking these with external libraries like GPGME and the Secrets API will be pretty easy and improve the user experience. So I'll be glad to work on it and provide you with feedback. Would you be interested in pushing your patches further after the testing? They seem pretty complete. I'm off-line for the next 10 days or so; I'll start testing when I get back. Thanks for your help Ted
From: Jeff King <hidden>
Date: 2016-06-15 22:51:36
On Fri, Jul 15, 2011 at 12:08:49PM -0500, Ted Zlatanov wrote:
JK> Check out: JK> https://github.com/peff/git/commits/jk/http-auth JK> which provides an interface for getting credentials from external JK> helpers. The API is good, but it's not clear from the docs how to configure credential helpers from the user side. From the tests it looks like you set GIT_ASKPASS to them, is that right? And you can also set credential.helper?
Yes, that is the documentation I need to write before I can send in the patches. :) The answer is that you use "credential.helper". For example: $ git config credential.helper cache $ git push https://your.server/repo.git Username: <input your username> Password: <input your password> ... push happens ... [five minutes pass] $ git push https://your.server/repo.git ... push happens, no auth required ...
Where do those helpers fit with the .netrc file? Are they called before or after or instead of the .netrc parse?
They are what git provides to curl, either because we have "user@" in
the URL, or because we tried curl once and got an HTTP 401. Curl uses
netrc automagically behind the scenes.
So for a URL without "user@" I believe the order would be:
1. Curl tries the request with what's in your netrc (or maybe it
transparently requests and uses the netrc after getting a 401; I'm
not sure).
2. Curl gives us a 401, and we ask for credentials via getpass(). Or a
credential helper, if defined. Any username given in netrc will not
be considered a partial credential (i.e., you will be prompted for
username and password as if netrc didn't exist).
3. If those credentials fail (i.e., we get a 401 again), we quit.
Linking these with external libraries like GPGME and the Secrets API will be pretty easy and improve the user experience. So I'll be glad to work on it and provide you with feedback.
Yes, exactly. I think somebody at GitHub will probably work on OS X
Keychain integration, too.
I personally use a home-grown password safe that is a searchable
gpg-encrypted file (which then gets unlocked by gpg-agent). My helper is
more or less:
-- >8 --
#!/bin/sh
unique=
for i in "$@"; do
case "$i" in
--unique=*) unique=${i#--unique=} ;;
esac
done
# find lines of the form
# example.com.username=me
# example.com.password=mypass
gpg -qd --no-tty $HOME/.pass.gpg |
sed -n 's/^$unique.//p
-- >8 --
(actually, my file format is quite a bit more complex and robust than
that, and I use a perl script to parse it instead of sed, but this was
meant to be illustrative of how simple it could be).
Obviously something integrated with the secrets API would be way nicer,
if you are running GNOME Keyring (that's part of why I pushed it out to
an external helper; there are nearly as many password wallet solutions
as there are users, and everybody will have their favorite).
Would you be interested in pushing your patches further after the testing? They seem pretty complete.
Absolutely. I'm planning on finishing up the docs and posting the patches in the next couple days, so hopefully they will get more feedback and testing there, too. -Peff