Steven Siebert <smsiebe@gmail.com> writes:
> Moving the secrets to another file will indeed fix this problem, and I
> really don't think it'll take very much to implement this. As you
> mentioned, this increases the complexity of the configuration process,
> and I certainly don't want to impose our backwards incompatible change
> (on upgrade, they would need to create those new files) on everyone
> else in the community.
I'm not following what's backwards incompatible about it? As I see it,
this would require some new syntax ("@filename" perhaps?) that you
could optionally use in place of a secret. If you had in mind to *force*
people to use out-of-line secret storage, I agree that ain't happening.
> My counter proposal is to optionally allow dbas to encrypt the secrets
> used in the configuration file by substituting the actual password
> with a variable.
This sounds like more complication with no real benefit. Also, we've
generally avoided putting any strong encryption capability into core
Postgres because of worries about US export regulations. Perhaps that
worry is obsolete, but I'm not sure.
regards, tom lane