| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Provide list of subscriptions and publications in psql's completion |
| Date: | 2017-02-19 12:43:14 |
| Message-ID: | CAB7nPqSBXFijDSeh9CPPFtAUDoUJ-ZhqcfO4a_rnVLjthJfd2Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Feb 19, 2017 at 8:03 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> If password auth is used, we have to store the password in plaintext
> equivalent somewhere. Meaning it's by definition going to be exposed to
> superusers and replication downstreams.
Another possibility is to mention the use of the new passfile
parameter for connection strings in the docs... This removes the need
to have plain passwords directly stored in the database. Not sure if
that's better though because that still mean that the password is
present in plain format somewhere.
> Or are you suggesting a scheme
> whereby you have to enter all your subscription passwords in a prompt of
> some kind when starting the postmaster, to avoid it?
Thinking about that now we could have a connection string parameter
called for example password_command, that could be used for example
with gpg2 to get back a decrypted password value.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2017-02-19 12:48:26 | Re: Provide list of subscriptions and publications in psql's completion |
| Previous Message | Robert Haas | 2017-02-19 12:35:53 | Re: Instability in select_parallel regression test |