From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Abhishek Chanda <abhishek(dot)becs(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Adding support for SSLKEYLOGFILE in the frontend |
Date: | 2025-03-13 18:29:16 |
Message-ID: | CAOYmi+mY7zBXTqJT6EYP_6sdk7ro8L8ByToKb4f-hU5qnpOxhw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 5, 2025 at 9:21 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> I managed to misunderstand skip blocks in TAP tests in the 0002, so the
> attached version fixes that. It has been failing on Debian in CI which I have
> yet to look into.
Drive-by comment:
> + {"sslkeylogfile", "PGSSLKEYLOGFILE",
> + "", NULL,
> + "SSL-Key-Log-File", "", 0, /* sizeof("") = 0 */
> + offsetof(struct pg_conn, sslkeylogfile)},
Adding the PG prefix to the envvar name addresses my collision
concern, but I think Tom's comment upthread [1] was saying that we
should not provide any envvar at all:
> I think it might be safer if we only accepted it as a connection
> parameter and not via an environment variable.
Is the addition of the PG prefix enough to address that concern too?
(Are people already sanitizing their environments for all PG*
variables?)
Thanks,
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-03-13 18:29:20 | Re: SQLFunctionCache and generic plans |
Previous Message | Christoph Berg | 2025-03-13 18:10:16 | Available disk space per tablespace |