Re: Adding support for SSLKEYLOGFILE in the frontend - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Adding support for SSLKEYLOGFILE in the frontend
Date
Msg-id 68b66b6d-cc59-44f8-bdd2-248d50055740@eisentraut.org
Whole thread Raw
In response to Re: Adding support for SSLKEYLOGFILE in the frontend  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Adding support for SSLKEYLOGFILE in the frontend
List pgsql-hackers
On 13.03.25 19:31, Tom Lane wrote:
> Jacob Champion <jacob.champion@enterprisedb.com> writes:
>> 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?
> 
> Indeed, I was advocating for *no* environment variable.  The PG prefix
> does not comfort me.

It seems to me that the environment variable would be the most useful 
way to use this feature, for example if you want to debug an existing 
program that you can't or don't want to change.

As was mentioned earlier, libcurl uses an environment variable for this. 
  Moreover, the format originated in the NSS library, which also uses an 
environment variable.

So we are here constructing a higher level of security that others don't 
seem to have found the need for.

It's also possible that we should consider the SSLKEYLOGFILE environment 
variable some kind of quasi-standard like PAGER, and we should be using 
exactly that environment variable name like everyone else.




pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: Proposal: manipulating pg_control file from Perl
Next
From: Tomas Vondra
Date:
Subject: Re: Get rid of WALBufMappingLock