Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I noticed while investigating [1] that we have one single solitary
> use of setenv(3) in our code base, in secure_open_gssapi().
>
> It's been project policy since 2001 to avoid setenv(), and I notice
> that src/port/win32env.c lacks support for setenv(), making it
> pretty doubtful that the call has the semantics one would wish
> on Windows.
Yeah, that doesn't seem good, though you'd have to be building with MIT
Kerberos for Windows to end up with GSSAPI on a Windows build in the
first place (much more common on Windows is to build with Microsoft SSPI
support instead). Still, it looks like someone went to the trouble of
setting that up on a buildfarm animal- looks like hamerkop has it.
> Now, versions of the POSIX spec released in this century do have setenv(),
> and even seem to regard it as "more standard" than putenv(). So maybe
> there's a case for moving our goalposts and deciding to allow use of
> setenv(). But then it seems like we'd better twiddle win32env.c to
> support it; and I'm not sure back-patching such a change would be wise.
>
> Alternatively, we could change secure_open_gssapi() to use putenv(),
> at the cost of a couple more lines of code.
>
> Thoughts?
So, auth.c already does the song-and-dance for putenv for this exact
variable, but it happens too late if you want to use GSSAPI for an
encrypted connection. Looking at this now, it seems like we should
really just move up where that's happening instead of having it done
once in be-secure-gssapi.c and then again in auth.c. Maybe we could do
it in BackendInitialize..?
Thanks,
Stephen