Обсуждение: Changing gssencmode default in Psycopg

Hello,

several Psycopg users report problems with GSS connection attempts,
which cause regular crashes on Windows and on macOS in multiprocessing
environments. Last report in [1] but looking for `gssencmode` in the
bug tracker will bring up other issues whose solution is to add a
`gssencmode=disable` to the connection string. Similar
errors/solutions can be googled for in other connector libraries
(Perl, Ruby).

Psycopg can use the system libpq, but most people rely on the `binary`
package to install a libpq in their system and use it without the need
of a C compiler on their client. I am considering changing the
parameter default to `disable` [2] in the libpq that we ship in the
macOS binary packages. I would do the same for Windows but, if I
recall correctly, at the moment we don't build a libpq.dll but we use
a pre-compiled one. Linux doesn't seem to require such treatment.

Would there be any shortcoming in doing so, apart from obviously
requiring GSS users to specify prefer/require for the parameter?

Thank you very much

-- Daniele

[1] https://github.com/psycopg/psycopg/issues/1136
[2] https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-connect.c#L136-L141

Hi,

On 2025-08-23 13:26:49 +0200, Daniele Varrazzo wrote:
> several Psycopg users report problems with GSS connection attempts,
> which cause regular crashes on Windows and on macOS in multiprocessing
> environments.

It's also a contention issue on at least linux:

https://postgr.es/m/20240610181212.auytluwmbfl7lb5n%40awork3.anarazel.de

I don't know what the right solution is, but it's really not good that
something as rarely used as gss encryption causes crashes and performance
issues for everyone.

Greetings,

Andres Freund

On Sat, 23 Aug 2025 at 13:26, Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:

> I am considering changing the
> parameter default to `disable` [2] in the libpq that we ship in the
> macOS binary packages.

I also see that in libpq 16 the function `PQconnectionUsedGSSAPI()`
was introduced [1]. This would enable us to detect if a connection is
established on GSS but no parameter was explicitly set in the env var
or connection string.

So, a responsible thing we could do would be to start, in the next
bugfix release, to raise a warning if we detect such combination, and
warn the user about the upcoming change, suggesting them to explicitly
set the connection string parameter or the env var to "prefer" or
"require",

[1]  https://www.postgresql.org/docs/16/libpq-status.html#LIBPQ-PQCONNECTIONUSEDGSSAPI

-- Daniele

On Sat, Aug 23, 2025 at 9:16 AM Andres Freund <andres@anarazel.de> wrote:
> I don't know what the right solution is, but it's really not good that
> something as rarely used as gss encryption causes crashes and performance
> issues for everyone.

This seems as good a time as any to mention that I'd like to
eventually default to `gssencmode=disable sslmode=verify-full`. And to
do that without too much wailing and gnashing of teeth, I'd like to
introduce an /etc config for client-side defaults. I think this would
allow us to make the changes we've really wanted to make for a while,
and then end users can override us if they're certain they don't want
those changes.

I think the sslmode bump will be an easier sell than the gssencmode
drop, though.

On Sat, Aug 23, 2025 at 4:27 AM Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:
> Would there be any shortcoming in doing so, apart from obviously
> requiring GSS users to specify prefer/require for the parameter?

I think that's the big one, but it is a big one. Some nonzero fraction
of users will have their security downgraded from passive, low-effort
encryption to absolutely nothing.

--Jacob