Stephen Frost <sfrost@snowman.net> writes:
> Let's stop having passwords and secrets in a complex configuration file
> which can have parsing and other failures.
> How about allowing users to put that information in an independent file,
> as do for SSL (admittedly, probably more because it's easier for us to
> deal with OpenSSL that way, but still)?
And then what? This other file can't possibly be so simple that
it's immune to having syntax errors, for example. You're just moving
the same problems from point A to point B. More, this would complicate
configuration and thereby create a whole new set of possible config
errors, which we'd then feel pressure to ameliorate by adding more
logging showing what the postmaster is doing. And that logging would
have this same issue of maybe it's exposing information that person A
doesn't want logged ... even though person B needs that very same info
to help him figure out his configuration mistake. A likely example of
that is feeding the wrong password/secret to some auth infrastructure
service, because you referenced the wrong item in this secondary file.
The core problem here is that we *need* to put security-relevant info
into the postmaster log in order to help people resolve problems. Moving
around configuration details isn't going to fix that; indeed, the more
complicated the configuration files, the worse the problem will be.
regards, tom lane