On Wed, Feb 06, 2008 at 02:57:39AM -0500, Kris Jurka wrote:
>
>
> On Tue, 5 Feb 2008, Tom Lane wrote:
>
> >The problem seems to be that AuthenticationGSSContinue messages carry
> >a variable-length payload, and the V2 protocol doesn't really cope with
> >that because it doesn't have a message length word.
> >
> >1. If the GSSContinue payload is self-identifying about its length,
> >qwe could teach fe-connect.c how to determine that.
>
> The GSS data is supposed to be opaque to the caller, so this doesn't
> seem likely or a good idea.
Yeah, agreed, that seems like a very fragile idea.
> >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.
//Magnus