On 25/03/13 14:31, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Tim Watts (tim.j.watts@kcl.ac.uk) wrote:
>>> I would have to respectfully take another point of view: that that
>>> particular judgement is probably better placed with the sysadmin
>>> rather than a blanket decision by the devs.
>
>> It's not a blanket decision by any means- the current situation is that
>> such an option doesn't exist. It's not "it exists, but we disabled it
>> because we felt like it."
>
>> Were someone to write the code to support such an option, it's entirely
>> possible it'd get committed (though likely with strong caveats about its
>> use in the documentation).
>
> I'm not sure it would. Allowing a fallback would amount to a protocol
> change, meaning that old clients might fail in strange ways. You'd
> need a lot stronger case than has been made here to justify dealing
> with that.
>
Just had a look at a non SSL psql connection with wireshark:
The username is offered. Then the server comes back with:
"Type: Authentication request"
"Authentication type: Plaintext password (3)"
So clearly it's not as simple as the client offering what it feels like.
And whilst I assume it might be possible for the server to have a new
code for
"Authentication type: GSSAPI with Password-Interactive-Fallback"
that's not going to be implicitly backwardly compatible.
Tricky I agree...
I presume the protocol does not allow the server to send a succession of
"Type: Authentication request" packets with different Authentication
types until it deems that one is acceptable?
BTW - I am not seriously proposing this - just for a bit of idea banter
and better understanding by me. If you've all got better things to do,
ignore me :-o
Cheers,
Tim
--
Tim Watts Tel (VOIP): +44 (0)1580 848360
Systems Manager Digital Humanities, King's College London
Systems Messages and Notifications: https://systemsblog.cch.kcl.ac.uk/
Personal Blog: http://squiddy.blog.dionic.net/
"A fanatic is one who can't change his mind and won't change the subject."
