On Fri, Dec 12, 2025 at 3:05 AM Zsolt Parragi <[email protected]> wrote: > I implemented a simple patch based on the above suggestion > (PGOAUTHDEBUG=UNSAFE:http...).
Thank you! > I added the new functions into a common source file which gets > included in both the oauth module and libpq. I'm not entirely happy > about this, but I didn't see a better way without duplicating the > code. Yeah, I'm not entirely happy about it either. Let me think about some alternatives... pgcommon is a possibility, as is reworking the API so that it's more ephemeral (these probably don't need to be super performant, so an `inline static` header implementation that reparses the envvar each time might work). > My concern, which is also there with the current version: is an > environment variable the best way to control these settings in a > library included into many applications? Wouldn't it be better to make > these settings in libpq (or the oauth module), and only add the > environment variables to psql? 1) Do you plan to be setting debug variables in production? 2) Do you want these settings to be part of a postgres:// URI? For me the answer to both is "no", so I'm not too excited about adding these as libpq connection parameters. Did you have another idea in mind? > This can be used to inject a CA into an application without the user > noticing it, I don't disagree. But at this point in these conversations, the question posed is typically "is the new risk/reward tradeoff any worse than PGSSLROOTCERT or PGSSLMODE or PGSERVICEFILE (or LD_LIBRARY_PATH or PATH)?" I'd say no, not enough to introduce a new way of configuring things for this particular setting. I've argued in the other direction before [1], but I still feel good about that, because I think a global keylogfile is more sensitive than this. > or without the application developer being aware of the > possibility. Mmm... I'd say that application developers always have to be aware of user environment changes in the context of any Linux programming, let alone libpq client development. The user is generally in partial control of the linker. Nearly every libpq setting is accessible via the environment. (setuid programming is its own specialized skillset for a reason.) Now, if there's any appetite to make the situation better, continuing to add security-critical settings into the environment makes things worse for anyone who wants to propose an alternative. But that's where we stood as of the last related conversation I was involved in. > But by splitting the setting into multiple flags, > this can go unnoticed even in a console application. Because it's not obviously spraying output all the time, you mean? We could perhaps be noisier when any UNSAFE setting is in use. > Another question is what to do with the CA file - currently it remains > a separate (environment) variable, but maybe it could be included in > the option string instead: > PGOAUTHDEBUG=UNSAFE:custom-ca=/path/to/the/file I think I've been convinced by the existence of this thread that we should split PGOAUTHCAFILE out of debug options entirely, pending the resolution of some of the open questions. Thanks, --Jacob [1] https://postgr.es/m/CAOYmi%2BmY7zBXTqJT6EYP_6sdk7ro8L8ByToKb4f-hU5qnpOxhw%40mail.gmail.com
