Password protected pull and push
wvxvw
Firstly, many thanks to the authors of this project, so far this is
the only sane way to work with git in emacs that I could find :)
However I'm having a problem, which I didn't probably understand
correctly, so, please advise, if you can:
the repository I'm trying to pull or push from has password protected
access. So, when I switch to magit-status buffer and then try to push
or pull I get "Git is already running" message (not prompted for
entering the password or anything). This effectively makes git process
stuck, and I (since I'm not really a pro in emacs) don't know how to
terminate it, unless I restart emacs or go to shell and kill it from
there.
Also, "p" (lowercase) is bound to moving up a line in emacs I'm not
sure, but I think it always was... so, it certainly doesn't pull
anything, it simply navigates up one line :) Or did I again do
something wrong?
Thanks!
Rémi Vanicat
> Hello.
> the repository I'm trying to pull or push from has password protected
> access. So, when I switch to magit-status buffer and then try to push
> or pull I get "Git is already running" message (not prompted for
> entering the password or anything).
Could you:
- Give us the content of the *magit-process* buffer when you have this error
message?
- Give us the result of running C-hv magit-process-connection-type?
> Also, "p" (lowercase) is bound to moving up a line in emacs I'm not
> sure, but I think it always was...
It is F to pull.
--
Rémi Vanicat
Ted Zlatanov
RV> wvxvw <olegs...@gmail.com> writes:
>> the repository I'm trying to pull or push from has password protected
>> access. So, when I switch to magit-status buffer and then try to push
>> or pull I get "Git is already running" message (not prompted for
>> entering the password or anything).
RV> Could you:
RV> - Give us the content of the *magit-process* buffer when you have this error
RV> message?
RV> - Give us the result of running C-hv magit-process-connection-type?
Hi,
I wanted to suggest that on GNU Emacs Magit could use
`auth-source-search' (see (info "auth") for details) to retrieve user
passwords for such interactive prompts. auth-source.el works in XEmacs
too; it's part of Gnus right now but can be unbundled if you want to use
it there. `magit-password' can then be modified to use the matched
string data (key name or user@host) for the search.
Obviously a .netrc file could do this too, but it's much less secure.
auth-source.el supports GPG-encrypted netrc files and can store and
retrieve passwords in the very secure Secrets API. It can also prompt
if the password is not found.
Let me know if anyone is interested and I can provide a patch.
Ted
Oleg Sivokon
Rémi Vanicat
> Thanks for fast reply!
> Here's the content of the *magit-process* buffer:
>
> $ git --no-pager pull -v
> Password:
> (That's, apparently after I tried to pull from remote repository).
>
> Re' the variable:
>
> Possible completions are:
> magit-process-client-buffer
> magit-process-popup-time
>
> EThese are the only ones I have - am I not using the proper version?
Well, you might want to try to use a more recent version that may have
solve your problem.
--
Rémi Vanicat
PJ Weisberg
> Hi,
>
> I wanted to suggest that on GNU Emacs Magit could use
> `auth-source-search' (see (info "auth") for details) to retrieve user
> passwords for such interactive prompts. auth-source.el works in XEmacs
> too; it's part of Gnus right now but can be unbundled if you want to use
> it there. `magit-password' can then be modified to use the matched
> string data (key name or user@host) for the search.
At the moment Magit actually *never* asks for a password; it invokes
Git as a subprocess, and Git asks for a password if needed. I've
found a scenario where this fails under GNU/Linux [1], and I don't
know if it ever works under Windows [2].
I, for one, would certainly welcome a solution that works all the time.
[1] https://github.com/magit/magit/issues/154
[2] https://github.com/magit/magit/issues/188
--
-PJ
Yann Hodique
> I wanted to suggest that on GNU Emacs Magit could use
> `auth-source-search' (see (info "auth") for details) to retrieve user
> passwords for such interactive prompts. auth-source.el works in XEmacs
> too; it's part of Gnus right now but can be unbundled if you want to use
> it there. `magit-password' can then be modified to use the matched
> string data (key name or user@host) for the search.
> Obviously a .netrc file could do this too, but it's much less secure.
> auth-source.el supports GPG-encrypted netrc files and can store and
> retrieve passwords in the very secure Secrets API. It can also prompt
> if the password is not found.
> Let me know if anyone is interested and I can provide a patch.
Hi Ted,
thanks for the offer. I, for one, would be very interested to see how
it's done and to work with you on integrating it properly if need be.
Our current way of handling authentication is quite limited
and I suspect most of us just use ssh-agent to workaround the problem.
I don't think we want to provide auth-source.el ourselves, just using it
when available should be sufficient as it's been around in GNU Emacs for
a while now (we can document the steps to make it available
though). That said, I think it would be a good idea in general to make
it fully separate from Gnus :)
As a side note, I'm working on a GitHub API to prepare the ground for
future Magit extensions, and I'd be more than happy to delegate
authentication handling to auth-source.el as well :)
Thanks,
Yann.
--
We tend to become like the worst in those we oppose.
-- Bene Gesserit Coda
Rémi Vanicat
> Thanks again, just to make sure I'm using the last version:
>
> https://github.com/magit/magit/downloads
> I've got it from here (I indeed used something older before).
> The downloaded archive has 1.0.0 in it's name, so I assume the version
> number is 1.0.0.
Could you now try with my master tree:
git://github.com/vanicat/magit.git I just push a would be patch.
>
> Now I do have the magit-process-connection-type and the overall behavior is
> slightly different. However there is no prompt when I try to pull changes.
> The status bar shows (Magit pull) and the *magit-process* buffer shows the
> same message I posted before.
>
> Here's the description for magit-process-connection-type:
>
> magit-process-connection-type is a variable defined in `magit.el'.
> Its value is t
>
> Documentation:
> Connection type used for the git process.
>
> nil mean pipe, it is usually faster and more efficient, and work on cygwin.
> t mean pty, it enable magit to prompt for passphrase when needed.
>
> You can customize this variable.
>
> So, it seems to be "as prescribed".
> Now, let's see if anything of my settings may be affecting it: I'm on Ubuntu
> 10.4 32 bit (have to *sigh*), using Gnome desktop, if that matters, bash is
> my default shell... well, don't know what other info you may need.
>
> Thanks.
--
Rémi Vanicat
Oleg Sivokon
Rémi Vanicat
> Hi Remi, sorry, it doesn't fix it:
>
> Running git pull -v
> error in process filter: cond: Wrong number of arguments: string-match, 1
> error in process filter: Wrong number of arguments: string-match, 1
>
> This is the error I'm getting when I try to either "F" or M-x magit-pull.
>
Sorry, my mistake, I forgot an arguments to one function. It should be
corrected by now, please try again.
[...]
--
Rémi Vanicat
Oleg Sivokon
Ted Zlatanov
>>>>>> "Ted" == Ted Zlatanov <t...@lifelogs.com> writes:
>> I wanted to suggest that on GNU Emacs Magit could use
>> `auth-source-search' (see (info "auth") for details) to retrieve user
>> passwords for such interactive prompts. auth-source.el works in XEmacs
>> too; it's part of Gnus right now but can be unbundled if you want to use
>> it there. `magit-password' can then be modified to use the matched
>> string data (key name or user@host) for the search.
>> Obviously a .netrc file could do this too, but it's much less secure.
>> auth-source.el supports GPG-encrypted netrc files and can store and
>> retrieve passwords in the very secure Secrets API. It can also prompt
>> if the password is not found.
>> Let me know if anyone is interested and I can provide a patch.
YH> thanks for the offer. I, for one, would be very interested to see how
YH> it's done and to work with you on integrating it properly if need be.
YH> Our current way of handling authentication is quite limited
YH> and I suspect most of us just use ssh-agent to workaround the problem.
OK. Is the Git CLI interaction in `magit-password' the only place I
need to fix? I don't think Magit does anything else with passwords,
right? See below about askpass...
YH> I don't think we want to provide auth-source.el ourselves, just using it
YH> when available should be sufficient as it's been around in GNU Emacs for
YH> a while now (we can document the steps to make it available
YH> though). That said, I think it would be a good idea in general to make
YH> it fully separate from Gnus :)
It is separate and lives in the Emacs 23.2+ and trunk (24.x eventually)
distributions. For XEmacs people would have to get it externally. I'll
just use it if `auth-source-search' or `auth-source-user-or-password'
(the older API) are fboundp and maybe the Magit installation
instructions can mention where to get it and point to (info "auth").
YH> As a side note, I'm working on a GitHub API to prepare the ground for
YH> future Magit extensions, and I'd be more than happy to delegate
YH> authentication handling to auth-source.el as well :)
OK, you'll see the changes are trivial so this is no big deal.
On Wed, 25 May 2011 09:07:02 -0700 PJ Weisberg <pjwei...@gmail.com> wrote:
PW> At the moment Magit actually *never* asks for a password; it invokes
PW> Git as a subprocess, and Git asks for a password if needed. I've
PW> found a scenario where this fails under GNU/Linux [1], and I don't
PW> know if it ever works under Windows [2].
PW> I, for one, would certainly welcome a solution that works all the time.
PW> [1] https://github.com/magit/magit/issues/154
PW> [2] https://github.com/magit/magit/issues/188
I still need to plug into `magit-password' which operates against the
STDOUT of the Git subprocess. This could be avoided if Git (actually
libcurl I think) could get passwords from a side channel instead of just
looking in ~/.netrc. Currently that's only possible with the askpass
mechanism AFAIK. So, can Magit supply the askpass mechanism through a
shell script (which can in turn communicate back to ELisp) on Unix and a
wrapper batch file on Windows?
On Windows I'm positive that this will depend on the particular flavor
of Git. I know how to do it with MSysGit+GitExtensions on Windows but
there are at least 2 other ways to get Git there.
All of this is optional and can be built later. Working against Git's
STDOUT password prompt will solve people's problem today so it's a good
first step :)
Thanks
Ted
Ted Zlatanov
TZ> OK. Is the Git CLI interaction in `magit-password' the only place I
TZ> need to fix? I don't think Magit does anything else with passwords,
TZ> right? See below about askpass...
Assuming so, here's an untested patch as an initial idea. It
distinguishes between SSH key passphrases and actual passwords.
For older versions of auth-source.el we'll use the
`auth-source-user-or-password' function. But please check the general
idea of this patch and see if it makes sense. Also check the HTTP
auth--without the origin URL I don't know what I'm looking up...
Thanks
Ted
Yann Hodique
> OK. Is the Git CLI interaction in `magit-password' the only place I
> need to fix? I don't think Magit does anything else with passwords,
> right? See below about askpass...
yep, should be the only entry point for authentication.
> It is separate and lives in the Emacs 23.2+ and trunk (24.x eventually)
> distributions. For XEmacs people would have to get it externally. I'll
> just use it if `auth-source-search' or `auth-source-user-or-password'
> (the older API) are fboundp and maybe the Magit installation
> instructions can mention where to get it and point to (info "auth").
yes, we can definitely add something like this in the manual.
Thanks,
Yann.
--
It is your fate, forgetfulness. All of the old lessons of life, you lose and
gain and lose and gain again.
-- Leto II, the Voice of Dar-es-Balat
Rémi Vanicat
> 68a69,70
>> (require 'auth-source nil t)
>>
> 1365,1370c1367,1391
> < (when (or (string-match "^Enter passphrase for key '\\\(.*\\\)': $" string)
> < (string-match "^\\\(.*\\\)'s password:" string))
> < (process-send-string proc
> < (concat (read-passwd
> < (format "Password for '%s': " (match-string 1 string))
> < nil) "\n"))))
I've recently pushed to master a modification to this part of the
code. Could you integrate with it?
Note also that when one is reading "foo's password:" it is actually ssh
asking for a password when there is no ssh-key. When it's git that do the asking, it
just ask for "Password:" (hence the bug for the original poster of this
thread).
[...]
--
Rémi Vanicat
Ted Zlatanov
RV> I've recently pushed to master a modification to this part of the
RV> code. Could you integrate with it?
Attached.
RV> Note also that when one is reading "foo's password:" it is actually ssh
RV> asking for a password when there is no ssh-key. When it's git that do the asking, it
RV> just ask for "Password:" (hence the bug for the original poster of this
RV> thread).
OK, I didn't get that. See my TODO comments regarding more things we
can do there, especially the origin.url if we can get it.
I changed things a bit so please let me know if any of the code is wrong
or broken. When this iteration is acceptable I'll add the backwards
compatibility calls to `auth-source-user-or-password' as well.
Also my original message asked about askpass; that's much more reliable
than parsing CLI output and works in Unix and Windows (with msysgit at
least). Could Magit support that?
It may be productive to give me commit access to the Github repo as I
have some other Magit things in my queue. It's not a big deal, just
don't make me do the Github-specific fork+pull request procedure :)
Ted
Rémi Vanicat
> On Fri, 27 May 2011 20:39:28 +0200 Rémi Vanicat <van...@debian.org> wrote:
>
> RV> I've recently pushed to master a modification to this part of the
> RV> code. Could you integrate with it?
>
> Attached.
>
> RV> Note also that when one is reading "foo's password:" it is actually ssh
> RV> asking for a password when there is no ssh-key. When it's git that do the asking, it
> RV> just ask for "Password:" (hence the bug for the original poster of this
> RV> thread).
>
> OK, I didn't get that. See my TODO comments regarding more things we
> can do there, especially the origin.url if we can get it.
We are not always pulling from origin. We should care to not falsely ask
the wrong password...
>
> I changed things a bit so please let me know if any of the code is wrong
> or broken. When this iteration is acceptable I'll add the backwards
> compatibility calls to `auth-source-user-or-password' as well.
>
> Also my original message asked about askpass; that's much more reliable
> than parsing CLI output and works in Unix and Windows (with msysgit at
> least). Could Magit support that?
For this to work we need a script that call Something like
--8<---------------cut here---------------start------------->8---
#!/bin/sh
emacsclient -e "(magit-ask-password \"$*\")"
--8<---------------cut here---------------end--------------->8---
where magit-ask-password would be a new function dealing with the actual
asking.
Then if we setenv SSH_ASKPASS to it, both git and ssh will use it for
asking password. (If we want this only for git it's GIT_ASKPASS we have
to set)
problems with this are:
- this might not work as easily on windows and Mac OS X
- we will need to install this script somewhere. It make magit
installation more complex, particularly for user of the git version
and those who install themselves.
An advantage would be to get ride of the problem that make us use
magit-process-connection-type and just use nil for its value.
> It may be productive to give me commit access to the Github repo as I
> have some other Magit things in my queue. It's not a big deal, just
> don't make me do the Github-specific fork+pull request procedure :)
I will look at your code later, but please, do fork and request
pull. It's really easy, and it's our standard procedure for dealing with
new contributor and review there code.
It's also the place where I go when I want to look at code review I
wanted to do and forget.
[...]
--
Rémi Vanicat
Ted Zlatanov
>> Also my original message asked about askpass; that's much more reliable
>> than parsing CLI output and works in Unix and Windows (with msysgit at
>> least). Could Magit support that?
RV> For this to work we need a script that call Something like
RV> #!/bin/sh
RV> emacsclient -e "(magit-ask-password \"$*\")"
RV> where magit-ask-password would be a new function dealing with the actual
RV> asking.
RV> Then if we setenv SSH_ASKPASS to it, both git and ssh will use it for
RV> asking password. (If we want this only for git it's GIT_ASKPASS we have
RV> to set)
We should do both (the HTTP transport is important).
RV> problems with this are:
RV> - this might not work as easily on windows and Mac OS X
RV> - we will need to install this script somewhere. It make magit
RV> installation more complex, particularly for user of the git version
RV> and those who install themselves.
It will work on Mac OS X, emacsclient works there and so do shell
scripts. On Windows I can provide a tcl/tk based askpass (cloned from
the standard one and adding some trivial password encryption) that works
in msysgit.
The script for Unix systems is very trivial. It could be created at the
time it's needed as a temp-file.
RV> An advantage would be to get ride of the problem that make us use
RV> magit-process-connection-type and just use nil for its value.
Of course, and you could keep using the old approach on Windows if the
tcl/tk approach doesn't work there.
>> It may be productive to give me commit access to the Github repo as I
>> have some other Magit things in my queue. It's not a big deal, just
>> don't make me do the Github-specific fork+pull request procedure :)
RV> I will look at your code later, but please, do fork and request
RV> pull. It's really easy, and it's our standard procedure for dealing with
RV> new contributor and review there code.
RV> It's also the place where I go when I want to look at code review I
RV> wanted to do and forget.
I really don't like to use and depend on Github (hence my request to
avoid it earlier). Is there something wrong with submitting patches?
I prefer the clarity and transparency of the patch-based process, plus
patches in an e-mail leave a record in the mailing list instead of a
vague trail somewhere on the web.
Ted
Ted Zlatanov
the auth-source and other things I proposed? Are you waiting for me to
implement things?
Thanks
Ted
Rémi Vanicat
Sorry, I didn't had time for the two last week to look at it. I will
have time next week>
--
Rémi Vanicat