> On Mon, Feb 11, 2013 at 05:23:39PM +0100, Michal Nazarewicz wrote:
>> + # TODO: Authentication may fail not because credentials were
>> + # invalid but due to other reasons, in which we should not
>> + # reject credentials.
>> + $auth = Git::credential({
>> + 'protocol' => 'smtp',
>> + 'host' => join(':', $smtp_server, $smtp_server_port),
>> + 'username' => $smtp_authuser,
>> + # if there's no password, "git credential fill" will
>> + # give us one, otherwise it'll just pass this one.
>> + 'password' => $smtp_authpass
>> + }, sub {
>> + my $cred = shift;
>> + return !!$smtp->auth($cred->{'username'}, $cred->{'password'});
>> + });On Mon, Feb 11 2013, Jeff King wrote: > What do we want to do about this TODO? > > I am happy to put it off until it becomes a problem, but I wonder if the > Git::credential() interface is sufficient to express what we would want. > It only allows two return values: true for approve, false for reject. > But we would want a tri-state: approve, reject, indeterminate. Being it tri-state is not a problem. The last can be easily represented by undef. > Reading the Net::SMTP code, it doesn't look like the information is even > available to us (it really just passes out success or failure), so I > don't think we can even make it work now. But it may be better to > prepare the public Git::credential interface for it now, so we do not > have to deal with breaking compatibility later. I guess. I left it as is since git-send-email won't make use of the indeterminate values, but I can add it in this patchset as well. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +----<email/xmpp: m...@google.com>--------------ooO--(_)--Ooo--
pgp25C8yPbugz.pgp
Description: PGP signature
