# [PATCH] send-email: Defines smtpPassCmd config option 13 messages from 2020-05-01 to 2020-05-04. Participants: Leonardo Bras, Carlo Marcelo Arenas Belón, Junio C Hamano, Taylor Blau, brian m. carlson, Jeff King. Thread: https://gitlist.dev/t/53366 ## Leonardo Bras, 2020-05-01 10:51 Subject: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <20200501105131.297457-1-leobras.c@gmail.com> URL: https://gitlist.dev/e/20200501105131.297457-1-leobras.c%40gmail.com ``` 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 --- 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 ``` ## Carlo Marcelo Arenas Belón, 2020-05-01 12:53 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <20200501125308.GE33264@Carlos-MBP> URL: https://gitlist.dev/e/20200501125308.GE33264%40Carlos-MBP In-Reply-To: <20200501105131.297457-1-leobras.c@gmail.com> ``` 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 ``` ## Junio C Hamano, 2020-05-01 15:50 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: URL: https://gitlist.dev/e/xmqqees3odrb.fsf%40gitster.c.googlers.com In-Reply-To: <20200501125308.GE33264@Carlos-MBP> ``` Carlo Marcelo Arenas Belón 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 ``` ## Taylor Blau, 2020-05-01 22:27 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <20200501222723.GF41612@syl.local> URL: https://gitlist.dev/e/20200501222723.GF41612%40syl.local In-Reply-To: ``` On Fri, May 01, 2020 at 08:50:48AM -0700, Junio C Hamano wrote: > Carlo Marcelo Arenas Belón 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 ``` ## brian m. carlson, 2020-05-01 23:59 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <20200501235948.GD6530@camp.crustytoothpaste.net> URL: https://gitlist.dev/e/20200501235948.GD6530%40camp.crustytoothpaste.net In-Reply-To: <20200501222723.GF41612@syl.local> ``` 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 ``` ## Jeff King, 2020-05-03 09:43 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <20200503094348.GE170902@coredump.intra.peff.net> URL: https://gitlist.dev/e/20200503094348.GE170902%40coredump.intra.peff.net In-Reply-To: <20200501235948.GD6530@camp.crustytoothpaste.net> ``` 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 ``` ## brian m. carlson, 2020-05-03 16:27 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <20200503162757.GE6530@camp.crustytoothpaste.net> URL: https://gitlist.dev/e/20200503162757.GE6530%40camp.crustytoothpaste.net In-Reply-To: <20200503094348.GE170902@coredump.intra.peff.net> ``` 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 ``` ## Carlo Marcelo Arenas Belón, 2020-05-03 23:48 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <20200503234834.GA86805@Carlos-MBP> URL: https://gitlist.dev/e/20200503234834.GA86805%40Carlos-MBP In-Reply-To: <20200503162757.GE6530@camp.crustytoothpaste.net> ``` 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..` again, 2020-04-24), might come up handy IMHO. Carlo ``` ## Leonardo Bras, 2020-05-04 19:02 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <6abf695198e969898c56669bd884f2679aebd35a.camel@gmail.com> URL: https://gitlist.dev/e/6abf695198e969898c56669bd884f2679aebd35a.camel%40gmail.com In-Reply-To: <20200501125308.GE33264@Carlos-MBP> ``` 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. ``` ## Leonardo Bras, 2020-05-04 19:09 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: URL: https://gitlist.dev/e/aeff4d773cc69b6845e89a79a6de79d3137b7da2.camel%40gmail.com In-Reply-To: ``` On Fri, 2020-05-01 at 08:50 -0700, Junio C Hamano wrote: > Carlo Marcelo Arenas Belón 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 ``` ## Leonardo Bras, 2020-05-04 19:49 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <306703d7687377d6a74ec9f1d63331580a3c109b.camel@gmail.com> URL: https://gitlist.dev/e/306703d7687377d6a74ec9f1d63331580a3c109b.camel%40gmail.com In-Reply-To: <20200501235948.GD6530@camp.crustytoothpaste.net> ``` 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 ``` ## Jeff King, 2020-05-04 20:35 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: <20200504203556.GA28192@coredump.intra.peff.net> URL: https://gitlist.dev/e/20200504203556.GA28192%40coredump.intra.peff.net In-Reply-To: <306703d7687377d6a74ec9f1d63331580a3c109b.camel@gmail.com> ``` 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 ``` ## Leonardo Bras, 2020-05-04 21:29 Subject: Re: [PATCH] send-email: Defines smtpPassCmd config option Message-ID: URL: https://gitlist.dev/e/d2bc3b0ff43461f14ca7b532554759169cda9e83.camel%40gmail.com In-Reply-To: <20200504203556.GA28192@coredump.intra.peff.net> ``` 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! ```