Re: [PATCH] git-send-email: add ~/.authinfo parsing

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 29 Jan 2013 11:53:19 -0800 Junio C Hamano <gitster@pobox.com> wrote: 

JCH> Makes one wonder why .authinfo and not .netrc; 

JCH> http://www.gnu.org/software/emacs/manual/html_node/auth/Help-for-users.html

JCH> phrases it amusingly:

JCH>         “Netrc” files are usually called .authinfo or .netr
JCH>         nowadays .authinfo seems to be more popular and the
JCH>         auth-source library encourages this confusion by accepting
JCH>         both

I wrote this and the auth-source.el library in Emacs (I'm glad it was
amusing :).  The confusion is further perpetuated by our (in Emacs)
encouragement to use a .authinfo.gpg file, which is then decrypted on
the fly by Emacs through GPG.  The format is the same; by the time
auth-source.el sees the contents, they are plain text since the decoding
happens at the file handler level.

I think it makes sense to write the code to support both
`git-send-email' and credentials.  I have had it in my TODO list for
almost 2 years now to work on credential support, and to support the
~/.authinfo.gpg decoding specifically.  Ideally this would also support
the other formats... Michal, would you be interested in that feature?  I
promise to get off my rear and help out.

>> +The '~/.authinfo' file is read if Text::CSV Perl module is installed
>> +on the system; if it's missing, a notification message will be printed
>> +and the file ignored altogether.  The file should contain a line with
>> +the following format:
>> ++
>> +  machine <domain> port <port> login <user> password <pass>

JCH> It is rather strange to require a comma-separated-values parser to
JCH> read a file format this simple, isn't it?

I'd recommend a hand-crafted parser.  Among other things, you should
accept both "strings" and 'strings' if possible (I've seen both formats
in the wild), and the format is simple enough to avoid the module
dependency.

>> ++
>> +Contrary to other tools, 'git-send-email' does not support symbolic
>> +port names like 'imap' thus `<port>` must be a number.

JCH> Perhaps you can convert at least some popular ones yourself?  After
JCH> all, the user may be using an _existing_ .authinfo/.netrc that she
JCH> has been using with other programs that do understand symbolic port
JCH> names.  Rather than forcing all such users to update their files,
JCH> the patch can work a bit harder for them and the world will be a
JCH> better place, no?

I agree, "port imap" is a nice self-documenting token.  Maybe it can be
interpreted by the program that requests the token with a services
lookup, where supported.

Ted