I assume this is not a TODO.
---
Magnus Hagander wrote:
> >>> The default on *all* windows versions since NT 4.0 (which is when the
> >>> directory we use was added) will put this file in a protected directory.
> >>> The onl
Magnus Hagander wrote:
> Dave Page wrote:
>> Magnus Hagander wrote:
>>
>>> Just to make things clear, this wouldn't be about another auth method.
>>> Windows has an API to store arbitrary passwords in a "secure way". At
>>> least it does in XP+, not sure if it was in 2000.
>> Would it really solve
Dave Page wrote:
> Magnus Hagander wrote:
>
>> Just to make things clear, this wouldn't be about another auth method.
>> Windows has an API to store arbitrary passwords in a "secure way". At
>> least it does in XP+, not sure if it was in 2000.
>
> Would it really solve Tony's problem though? I'm
Magnus Hagander wrote:
> Just to make things clear, this wouldn't be about another auth method.
> Windows has an API to store arbitrary passwords in a "secure way". At
> least it does in XP+, not sure if it was in 2000.
Would it really solve Tony's problem though? I'm not familiar with the
API yo
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tony Caduto wrote:
>>> What about having a wallet type system where the user can create a pass
>>> phrase to protect a generated key that would get
>>> loaded once per session. That is how KDE allows users to store passwords.
>
>> I
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tony Caduto wrote:
>> What about having a wallet type system where the user can create a pass
>> phrase to protect a generated key that would get
>> loaded once per session. That is how KDE allows users to store passwords.
> If we wanted to do that, w
Tony Caduto wrote:
> Magnus Hagander wrote:
>> Are we sure we want to do this? (Sorry, didn't notice this thread last
>> time)
>>
>> The default on *all* windows versions since NT 4.0 (which is when the
>> directory we use was added) will put this file in a protected directory.
>>
> Is there tru
Magnus Hagander wrote:
Are we sure we want to do this? (Sorry, didn't notice this thread last
time)
The default on *all* windows versions since NT 4.0 (which is when the
directory we use was added) will put this file in a protected directory.
Is there truly such a thing on a windows PC? All
Tom Lane wrote:
> "Michael Schmidt" <[EMAIL PROTECTED]> writes:
> > ... Regarding how I concluded
> > that PGPASSFILE was deprecated for pg_dump, I offer the following.
>
> > 1. The documentation for pg_dump in the manual (Section VI) includes a
> > section labeled "Environment". This lists PG
>>> The default on *all* windows versions since NT 4.0 (which is when the
>>> directory we use was added) will put this file in a protected directory.
>>> The only case when it's not protected by default is if you're usnig FAT
>>> filesystem, in which case there is nothing you can do about it anywa
Bruce Momjian wrote:
Magnus Hagander wrote:
Are we sure we want to do this? (Sorry, didn't notice this thread last
time)
The default on *all* windows versions since NT 4.0 (which is when the
directory we use was added) will put this file in a protected directory.
The only case when it's not pro
Magnus Hagander wrote:
> Are we sure we want to do this? (Sorry, didn't notice this thread last
> time)
>
> The default on *all* windows versions since NT 4.0 (which is when the
> directory we use was added) will put this file in a protected directory.
> The only case when it's not protected by de
Are we sure we want to do this? (Sorry, didn't notice this thread last
time)
The default on *all* windows versions since NT 4.0 (which is when the
directory we use was added) will put this file in a protected directory.
The only case when it's not protected by default is if you're usnig FAT
filesy
Added to TODO for Win32:
o Check .pgpass file permissions
---
Shane Ambler wrote:
> Michael Schmidt wrote:
> > Fellow PostgreSQL fans,
>
> > 1. I don't see that this would pose a major security risk. In
> > fac
"Michael Schmidt" <[EMAIL PROTECTED]> writes:
> ... Regarding how I concluded
> that PGPASSFILE was deprecated for pg_dump, I offer the following.
> 1. The documentation for pg_dump in the manual (Section VI) includes a
> section labeled "Environment". This lists PGDATABASE, PGHOST, PGPORT,
>
Mr. Lane and Mr. Momjian,
Well, I asked and I got an answer. So be it. Regarding how I concluded that
PGPASSFILE was deprecated for pg_dump, I offer the following.
1. The documentation for pg_dump in the manual (Section VI) includes a section
labeled "Environment". This lists PGDATABASE, PGH
Michael Schmidt wrote:
Fellow PostgreSQL fans,
1. I don't see that this would pose a major security risk. In
> fact, in applications where the user enters the password for each
> session, the password need never be saved to disk, which seems a
> definite security advantage. Some folks have
Tom Lane wrote:
> "Michael Schmidt" <[EMAIL PROTECTED]> writes:
> > Also, it appears
> > from the documentation that the PGPASSFILE environmental variable has
> > been deprecated for pg_dump and pg_restore.
>
> Eh? Certainly not ... where did you get that idea?
I assumed he meant the PASSWORD en
"Michael Schmidt" <[EMAIL PROTECTED]> writes:
> Also, it appears
> from the documentation that the PGPASSFILE environmental variable has
> been deprecated for pg_dump and pg_restore.
Eh? Certainly not ... where did you get that idea?
> I would like to ask that we return to outputting the Passwor
Michael Schmidt wrote:
> Fellow PostgreSQL fans, Last year there was a pretty lengthy discussion
> (Tom Lane offered a lot of insights) on this list about deprecating
> the PGPASSWORD environmental variable. I understand the security issues
> here very well. However, up through version 8.1, it ha
Fellow PostgreSQL fans,
Last year there was a pretty lengthy discussion (Tom Lane offered a lot of
insights) on this list about deprecating the PGPASSWORD environmental variable.
I understand the security issues here very well. However, up through version
8.1, it has been easy to use pg_dump a
21 matches
Mail list logo
