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:
> "Matthew T. O'Connor" writes:
> > Tom Lane wrote:
> >> Does Windows even have a concept of home directory? What would be a
> >> reasonable equivalent to ~/.postgresql/ ?
>
> > The versions of windows that the port supports (NT4, 2000, 2003, XP) do
> > have home directories.
>
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
Tom Lane wrote:
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)
{
-- O
"Matthew T. O'Connor" writes:
> Tom Lane wrote:
>> Does Windows even have a concept of home directory? What would be a
>> reasonable equivalent to ~/.postgresql/ ?
> The versions of windows that the port supports (NT4, 2000, 2003, XP) do
> have home directories.
OK ... are you supposed to find
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
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 of home dire
Yeah I already tried removing the ifdef's...oh BOY was it not happy :'(
Tom Lane wrote:
"T.J." <[EMAIL PROTECTED]> writes:
Which leads me to my next question; that function client_cert_cb, does
it ever get executed on windows? :)
Um. Looks like someone ifdef'd it out :-(. In fact, if yo
"T.J." <[EMAIL PROTECTED]> writes:
> Which leads me to my next question; that function client_cert_cb, does
> it ever get executed on windows? :)
Um. Looks like someone ifdef'd it out :-(. In fact, if you look
through fe-secure.c, you'll see that just about all the SSL code is
ifdef'd out on Wi
After some more screwing around, I'm not entirely certain windows is
even trying to open my certs. After repeatedly trying to connect it
seemed like I was getting an equal amount of the sslv3 and SSL SYSCALL
errors, whether or not the certs were (where I thought?) windows was
looking for them..
"T.J." <[EMAIL PROTECTED]> writes:
> Not to my knowledge. By the way, for future reference on windows it
> looks for the cert/key in the linux equivalent of
> `pwd`/.postgresql/postgresql.crt/key, instead of
> $HOME/.postgresql/postgresql.crt/key.
Actually, it asks getpwuid() for the user's hom
Not to my knowledge. By the way, for future reference on windows it
looks for the cert/key in the linux equivalent of
`pwd`/.postgresql/postgresql.crt/key, instead of
$HOME/.postgresql/postgresql.crt/key. Maybe you already knew this but I
had to do testing to figure it out so hopefully that bit
Did we ever find the solution to this, or did anyone find the cause?
---
T.J. wrote:
> Having some problems (still, hehe) getting SSL to work properly on
> windows in the new 8.0 (all vers) environment (where cert/key is re
Having some problems (still, hehe) getting SSL to work properly on
windows in the new 8.0 (all vers) environment (where cert/key is required).
On the client side when not finding the certificate/key psql would
report the SSL error sslv3 alert handshale failure. After I figured out
where psql wa
28 matches
Mail list logo
