On Wed, Dec 17, 2025 at 5:15 AM Zsolt Parragi <[email protected]> wrote: > > 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. > > Those are also bad, but there are also parameter alternatives for all of them.
But if the concern is security, the existence of the parameter alternatives doesn't really seem to help you. > > 2) Do you want these settings to be part of a postgres:// URI? > > Not for debug settings, but if everyone agrees on splitting the CA > into its own setting, it could behave the same way as > sslrootcert/PGSSLROOTCERT. I don't know if everyone does, but I've seen no pushback yet, so I plan to do so (parameter + envvar). I only nested it under debug settings because I thought there was no production use case, and now that Jonathan is saying "yes, I have a production case", that seems good enough. I don't think I need to raise the bar any more than that. > > 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.) > > My concern is not somebody developing libpq directly on Linux, but > more complex situations. Understood (and I'd like to make this better too). But see below. > This is also probably a separate discussion, but what do you think > about introducing a parameter that disables environment variable > fallbacks? Both for existing variables like PGSSLROOTCERT and > new/debug variables like PGOAUTHCAFILE. (by default everything works > as currently; when specified environment variables are ignored) I like the idea of more application control over this, generally. I think the concern that's been raised before, for example with the superuser-can-do-too-much conversations, is: Piecemeal improvements, without a consensus on the end goal, can paradoxically make things less secure. Because now users have a harder time reasoning about the system's behavior and designing for it. It's even worse if committers can't reason about it and start working at cross purposes. For example, if we lock down our envvars and then immediately farm security-critical decisions out to Kerberos or Curl or PAM or etc. which use their own envvars, in what cases is that better than telling application developers that hey, you always need to be careful about sanitizing your environment if you somehow don't trust it? I don't really know (hand-wavy), and I think proposals would need to provide good arguments in favor. Definitely a separate discussion. Thanks, --Jacob
