Re: send-email and credential

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 12, 2019 at 06:00:14PM -0400, D. Ben Knoble wrote:

> I spent a frustrating hour today hoping to setup git-send-email with
> my gmail account. I've been able to confirm the following:
> 
> 1. git credential works
> 
>     # git config credential.helper
>     osxkeychain
>     # git credential fill <<EOF
>     protocol=smtp
>     host=smtp.gmail.com
>     EOF
> 
> outputs the correct username and password for my gmail account.
> 
> 2. I (believe) I setup gitconfig properly:
> 
>     # git config --get-regexp sendemail
>     sendemail.smtpserver smtp.gmail.com
>     sendemail.smtpuser ben.knoble@xxxxxxxxx
>     sendemail.smtpencryption tls
>     sendemail.smtpserverport 587
>     sendemail.multiedit true
>     sendemail.annotate true
> 
> The strange behavior I'm seeing is that git-send-email
> 
> - prompted me via macOS for keychain access (expected). This happened
> twice in a row, during one command invocation.
> - prompted me at the terminal for my gmail password (shudders)
> - stopped prompting me for messages send after that (all within the 15
> minutes of the first two)
> 
> Can anyone confirm/explain what's going on? I've never tried to use
> git-credential or git-send-email before, so I'm new to those (but
> experienced in git).

I don't think the saved password you're showing in step 1 is being
triggered, because Git will send "smtp.gmail.com:587" as the host field.
Try this:

  git \
    -c credential.helper='!exec >/tmp/credential.log 2>&1; cat; echo' \
    send-email ...

which will log the helper request. It probably has:

  host=smtp.gmail.com:587

I don't remember the specifics of how osxkeychain works, but it probably
pulls the port out of that and passes it to the OS keychain code, which
then treats it as a separate service.

So the rest of the behavior makes sense, then, I think:

  1. macOS had to unlock your keychain to check for the entry

  2. finding nothing, Git prompted you for the password

  3. Git then wrote the password to keychain after it was used
     successfully (maybe prompting another keychain password request? I
     don't know how it works), after which it should work without a
     password.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux