[PATCH] send-email: Defines smtpPassCmd config option

[PATCH] send-email: Defines smtpPassCmd config option

[Leonardo Bras]

Defines smtpPassCmd config option, to allow the user to pass a command
that is used to output the password.

Its useful for users that store the password encrypted on disk, and
want a easy way to send-email without typing it again.

Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
---
 Documentation/config/sendemail.txt |  1 +
 Documentation/git-send-email.txt   |  5 +++--
 git-send-email.perl                | 11 +++++++++++
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt
index 0006faf800..f71e58862d 100644
--- a/Documentation/config/sendemail.txt
+++ b/Documentation/config/sendemail.txt
@@ -34,6 +34,7 @@ sendemail.from::
 sendemail.multiEdit::
 sendemail.signedoffbycc::
 sendemail.smtpPass::
+sendemail.smtpPassCmd::
 sendemail.suppresscc::
 sendemail.suppressFrom::
 sendemail.to::
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0a69810147..8e9da5ed64 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -203,8 +203,9 @@ independently of `--smtp-user`
 Furthermore, passwords need not be specified in configuration files
 or on the command line. If a username has been specified (with
 `--smtp-user` or a `sendemail.smtpUser`), but no password has been
-specified (with `--smtp-pass` or `sendemail.smtpPass`), then
-a password is obtained using 'git-credential'.
+specified (with `--smtp-pass` or `sendemail.smtpPass`, or as an output
+of `sendemail.smtpPassCmd`), then a password is obtained using
+'git-credential'.
 
 --no-smtp-auth::
 	Disable SMTP authentication. Short hand for `--smtp-auth=none`
diff --git a/git-send-email.perl b/git-send-email.perl
index dc95656f75..d953ebb058 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -170,6 +170,7 @@ sub format_2822_time {
 my $smtp;
 my $auth;
 my $num_sent = 0;
+my $smtp_authpass_cmd;
 
 # Regexes for RFC 2047 productions.
 my $re_token = qr/[^][()<>@,;:\\"\/?.= \000-\037\177-\377]+/;
@@ -271,6 +272,7 @@ sub do_edit {
     "smtpserveroption" => \@smtp_server_options,
     "smtpuser" => \$smtp_authuser,
     "smtppass" => \$smtp_authpass,
+    "smtppasscmd" => \$smtp_authpass_cmd,
     "smtpdomain" => \$smtp_domain,
     "smtpauth" => \$smtp_auth,
     "smtpbatchsize" => \$batch_size,
@@ -1303,6 +1305,15 @@ sub smtp_auth_maybe {
 		die "invalid smtp auth: '${smtp_auth}'";
 	}
 
+	# Check password command if password was not provided.
+	if(!defined $smtp_authpass && defined $smtp_authpass_cmd){
+		open my $pass, "$smtp_authpass_cmd |"
+			or die sprintf(__("Could not execute '%s'"), $smtp_authpass_cmd);
+		#Cut newline char
+		$smtp_authpass = substr <$pass>, 0, -1;
+		close($pass);
+	}
+
 	# TODO: Authentication may fail not because credentials were
 	# invalid but due to other reasons, in which we should not
 	# reject credentials.
-- 
2.25.4

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Carlo Marcelo Arenas Belón]

On Fri, May 01, 2020 at 07:51:31AM -0300, Leonardo Bras wrote:
> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
> index 0a69810147..8e9da5ed64 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -203,8 +203,9 @@ independently of `--smtp-user`
>  Furthermore, passwords need not be specified in configuration files
>  or on the command line. If a username has been specified (with
>  `--smtp-user` or a `sendemail.smtpUser`), but no password has been
> -specified (with `--smtp-pass` or `sendemail.smtpPass`), then
> -a password is obtained using 'git-credential'.
> +specified (with `--smtp-pass` or `sendemail.smtpPass`, or as an output
> +of `sendemail.smtpPassCmd`), then a password is obtained using
> +'git-credential'.

this last part on git credential is just undocumented, since it is already
doing so since 4d31a44a08 (git-send-email: use git credential to obtain
password, 2013-02-12)
 
and of course, assuming you use a credential helper that keeps the password
encrypted you could use that instead of this new feature.

having said that, this looks like a good alternative, but might need to
make sure if die makes sense below or would be better to see if you can
still get a password through git credential even if that fails.

maybe the rule of what to do might even need some configuration itself.

Carlo

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Junio C Hamano]

Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:

>> +of `sendemail.smtpPassCmd`), then a password is obtained using
>> +'git-credential'.
>
> this last part on git credential is just undocumented, since it is already
> doing so since 4d31a44a08 (git-send-email: use git credential to obtain
> password, 2013-02-12)
>  
> and of course, assuming you use a credential helper that keeps the password
> encrypted you could use that instead of this new feature.

Up to this point I understand your response.

Documenting that "git send-email" can use "git credential" for its
password store, if it is not already documented, is of course a good
change.

But I am not sure why this is "a good alternative".  Having more
choices that do not offer anything substantially different is a bad
thing.  Is this "new mechanism" better in what way?  Simpler to use?
Faster?  Less error prone?  Something else?

Thanks.

> having said that, this looks like a good alternative, but might need to
> make sure if die makes sense below or would be better to see if you can
> still get a password through git credential even if that fails.
>
> maybe the rule of what to do might even need some configuration itself.
>
> Carlo

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Taylor Blau]

On Fri, May 01, 2020 at 08:50:48AM -0700, Junio C Hamano wrote:
> Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
>
> >> +of `sendemail.smtpPassCmd`), then a password is obtained using
> >> +'git-credential'.
> >
> > this last part on git credential is just undocumented, since it is already
> > doing so since 4d31a44a08 (git-send-email: use git credential to obtain
> > password, 2013-02-12)
> >
> > and of course, assuming you use a credential helper that keeps the password
> > encrypted you could use that instead of this new feature.
>
> Up to this point I understand your response.
>
> Documenting that "git send-email" can use "git credential" for its
> password store, if it is not already documented, is of course a good
> change.

I agree completely.

> But I am not sure why this is "a good alternative".  Having more
> choices that do not offer anything substantially different is a bad
> thing.  Is this "new mechanism" better in what way?  Simpler to use?
> Faster?  Less error prone?  Something else?

Ditto. I don't think that an increased surface-area of possibilities to
specify your password to 'git send-email' is useful. Put another way:
why *not* use the in-built credential helper, which is already
supported?

Would having it documented eliminate some rationale for invoking a
separate program?

> Thanks.
>
> > having said that, this looks like a good alternative, but might need to
> > make sure if die makes sense below or would be better to see if you can
> > still get a password through git credential even if that fails.
> >
> > maybe the rule of what to do might even need some configuration itself.
> >
> > Carlo

Thanks,
Taylor

Re: [PATCH] send-email: Defines smtpPassCmd config option

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On 2020-05-01 at 22:27:23, Taylor Blau wrote:
> On Fri, May 01, 2020 at 08:50:48AM -0700, Junio C Hamano wrote:
> > Documenting that "git send-email" can use "git credential" for its
> > password store, if it is not already documented, is of course a good
> > change.
> 
> I agree completely.

I also concur.

> > But I am not sure why this is "a good alternative".  Having more
> > choices that do not offer anything substantially different is a bad
> > thing.  Is this "new mechanism" better in what way?  Simpler to use?
> > Faster?  Less error prone?  Something else?
> 
> Ditto. I don't think that an increased surface-area of possibilities to
> specify your password to 'git send-email' is useful. Put another way:
> why *not* use the in-built credential helper, which is already
> supported?
> 
> Would having it documented eliminate some rationale for invoking a
> separate program?

I think perhaps many folks aren't aware that you can invoke Git with an
arbitrary shell command as "credential.helper", which of course makes
life a lot easier.  So if you want to invoke a separate command, it's
really as easy as this:

  git config credential.smtp://smtp.crustytoothpaste.net.helper \
    '!f() { echo username=my-username; echo "password=$(my-password-command)"; }; f'

So I think that documenting the use of the credential helper is step 1,
because probably most people _do_ want to use that for their passwords,
and then documenting that credential helpers can be arbitrary shell
commands that speak the protocol is step 2, so that people who don't can
figure out a way to do what they want.

I'll send some patches later which document the latter feature, since I
don't think we mention it anywhere outside of the FAQ.  I actually
didn't know about it until Peff mentioned it to me one time.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Jeff King]

On Fri, May 01, 2020 at 11:59:48PM +0000, brian m. carlson wrote:

> I think perhaps many folks aren't aware that you can invoke Git with an
> arbitrary shell command as "credential.helper", which of course makes
> life a lot easier.  So if you want to invoke a separate command, it's
> really as easy as this:
> 
>   git config credential.smtp://smtp.crustytoothpaste.net.helper \
>     '!f() { echo username=my-username; echo "password=$(my-password-command)"; }; f'
> 
> So I think that documenting the use of the credential helper is step 1,
> because probably most people _do_ want to use that for their passwords,
> and then documenting that credential helpers can be arbitrary shell
> commands that speak the protocol is step 2, so that people who don't can
> figure out a way to do what they want.
> 
> I'll send some patches later which document the latter feature, since I
> don't think we mention it anywhere outside of the FAQ.  I actually
> didn't know about it until Peff mentioned it to me one time.

This is documented, but only recently did it make it out of
Documentation/technical/ and into gitcredentials(7). I don't mind adding
more pointers, though.

It's also being discussed in this thread:

  https://lore.kernel.org/git/63f35287c9ced4d674f938bedd439aefa6c46f41.camel@gmail.com/

about how deep into the rabbit-hole we want to go in terms of showing a
working example. In particular, in your example above I'd consider
checking that "$1" is "get" in the function.

You also could be using credential.*.username. It's twice as many
git-config commands to set up on the command-line, but IMHO the
resulting config file is a little easier to read.

-Peff

Re: [PATCH] send-email: Defines smtpPassCmd config option

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On 2020-05-03 at 09:43:48, Jeff King wrote:
> On Fri, May 01, 2020 at 11:59:48PM +0000, brian m. carlson wrote:
> 
> > I think perhaps many folks aren't aware that you can invoke Git with an
> > arbitrary shell command as "credential.helper", which of course makes
> > life a lot easier.  So if you want to invoke a separate command, it's
> > really as easy as this:
> > 
> >   git config credential.smtp://smtp.crustytoothpaste.net.helper \
> >     '!f() { echo username=my-username; echo "password=$(my-password-command)"; }; f'
> > 
> > So I think that documenting the use of the credential helper is step 1,
> > because probably most people _do_ want to use that for their passwords,
> > and then documenting that credential helpers can be arbitrary shell
> > commands that speak the protocol is step 2, so that people who don't can
> > figure out a way to do what they want.
> > 
> > I'll send some patches later which document the latter feature, since I
> > don't think we mention it anywhere outside of the FAQ.  I actually
> > didn't know about it until Peff mentioned it to me one time.
> 
> This is documented, but only recently did it make it out of
> Documentation/technical/ and into gitcredentials(7). I don't mind adding
> more pointers, though.

Ah, yes, I remembered that series, but forgot that it introduced
documentation for that.

I'll just send a patch that updates the config option to mention the
other cases, since we already document it in gitcredentials(7).
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Carlo Marcelo Arenas Belón]

On Sun, May 03, 2020 at 04:27:57PM +0000, brian m. carlson wrote:
> On 2020-05-03 at 09:43:48, Jeff King wrote:
> > On Fri, May 01, 2020 at 11:59:48PM +0000, brian m. carlson wrote:
> > 
> > > I think perhaps many folks aren't aware that you can invoke Git with an
> > > arbitrary shell command as "credential.helper", which of course makes
> > > life a lot easier.  So if you want to invoke a separate command, it's
> > > really as easy as this:
> > > 
> > >   git config credential.smtp://smtp.crustytoothpaste.net.helper \
> > >     '!f() { echo username=my-username; echo "password=$(my-password-command)"; }; f'
> > > 
> > > So I think that documenting the use of the credential helper is step 1,
> > > because probably most people _do_ want to use that for their passwords,
> > > and then documenting that credential helpers can be arbitrary shell
> > > commands that speak the protocol is step 2, so that people who don't can
> > > figure out a way to do what they want.
> > > 
> > > I'll send some patches later which document the latter feature, since I
> > > don't think we mention it anywhere outside of the FAQ.  I actually
> > > didn't know about it until Peff mentioned it to me one time.
> > 
> > This is documented, but only recently did it make it out of
> > Documentation/technical/ and into gitcredentials(7). I don't mind adding
> > more pointers, though.
> 
> Ah, yes, I remembered that series, but forgot that it introduced
> documentation for that.

