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.
regards, tom lane
