Tom Lane wrote:
Basically my point here is that the default "prefer" SSL mode
effectively becomes "require" if the server has a root.crt.
Ok, in the scenario where validation is important, clients should be
using "require" anyway, so it's not an issue so long as libpq doesn't
try to fall back to
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not sure if this is desirable. Should libpq try to fall back to a
>> non-SSL-encrypted connection, instead?
> Only if the server certificate validates, otherwise an active attacker
> could intercept the SSL connection to force li
Tom Lane wrote:
BTW, as of CVS tip, if the server has a root.crt file and the client
does not have any certificate files, the default behavior is that
connections fail:
$ psql -h localhost regression
psql: could not open certificate file "/home/tgl/.postgresql/postgresql.crt":
No such file or dire
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I think it's only broken when you fiddle with certificates.
Yeah, the commented-out stuff had to do with certificates, and would not
be executed unless the server demands a client certificate (which only
happens if the server has a root.crt file).
B
> > > win32 hackers, anyone know why it's like this?
> >
> > Looking through the code, it seems that it's because
> someone thought
> > that breaking SSL would be easier than replacing the pqGetpwuid()
> > calls that are used to find out the user's home directory.
> >
>
> I think what happene
Tom Lane wrote:
> I wrote:
> > win32 hackers, anyone know why it's like this?
>
> Looking through the code, it seems that it's because someone thought
> that breaking SSL would be easier than replacing the pqGetpwuid() calls
> that are used to find out the user's home directory.
>
I think what h
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Tom also wrote:
>> Now that I look at it, there are several places that are depending on
>> getenv("HOME") or getenv("USERPROFILE") (on Windows) as the meaning of
>> "home directory". In particular ~/.pgpass is sought there, and psql
>> also uses get
> >OK ... are you supposed to find it out by looking at the environment
> >vars, or is there another API defined?
> >
> >I am planning to consolidate the platform dependency into a function
> >defined like
> >
> > static bool pqGetHomeDirectory(char *buf, int bufsize)
> > {
> >
Matthew T. O'Connor wrote:
Tom Lane wrote:
If someone can whip up and test a WIN32 version of this, I'll take care
of the rest.
I can't do the coding, but I took a quick look at msdn and I think
this is relevant:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platfo
Tom Lane wrote:
I wrote:
win32 hackers, anyone know why it's like this?
Looking through the code, it seems that it's because someone thought
that breaking SSL would be easier than replacing the pqGetpwuid() calls
that are used to find out the user's home directory.
Does Windows even have a concept
Tom Lane wrote:
John R Pierce <[EMAIL PROTECTED]> writes:
more fun. I just checked the environment of the postmaster service on a
win2000 Pro system (using www.sysinternals.com's excellent Process Explorer
tool, btw). HOME is not set. USERPROFILE is set to "C:\Documents and
Settings\postg
win2000 Pro system (using www.sysinternals.com's excellent Process
Explorer tool, btw). HOME is not set. USERPROFILE is set to
"C:\Documents and Settings\postgres"...
For services that are running as 'NT AUTHORITY\SYSTEM', the profile is
"C:\Documents and Settings\Default User" (and the USER
Actually, the server doesn't depend on home directories in any way shape
or form. The places that we are concerned about are on the client side,
either in libpq or in psql. So what we have to think about is the
environment that libpq might see.
libpq could be called from a service, such as ineti
John R Pierce <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Seems like we should be consistent about this --- either we trust $HOME
>> or we don't.
> more fun. I just checked the environment of the postmaster service on a
> win2000 Pro system (using www.sysinternals.com's excellent Process Ex
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I think CSIDL_APPDDATA is probably the way to go, but one of the heavy
Windows hitters will know better than I do.
Now that I look at it, there are several places that are depending on
getenv("HOME") or getenv("USERPROFILE") (on Windows)
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think CSIDL_APPDDATA is probably the way to go, but one of the heavy
> Windows hitters will know better than I do.
Now that I look at it, there are several places that are depending on
getenv("HOME") or getenv("USERPROFILE") (on Windows) as the meani
16 matches
Mail list logo
