> 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: mpn@xxxxxxxxxx>--------------ooO--(_)--Ooo--Attachment:
pgpjXJmFYAPgt.pgp
Description: PGP signature