From: Ted Zlatanov <tzz@lifelogs•com>
To: Jeff King <peff@peff•net>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] git-send-email: add ~/.authinfo parsing
Date: Mon, 04 Feb 2013 11:40:54 -0500 [thread overview]
Message-ID: <87wquovxpl.fsf@lifelogs.com> (raw)
In-Reply-To: <20130203194148.GA26318@sigill.intra.peff.net> (Jeff King's message of "Sun, 3 Feb 2013 14:41:49 -0500")
On Sun, 3 Feb 2013 14:41:49 -0500 Jeff King <peff@peff•net> wrote:
JK> On Sat, Feb 02, 2013 at 06:57:29AM -0500, Ted Zlatanov wrote:
>> If the file name ends with ".gpg", it will run "gpg --decrypt FILE" and
>> use the output. So non-interactively, that could hang if GPG was
>> waiting for input. Does Git handle that, or should I check for a TTY?
JK> No, git does not do anything special with respect to credential helpers
JK> and ttys (nor should it, since one use of helpers is to get credentials
JK> when there is no tty). I think it is GPG's problem to deal with, though.
JK> We will invoke it, and it is up to it to decide whether it can acquire
JK> the passphrase or not (either through the tty, or possibly from
JK> gpg-agent). So it would be wrong to do the tty check yourself.
JK> I haven't tested GPG, but I assume it properly tries to read from
JK> /dev/tty and not stdin. Your helper's stdio is connected to git and
JK> speaking the credential-helper protocol, so GPG reading from stdin would
JK> either steal your input (if run before you read it), or just get EOF (if
JK> you have read all of the pipe content already). If GPG isn't well
JK> behaved, it may be worth redirecting its stdin from /dev/null as a
JK> safety measure.
In my testing GPG did the right thing, so I think this is OK.
>> Take a look at the proposed patch and let me know if it's usable, if you
>> need a formal copyright assignment, etc.
JK> Overall looks sane to me, though my knowledge of .netrc is not
JK> especially good. Usually we try to send patches inline in the email
JK> (i.e., as generated by git-format-patch), and include a "Signed-off-by"
JK> line indicating that content is released to the project; see
JK> Documentation/SubmittingPatches.
OK, thanks. I will fire that off.
>> +use Data::Dumper;
JK> I don't see it used here. Leftover from debugging?
It's part of my Perl new script skeleton, sorry.
>> + print <<EOHIPPUS;
JK> Cute, I haven't seen that one before.
Heh heh. I've had to explain that one in code review many times. "See,
it's the precursor to the modern horse..."
>> +$0 [-f AUTHFILE] [-d] get
>> +
>> +Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
JK> I don't know if we have a particular policy for items in contrib/, but
JK> this license may be too vague. In particular, it does not explicitly
JK> allow redistribution, which would make Junio shipping a release with it
JK> a copyright violation.
JK> Any objection to just putting it under some well-known simple license
JK> (GPL, BSD, or whatever)?
No, I didn't know what Git requires, and I'd like it to be the least
restrictive, so BSD is OK. Stated in -h now.
>> +if ($file =~ m/\.gpg$/)
>> +{
>> + $file = "gpg --decrypt $file|";
>> +}
JK> Does this need to quote $file, since the result will get passed to the
JK> shell? It might be easier to just use the list form of open(), like:
JK> my @data = $file =~ /\.gpg$/ ?
JK> load('-|', qw(gpg --decrypt), $file) :
JK> load('<', $file);
JK> (and then obviously update load to just dump all of @_ to open()).
Yes, thanks. Done.
>> +die "Sorry, we could not load data from [$file]"
>> + unless (scalar @data);
JK> Probably not that interesting a corner case, but this means we die on an
JK> empty .netrc, whereas it might be more sensible for it to behave as "no
JK> match".
JK> For the same reason, it might be worth silently exiting when we don't
JK> find a .netrc (or any of its variants). That lets people who share their
JK> dot-files across machines configure git globally, even if they don't
JK> necessarily have a netrc on every machine.
OK; done.
>> +# the query
>> +my %q;
>> +
>> +foreach my $v (values %{$options{tmap}})
>> +{
>> + undef $q{$v};
>> +}
JK> Just my personal style, but I find the intent more obvious with "map" (I
JK> know some people find it unreadable, though):
JK> my %q = map { $_ => undef } values(%{$options{tmap}});
Yes, changed.
>> +while (<STDIN>)
>> +{
>> + next unless m/([a-z]+)=(.+)/;
JK> We don't currently have any exotic tokens that this would not match, nor
JK> do I plan to add them, but the credential documentation defines a valid
JK> line as /^([^=]+)=(.+)/.
JK> It's also possible for the value to be empty, but I do not think
JK> off-hand that current git will ever send such an empty value.
Yes, changed.
JK> The rest of it looks fine to me. I don't think any of my comments are
JK> show-stoppers. Tests would be nice, but integrating contrib/ stuff with
JK> the test harness is kind of a pain.
"I tested it on AIX, it works great!" :)
It's pretty easy to write a local Makefile with a test target, if you
think it worthwhile.
Ted
next prev parent reply other threads:[~2013-02-04 16:41 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 19:13 [PATCH] git-send-email: add ~/.authinfo parsing Michal Nazarewicz
2013-01-29 19:53 ` Junio C Hamano
2013-01-29 21:08 ` [PATCHv2] " Michal Nazarewicz
2013-01-29 22:38 ` Junio C Hamano
2013-01-30 0:03 ` [PATCHv3] " Michal Nazarewicz
2013-01-30 0:34 ` Junio C Hamano
2013-01-30 7:43 ` [PATCH] " Jeff King
2013-01-30 15:57 ` Junio C Hamano
2013-01-31 15:23 ` Ted Zlatanov
2013-01-31 19:38 ` Jeff King
2013-02-02 11:57 ` Ted Zlatanov
2013-02-03 19:41 ` Jeff King
2013-02-04 16:40 ` Ted Zlatanov [this message]
2013-02-04 16:42 ` [PATCH 1/3] Add contrib/credentials/netrc with GPG support Ted Zlatanov
2013-02-04 16:57 ` Ted Zlatanov
2013-02-04 17:24 ` Junio C Hamano
2013-02-04 18:33 ` Ted Zlatanov
2013-02-04 19:06 ` Junio C Hamano
2013-02-04 19:40 ` Ted Zlatanov
2013-02-04 23:10 ` Junio C Hamano
2013-02-06 15:10 ` CodingGuidelines Perl amendment (was: [PATCH 1/3] Add contrib/credentials/netrc with GPG support) Ted Zlatanov
2013-02-06 16:29 ` CodingGuidelines Perl amendment Junio C Hamano
2013-02-06 17:45 ` demerphq
2013-02-06 18:08 ` Ted Zlatanov
2013-02-06 18:14 ` Junio C Hamano
2013-02-06 18:18 ` demerphq
2013-02-06 17:55 ` [PATCH] Update CodingGuidelines for Perl 5 Ted Zlatanov
2013-02-06 18:05 ` CodingGuidelines Perl amendment Ted Zlatanov
2013-02-06 18:16 ` Junio C Hamano
2013-02-06 18:27 ` Ted Zlatanov
2013-02-06 18:25 ` demerphq
2013-02-06 18:35 ` Ted Zlatanov
2013-02-06 18:44 ` demerphq
2013-02-06 18:54 ` Ted Zlatanov
2013-02-06 19:37 ` Junio C Hamano
2013-02-06 19:49 ` [PATCH v2] Update CodingGuidelines for Perl 5 Ted Zlatanov
2013-02-04 16:42 ` [PATCH 2/3] Skip blank and commented lines in contrib/credentials/netrc Ted Zlatanov
2013-02-04 16:43 ` [PATCH 3/3] Fix contrib/credentials/netrc minor issues: exit quietly; use 3-parameter open; etc Ted Zlatanov
2013-02-04 17:27 ` Junio C Hamano
2013-02-04 18:41 ` Ted Zlatanov
2013-02-04 16:33 ` [PATCH] git-send-email: add ~/.authinfo parsing Michal Nazarewicz
2013-02-04 17:00 ` Ted Zlatanov
2013-02-04 20:10 ` Jeff King
2013-02-04 20:28 ` Ted Zlatanov
2013-02-04 20:59 ` Jeff King
2013-02-04 21:08 ` Ted Zlatanov
2013-02-04 21:22 ` Jeff King
2013-02-04 21:41 ` Ted Zlatanov
2013-02-05 23:10 ` Junio C Hamano
2013-02-06 8:11 ` Matthieu Moy
2013-02-06 14:53 ` Ted Zlatanov
2013-02-06 15:10 ` Matthieu Moy
2013-02-06 15:58 ` Ted Zlatanov
2013-02-06 16:41 ` Matthieu Moy
2013-02-06 17:40 ` Ted Zlatanov
2013-02-06 18:11 ` [PATCH 0/4] Allow contrib/ to use Git's Makefile for perl code Matthieu Moy
2013-02-06 18:11 ` [PATCH 1/4] Makefile: extract perl-related rules to make them available from other dirs Matthieu Moy
2013-02-07 19:16 ` Junio C Hamano
2013-02-06 18:11 ` [PATCH 2/4] perl.mak: introduce $(GIT_ROOT_DIR) to allow inclusion from other directories Matthieu Moy
2013-02-06 18:11 ` [PATCH 3/4] Makefile: factor common configuration in git-default-config.mak Matthieu Moy
2013-02-07 19:28 ` Junio C Hamano
2013-02-08 17:05 ` Matthieu Moy
2013-02-08 17:31 ` [PATCH 1/2] Makefile: make script-related rules usable from subdirectories Matthieu Moy
2013-02-08 17:31 ` [PATCH 2/2] git-remote-mediawiki: use toplevel's Makefile Matthieu Moy
2013-02-06 18:11 ` [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script Matthieu Moy
2013-02-07 19:28 ` Junio C Hamano
2013-02-08 4:28 ` Jeff King
2013-02-08 17:34 ` Matthieu Moy
2013-02-08 17:43 ` Jeff King
2013-02-08 18:13 ` Junio C Hamano
2013-02-08 18:15 ` Jeff King
2013-02-06 21:57 ` [PATCH] git-send-email: add ~/.authinfo parsing Jeff King
2013-02-06 23:12 ` Ted Zlatanov
2013-02-07 7:08 ` Matthieu Moy
2013-02-07 14:30 ` Ted Zlatanov
2013-02-06 13:26 ` Michal Nazarewicz
2013-02-06 14:47 ` Ted Zlatanov
2013-01-30 15:03 ` Ted Zlatanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wquovxpl.fsf@lifelogs.com \
--to=tzz@lifelogs$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox