On Mon, Oct 1, 2012 at 10:26 AM, Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> wrote: > On 10/01/2012 12:19 PM, Darren Duncan wrote: > >> You should never put your passwords (or private keys) in source control; >> it would be better to use the puppet/bcfg option. > > > That was kind of my point. Puppet / Bcfg2 have the same problem. About a > dozen people have access to our bcfg2 repo than I would want to know the > contents of .pgpass. > > We have twenty machines. If I ever change that file, I have to change it in > 20 places. I'd love to put it in bcfg2, but that necessitates allowing > anyone with access to bcfg2 the ability to read it. No go. Who are those people? Do they have administrative access to the 20 machines? If so, it seems to me that the game is already over. If not, what mechanism do you use to keep them out? Perhaps that mechanism could be extended to cover this case as well; or use host-based authentication on the PG server. > You basically just reiterated my question back to me. ;) I'd like to *stop* > manually copying the files around, but can't because they're completely > plain text. It doesn't matter if it's source control, puppet, bcfg2, > cfengine, or anything else; unauthorized people can read them, and I rather > they didn't. I'm not familiar with those tools, at least not at an administrative level. Don't they allow tiered access so that some things can have stricter access controls? > Encrypted passwords would be nice, but apparently this isn't an option. I don't see how that can work. It sounds like an infinite regress. How do you distribute the key without exposing it? Cheers, Jeff -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
