> 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. > 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. > Because it's not obviously spraying output all the time, you mean? We > could perhaps be noisier when any UNSAFE setting is in use. Yes, mainly that. And as you mentioned there's already existing behavior like that in the code, so it's nothing new. > Yeah, I'm not entirely happy about it either. Let me think about some > alternatives... I'll try these suggestions and see what they look like - and I'll start a separate thread with it so that this thread can focus on the CA variable. > 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. For example: 1. there is libpq 2. libpq is used by scripting language bindings for python/ruby/etc 3. language libraries are used in ORM frameworks, which have their own configuration interface 4. ORM frameworks are used in web frameworks / other libraries 5. those frameworks/libraries get used by somebody writing an actual webpage/application 6. And that webpage/application gets installed/maintained by an administrator/user, who might or might not be aware of this And we also have Windows/other platforms, where environment variables are less visible. > 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 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)
