Greetings, * Tom Lane (t...@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
signature.asc
Description: PGP signature
