Andreas Pflug wrote:
Oliver Jowett wrote:
postgresbugs wrote:
The functionality provided by PGPASSWORD should not be removed unless
there is a functionality other than .pgpass, which is fine for some
uses and not for others, that will provide similar functionality.
That could be psql and pg_dump
Oliver Jowett wrote:
postgresbugs wrote:
The functionality provided by PGPASSWORD should not be removed unless
there is a functionality other than .pgpass, which is fine for some
uses and not for others, that will provide similar functionality. That
could be psql and pg_dump and the like accepti
Bruce Momjian wrote:
postgresbugs wrote:
Oliver Jowett wrote:
postgresbugs wrote:
The functionality provided by PGPASSWORD should not be removed unless
there is a functionality other than .pgpass, which is fine for some
uses and not for oth
postgresbugs wrote:
The functionality provided by PGPASSWORD should not be removed
unless there is a functionality other than .pgpass, which is fine for
some uses and not for others, that will provide similar functionality.
That could be psql and pg_dump and the like accepting a password on the
Oliver Jowett wrote:
postgresbugs wrote:
Tom Lane wrote:
The point here is that if
PGPASSWORD is passed down to psql as an environmental variable, it is
visible as part of psql's environment for the entire run of psql.
Whatever the calling script does later doesn't remove that window of
vulnerabi
postgresbugs wrote:
Tom Lane wrote:
Agreed, which is why we invented .pgpass. But that argument scales up
to beyond one invocation of this hypothetical script, does it not?
regards, tom lane
I guarantee you that his process which includes binaries and scripts is
not hypothetical.
postgresbugs wrote:
Tom Lane wrote:
The point here is that if
PGPASSWORD is passed down to psql as an environmental variable, it is
visible as part of psql's environment for the entire run of psql.
Whatever the calling script does later doesn't remove that window of
vulnerability.
[...]
And, yes I
Tom Lane wrote:
Agreed, which is why we invented .pgpass. But that argument scales up
to beyond one invocation of this hypothetical script, does it not?
regards, tom lane
I guarantee you that his process which includes binaries and scripts is
not hypothetical.
Regards,
John Griffiths
Tom Lane wrote:
postgresbugs <[EMAIL PROTECTED]> writes:
Unless the utilities like psql and pg_dump are changed to accept a
password as a command line option, I don't think PGPASSWORD should go
away. It is too useful for those that know how to properly use and
destroy environm
Tom Lane wrote:
- the user might not want to store their password in .pgpass
Without a concrete argument why they should not, this is a straw man.
I think this is the core of our disagreement.
Storing passwords on the client's disk is surely less secure than not
storing them on disk. That's my per
Oliver Jowett <[EMAIL PROTECTED]> writes:
> My main objections to using .pgpass are:
> - the script/application itself has no business meddling with .pgpass
It isn't. The password sits in .pgpass and is never touched by the
script. Really the script doesn't know it is there. (For that matter,
postgresbugs <[EMAIL PROTECTED]> writes:
> Unless the utilities like psql and pg_dump are changed to accept a
> password as a command line option, I don't think PGPASSWORD should go
> away. It is too useful for those that know how to properly use and
> destroy environmental variables.
... which
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
If you're a shell script calling psql / pg_dump / etc, how do you do this?
That doesn't strike me as a compelling case for inventing "--password-fd".
Such a shell script is going to have a hard time passing a password
securely anyway (you w
Oliver Jowett wrote:
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Assuming that you can't tweak .pgpass (for example, you're just
propagating a password you interactively got from the user), what's
the recommended way to provide the password?
In the connection string given to PQconn
Oliver Jowett <[EMAIL PROTECTED]> writes:
> If you're a shell script calling psql / pg_dump / etc, how do you do this?
That doesn't strike me as a compelling case for inventing "--password-fd".
Such a shell script is going to have a hard time passing a password
securely anyway (you weren't plannin
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Assuming that you can't tweak .pgpass (for example, you're just
propagating a password you interactively got from the user), what's the
recommended way to provide the password?
In the connection string given to PQconnectdb (or equivalent)
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Assuming that you can't tweak .pgpass (for example, you're just
> propagating a password you interactively got from the user), what's the
> recommended way to provide the password?
In the connection string given to PQconnectdb (or equivalent).
Tom Lane wrote:
postgresbugs <[EMAIL PROTECTED]> writes:
I would like to recommend removing the deprecation flag from PGPASSWORD.
Do you understand why it's deprecated? It's because on some operating
systems, everyone on the machine can see your environment variable
values (if they know how to l
postgresbugs <[EMAIL PROTECTED]> writes:
> I would like to recommend removing the deprecation flag from PGPASSWORD.
Do you understand why it's deprecated? It's because on some operating
systems, everyone on the machine can see your environment variable
values (if they know how to look). We cann
I know this is not a bug, but I didn't see a list that I thought this
would fit into.
I saw in the documentation that PGPASSWORD is deprecated in favor of of
the .pgpass file for security reasons.
I would like to recommend removing the deprecation flag from PGPASSWORD.
It is very useful in dyn
20 matches
Mail list logo
