Re: sslmode=secure by default (Re: Making sslrootcert=system work on Windows psql)
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Christoph Berg <myon@debian.org>,
George MacKerron <george@mackerron.co.uk>, Daniel Gustafsson <daniel@yesql.se>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-25T18:56:38Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
doc: Clarify the system value for sslrootcert
- dda1b0603523 16.9 landed
- daa16893faa9 18.0 landed
- c88b36d382eb 17.5 landed
On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut <peter@eisentraut.org> wrote: > Another detail to think about is how this affects psql -h localhost. In > principle, this should require full SSL, but you're probably not going > to have certificates that allow "localhost". And connections to > localhost are the default on Windows. We could also switch the Windows > default to Unix-domain sockets. But there are probably still other > reasons why connections to TCP/IP localhost are made. Some things to > think about. Yeah, we pretty quickly get to the boring-but-hard part. Is there a group of users we feel comfortable breaking? What ways is it acceptable to break them? How hard should it be for them to unbreak themselves once it happens? It'd be kind of nice if there were a better way than environment variables to configure defaults for the client. I've been looking at openssl.cnf for the Windows certificate problem, and I wish we had that knob available for conversations like this... If we had a global client config, then we could declare that we're going to change the defaults in that config far in advance, and anyone who absolutely hates it can proceed to undo it globally and move on. The service file is IMO not enough for this. --Jacob