On Thu, Mar 20, 2025 at 6:11 AM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > I'm not saying there's no attack possible here (although I cannot > think of one), but we allow configuring every other SSL option using > an env var^1. So if there is an attack possible, why would that only > apply to being able to control the sslkeylogfile as opposed to e.g. > sslmode or sslrootcert.
(First off: I was specifically referring to the "if X and Y, then it's game over, so might as well Z too" line of argument. I think that kind of reasoning causes problems in OSS security.) I don't think the argument against an envvar is being made from the point of view of consistency. That's not very helpful in security contexts, where we'd rather be inconsistently good/better than consistently bad. (And existing clients that allow an adversary to control the PGSSLROOTCERT environment variable are broken, and have been since, what, 2009? I'm not going to spend energy on that.) The argument is about net-new behavior: is it okay for a new environment variable to silently log key material for all our connections to an arbitrary location on disk? I feel less strongly about it than Tom does, looks like, but the additional risk is definitely not zero. Maybe we could declare a prefix of environment variables to be security-critical or something, to help that concern in the future. OpenSSL 3.5 will add native support for the SSLKEYLOGFILE envvar, but I think they've locked it behind both a build-time option and a default-off configuration setting. And there are moving discussions [1] on whether they might provide a setting to centrally disable the logging callback used in this patch, too. I think Tom's concern has merit, and I think we should move cautiously here. Thanks, --Jacob [1] https://github.com/openssl/openssl/issues/26282
