From: | Alan Evans <alanwevans(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Feature/Suggestion: libpq/psql support for libsecret (formerly gnome-keyring) |
Date: | 2023-11-01 00:24:17 |
Message-ID: | CAMFVOoVoFSu3UQQ+35TiJ97Yns-S=x87SAPL_HN02rgjCh_Fng@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I was working with a user and was looking for a convenient and secure
method of password storage for `psql`. I was reminded of the various
options, `-p password`, PGPASSWORD, .pgpass and so on. I was thinking it
would be cool if psql/libpq could interact with the system keyring on linux
systems, libsecret (formerly gnome-secret, seahorse, etc etc).
It seems like a match made in heaven actually. libpq stores
`hostname:port:database:username:password` and libsecret allows clients to
store arbitrary attributes associated with passwords. Perhaps hostname,
port, database and username for example...
It seems like libpq could possibly just use libescret as an alternate
backend to using the .pgpass file.
I'm envisioning something like an environment variable PGPASSBACKEND where
the values are something like:
auto - (default) try libsecret if available, fall back to current behavior
if libsecret is unavailable or a suitable secret isn't found
auto-save - like auto, but automatically save passwords in libsecret if
it's unavailable
libsecret - only use libscret, fail if unavailable, fail if password not
found
pgpass - current behavior.
(Discussion needed, just brainstorming...)
Clearly there'd have to be some thought around interaction w/ things like
the -p -w and -W switches, other environment variables and default
behaviors for things like saving secrets in libsecret or not, but I thought
I'd start the discussion.
Regards,
-Alan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-11-01 00:52:07 | Re: Inefficient query plan for SELECT ... EXCEPT ... |
Previous Message | David Rowley | 2023-10-31 22:57:03 | Re: Inefficient query plan for SELECT ... EXCEPT ... |