From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Changing gssencmode default in Psycopg |
Date: | 2025-08-25 15:27:53 |
Message-ID: | CAOYmi+nUHd8ztwEHLqvgmVD6v_+5jU4aM64Z14p6dqKphWJySg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Aug 23, 2025 at 9:16 AM Andres Freund <andres(at)anarazel(dot)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(dot)varrazzo(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2025-08-25 15:28:49 | Re: Problem in 'ORDER BY' of a column using a created collation? |
Previous Message | Yugo Nagata | 2025-08-25 15:24:27 | Re: vacuumdb --missing-stats-only and permission issue |