if we are going to mention an example or a credential helper specially
tailored to smtp, then the recently reintroduced syntax by Dscho in
9a121b0d22 (credential: handle `credential.<partial-URL>.<key>` again,
2020-04-24), might come up handy IMHO.

Carlo

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Leonardo Bras]

On Fri, 2020-05-01 at 05:53 -0700, Carlo Marcelo Arenas Belón wrote:
> having said that, this looks like a good alternative, but might need to
> make sure if die makes sense below or would be better to see if you can
> still get a password through git credential even if that fails.

Thank you.

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Leonardo Bras]

On Fri, 2020-05-01 at 08:50 -0700, Junio C Hamano wrote:
> Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
> 
> > > +of `sendemail.smtpPassCmd`), then a password is obtained using
> > > +'git-credential'.
> > 
> > this last part on git credential is just undocumented, since it is already
> > doing so since 4d31a44a08 (git-send-email: use git credential to obtain
> > password, 2013-02-12)
> >  
> > and of course, assuming you use a credential helper that keeps the password
> > encrypted you could use that instead of this new feature.
> 
> Up to this point I understand your response.
> 
> Documenting that "git send-email" can use "git credential" for its
> password store, if it is not already documented, is of course a good
> change.
> 
> But I am not sure why this is "a good alternative".  Having more
> choices that do not offer anything substantially different is a bad
> thing.  Is this "new mechanism" better in what way?  Simpler to use?
> Faster?  Less error prone?  Something else?

The main reason would be "simpler to use".
At the point the developer is configuring smtp, adding another line
with 'command to get the password' instead of 'password' is way more
intuitive than configure a credential.

Best regards,
Leonardo Bras

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Leonardo Bras]

On Fri, 2020-05-01 at 23:59 +0000, brian m. carlson wrote:
>   git config credential.smtp://smtp.crustytoothpaste.net.helper \
>     '!f() { echo username=my-username; echo "password=$(my-password-command)"; }; f'

I have tried doing this, with --global, and my config file changed like
this:

[credential "smtp://smtp.gmail.com"]
        helper = "!f() { echo username=mymail@gmail.com; echo
\"password=$(gpg2 -q --for-your-eyes-only --no-tty -d ~/words/imap)\";
}; f"

While sendemail has:
[sendemail]
        smtpServer = smtp.gmail.com
        smtpServerPort = 587
        smtpEncryption = tls
        smtpUser = mymail@gmail.com

Yet still,  I was asked for password:
Password for 'smtp://mymail@gmail.com@smtp.gmail.com:587': 

What have I done wrong?

Best regards,
Leonardo Bras

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Jeff King]

On Mon, May 04, 2020 at 04:49:09PM -0300, Leonardo Bras wrote:

> On Fri, 2020-05-01 at 23:59 +0000, brian m. carlson wrote:
> >   git config credential.smtp://smtp.crustytoothpaste.net.helper \
> >     '!f() { echo username=my-username; echo "password=$(my-password-command)"; }; f'
> 
> I have tried doing this, with --global, and my config file changed like
> this:
> 
> [credential "smtp://smtp.gmail.com"]
>         helper = "!f() { echo username=mymail@gmail.com; echo
> \"password=$(gpg2 -q --for-your-eyes-only --no-tty -d ~/words/imap)\";
> }; f"
> 
> While sendemail has:
> [sendemail]
>         smtpServer = smtp.gmail.com
>         smtpServerPort = 587
>         smtpEncryption = tls
>         smtpUser = mymail@gmail.com
> 
> Yet still,  I was asked for password:
> Password for 'smtp://mymail@gmail.com@smtp.gmail.com:587': 

I think the way the host-matching works, you'd need to put the ":587"
into the credential.*.url config section heading for it to match.

-Peff

Re: [PATCH] send-email: Defines smtpPassCmd config option

[Leonardo Bras]

On Mon, 2020-05-04 at 16:35 -0400, Jeff King wrote:
> Yet still,  I was asked for password:
> > Password for 'smtp://mymail@gmail.com@smtp.gmail.com:587': 
> 
> I think the way the host-matching works, you'd need to put the ":587"
> into the credential.*.url config section heading for it to match.

Oh, that makes sense.
It works, thanks!