Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Wed, Feb 06, 2008 at 02:57:39AM -0500, Kris Jurka wrote:
>>> On Tue, 5 Feb 2008, Tom Lane wrote:
>>>> 2. We could retroactively redefine the contents of
>>>> AuthenticationGSSContinue as carrying a length word after the
>>>> authentication type code, but only in V2 protocol (so as not to break
>>>> existing working cases). This is pretty ugly but certainly possible.
>>> I see no harm in doing this. What's there now can't work and the change
>>> is self contained. Is there any problem with the password message taking
>>> a "String" datatype instead of Byte[n] with a null byte?
>
>> I agree that this is probabliy the best way, if we can do it. But you do
>> raise a good point - the message that goes the other way can certainly contain
>> embedded NULLs.
>
> I hadn't thought about the response side of the problem, but yeah, it is
> equally broken. To fix that would have to mean that V2 has two
> different password message formats for GSS vs other cases, which I think
> is starting to exceed my threshold of ugliness --- we are now talking at
> least four places needing weird special cases for V2 vs V3 protocol, two
> each in the server and (each) client library. I also quite dislike the
> idea that a password message couldn't even be parsed without context
> knowledge about which auth method it was for.
>
> In retrospect it was a serious error to use the PasswordMessage format
> for GSS responses, but with 8.3 already out the door I'm afraid we
> are stuck with that decision.
>
> I vote we just decide that GSS isn't going to be supported on protocol
> V2, and put a suitable error message into the server for that. It
> doesn't seem to me that this combination is worth the amount of
> contortions it would require to support.
Agreed. The cost is rapidly becoming too high. But we certainly can't
change the protocol for the stuff that actually does work.
//Magnus