From: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Abhishek Chanda <abhishek(dot)becs(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Adding support for SSLKEYLOGFILE in the frontend |
Date: | 2025-03-20 09:39:05 |
Message-ID: | 202503200939.zfwbiggjclfi@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
It seems there's rough consensus on proceeding with a connection param
and no environment variable. TBH it's not very clear to me that an
envvar is a great way to drive this, even if there weren't security
considerations at play, just considering the case of a multithreaded
program that opens two connections ... reading that log file is going to
be super fun.
In initialize_SSL(), the test for conn->sslkeylogfile is inside the
#ifdef for the existance of the SSL function. I think it's better to
log a message (probably just a warning) that says "this feature is not
supported with this TLS library" rather than doing nothing. Silently
failing to act is just painful for the user who then has to go to our
source file to figure out why the setting isn't taking effect.
Thanks,
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)
From | Date | Subject | |
---|---|---|---|
Next Message | Rushabh Lathia | 2025-03-20 09:54:45 | Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints |
Previous Message | Ryo Kanbayashi | 2025-03-20 09:16:44 | [PATCH] PGSERVICEFILE as part of a normal connection string |