Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Martin Pitt wrote: > Peter Eisentraut [2009-04-10 14:56 +0300]: >> I assume the server has the snakeoil certificate installed? In that case, >> it >> is correct that the client refuses to proceed, although the exact manner of >> breaking could perhaps be improved. > > Is it really refusing self-signed certificates? That would be strange. It treats self-signed certificates the same way it treats anything else. In the case of a self-signed one, the certificate and the CA certificate are the same. Thus, you have to copy the server certificate to the client. (This is, of course, not a security issue in itself, because you don't copy the *key* over. Just as a FYI to those who thought it would be :-P) > I had thought it checks whether the user has the server signing > certificate of the server installed on his client home directory > (which, BTW, seems like a strange place to default to, and thus keep > it). That has just been brought up from previous versions. Perhaps we need to have a system wide root store as well - then you could point that to whatever snakeoil store you have, and it would find the cert correctly? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4756: Installationproblems
The following bug has been logged online: Bug reference: 4756 Logged by: Email address: mattierm...@gmail.com PostgreSQL version: 8.3 Operating system: Windows xp Description:Installationproblems Details: Failour during installationprocess Data directory error The PostgreSQL data directory must be on an NTFS formated voulme. If you wish to install the data directory on another type of partition (which is not recommended, and is unsupported) you must initialize the database cluster manually by running intidb.exe This is the Message. I need PostgreSQL and I am not able to install it properly. I don`t have a useraccount or anything. Can you reccomend another way of installing it or another file, because i downloaded a zip-file and not an exe file? Thanks for you help -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Martin Pitt wrote: -- Start of PGP signed section. > Peter Eisentraut [2009-04-10 14:56 +0300]: > > I assume the server has the snakeoil certificate installed? > > It is a self-signed certificate indeed (Debian's ssl-cert package). > > > In that case, it is correct that the client refuses to proceed, > > although the exact manner of breaking could perhaps be improved. > > That may be true for 8.4, and I'm could stop configuring the snakeoil > certificate by default. That would make configuring a server for a > real SSL certificate harder than it needs to be, though. > > However, we can't afford to break existing installations. If a user > has 8.4 installed locally, he'll use libpq from 8.4, and suddenly he > could not connect to a remote SSL 8.3 cluster any more. So the check > needs at least be turned into a warning for connecting to a pre-8.4 > server. > > Also, the error message needs to be much clearer. Right now it just > tells you that it couldn't find a per-user root.crt and fails. So as > an user, I wonder: What is that file? I don't have one, where should I > get it from? And why does each user need to have its own? > > html/libpq-ssl.html describes it fairly well: > > "When the sslverify parameter is set to cn or cert, libpq will > verify that the server certificate is trustworthy by checking the > certificate chain up to a CA. For this to work, place the > certificate of a trusted CA in the file ~/.postgresql/root.crt in > the user's home directory. libpq will then verify that the server's > certificate is signed by one of the trusted certificate > authorities." > > Nowhere does it say that the connection will fail immediately if you > do not have a root.crt. man psql(1) does not have any word about it, > like how to set the sslverify argument. I noticed you didn't quote the next sentence: The SSL connection will fail if the server does not present a trusted certificate. Which clearly explains _a_ failure, but doesn't link it well to the behavior. I agree the wording needs improvement so I have update the doc paragraph to mention "requires" at the beginning": When the sslverify parameter is set to cn or cert, libpq requires a trustworthy server certificate by checking the certificate chain up to a CA. To allow verification, place the certificate of a trusted CA in the file ~/.postgresql/root.crt in the user's home directory. (On Microsoft Windows the file is named %APPDATA%\postgresql\root.crt.) libpq will then verify that the server's certificate is signed by one of the trusted certificate authorities. The SSL connection will fail if the server does not present a trusted certificate. I will now look at improving the libpq error message. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4756: Installationproblems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 mattierm...@gmail.com wrote: > The following bug has been logged online: > > Bug reference: 4756 > Logged by: > Email address: mattierm...@gmail.com > PostgreSQL version: 8.3 > Operating system: Windows xp > Description:Installationproblems > Details: > > Failour during installationprocess > > Data directory error > > The PostgreSQL data directory must be on an NTFS formated voulme. pls see if this link is helpful :- http://wiki.postgresql.org/wiki/Running_&_Installing_PostgreSQL_On_Native_Windows -- regards,tushar http://webeatoracle.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFJ4LLkfQNodY2PIRoRAg+IAKCxzzxYCgdu7plOVDOO1TZYBcLBmgCfd0tF /XpXX4a4I3sDmGYnQ4xZj+Q= =klE/ -END PGP SIGNATURE- -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Peter Eisentraut wrote:
> On Friday 10 April 2009 08:39:33 Martin Pitt wrote:
> > Tom Lane [2009-04-10 1:15 -0400]:
> > > Martin Pitt writesyuqhom#3:
> > > > The test suite detected one regression in libpq, though: Setting
> > > > $PGHOST now complains about a missing root.crt, although this is only
> > > > relevant on the server side (or did I misunderstood this?)
> > >
> > > No, that's a progression: the client wants to validate the server's
> > > cert, too.
> >
> > Indeed it is nice to see this feature (great to prevent spoofing), but
> > if I don't have a ~/.postgresql/root.crt at all, it shouldn't
> > certainly break completely? (which it does now).
>
> I assume the server has the snakeoil certificate installed? In that case, it
> is correct that the client refuses to proceed, although the exact manner of
> breaking could perhaps be improved.
I have developed a patch to more clearly explain the problem with a
missing client root.crt file:
$ PGSSLVERIFY=cn sql -h localhost test
psql: root certificate file "/u/postgres/.postgresql/root.crt" does not
exist
Either supply the file or set sslverify to "none" to disable server
certificate verification.
$ PGSSLVERIFY=none sql -h localhost test
psql (8.4beta1)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
I had to add a second error message line; I didn't see us doing a
second line anywhere else in libpq, but it seemed to be the only
solution. Should I use three lines?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.122
diff -c -c -r1.122 fe-secure.c
*** src/interfaces/libpq/fe-secure.c 31 Mar 2009 01:41:27 - 1.122
--- src/interfaces/libpq/fe-secure.c 11 Apr 2009 19:32:47 -
***
*** 1067,1073
if (strcmp(conn->sslverify, "none") != 0)
{
printfPQExpBuffer(&conn->errorMessage,
! libpq_gettext("root certificate file \"%s\" does not exist"), fnbuf);
return -1;
}
}
--- 1067,1074
if (strcmp(conn->sslverify, "none") != 0)
{
printfPQExpBuffer(&conn->errorMessage,
! libpq_gettext("root certificate file \"%s\" does not exist\n"
! "Either supply the file or set sslverify to \"none\" to disable server certificate verification.\n"), fnbuf);
return -1;
}
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4757: to_timestamp returns incorrect result
The following bug has been logged online: Bug reference: 4757 Logged by: Timofey.Asyrkin Email address: timoha-...@ngs.ru PostgreSQL version: 8.3 Operating system: Ubuntu 8.10 Description:to_timestamp returns incorrect result Details: Hello everybody, It looks like there is a bug in to_timestamp function: I'm living in Italy and I have a timezone GMT+2 (summer). These two queries return the same result: 1)select TO_TIMESTAMP( '25/03/2001 02:00:00', 'dd/mm/ hh24:mi:ss' ); 2)select TO_TIMESTAMP( '25/03/2001 03:00:00', 'dd/mm/ hh24:mi:ss' ); Result: 2001-03-25 03:00:00+02 Having executed with different date, but the same time didn't gave such result, moreover, changing the timezone gives correct result. Kind regards, Timofey -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4757: to_timestamp returns incorrect result
"Timofey.Asyrkin" writes: > I'm living in Italy and I have a timezone GMT+2 (summer). > These two queries return the same result: > 1)select TO_TIMESTAMP( '25/03/2001 02:00:00', 'dd/mm/ hh24:mi:ss' ); > 2)select TO_TIMESTAMP( '25/03/2001 03:00:00', 'dd/mm/ hh24:mi:ss' ); > Result: 2001-03-25 03:00:00+02 If that day is a DST transition day, those results are not wrong. The two times are the same, and it happens that we preferentially show that time in DST. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Martin Pitt wrote: > I do see the benefit of failing to connect to an SSL-enabled server > *if* I have a root.crt which doesn't match. But why fail if I don't > have one? I have digested this thread, and have done two things: improved the documentation and posted a patch to make the error message clearer. In terms of your suggestion about root.crt, I think sslverify != none should error if it can't verify the server's certificate, whether the root.crt file is there or not. If you are asking for sslverify, it should do that or error, not ignore the setting if there is no root.crt file. The only other approach would be to add an sslverify value of 'try' that tries only if root.crt exists. A separate issue is if sslverify should default to 'cn'. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Bruce Momjian writes: > In terms of your suggestion about root.crt, I think sslverify != none > should error if it can't verify the server's certificate, whether the > root.crt file is there or not. If you are asking for sslverify, it > should do that or error, not ignore the setting if there is no root.crt > file. Fair enough. > The only other approach would be to add an sslverify value of > 'try' that tries only if root.crt exists. +1 for adding a "try" setting (though I'm not sure if I like that name or not). I don't think that we actually have any choice in the matter. By the end of beta, we *will* have such a setting; the only question in my mind is whether it will be default or not. That depends on exactly how nasty the villagers become ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Bruce Momjian wrote: > Martin Pitt wrote: >> I do see the benefit of failing to connect to an SSL-enabled server >> *if* I have a root.crt which doesn't match. But why fail if I don't >> have one? > > I have digested this thread, and have done two things: improved the > documentation and posted a patch to make the error message clearer. > > In terms of your suggestion about root.crt, I think sslverify != none > should error if it can't verify the server's certificate, whether the > root.crt file is there or not. If you are asking for sslverify, it > should do that or error, not ignore the setting if there is no root.crt > file. The only other approach would be to add an sslverify value of > 'try' that tries only if root.crt exists. Doesn't "try" make the whole check pretty pointless, and you can just set it to "none" then? The point is, you need to *know*. "try" makes no sense. If we want to be sure it never fails to connect, we disable security by default - setting sslverify to "none". For those who care about security, we document clearly how to enable it, and make it very clear that we ship with this part of the security system disabled by default. (shipping in this way, btw, will be considered a bug by anybody in the security community. But that's a different community than ours, and at least there's a builtin way to fix it) Inventing a switch that makes it more or less impossible to figure out if you are going to be secure or not makes no sense. When dealing with security, maybe is the same as no, and you have to *know*. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Bruce Momjian writes: >> In terms of your suggestion about root.crt, I think sslverify != none >> should error if it can't verify the server's certificate, whether the >> root.crt file is there or not. If you are asking for sslverify, it >> should do that or error, not ignore the setting if there is no root.crt >> file. > > Fair enough. > >> The only other approach would be to add an sslverify value of >> 'try' that tries only if root.crt exists. > > +1 for adding a "try" setting (though I'm not sure if I like that name > or not). I don't think that we actually have any choice in the matter. > By the end of beta, we *will* have such a setting; the only question > in my mind is whether it will be default or not. That depends on > exactly how nasty the villagers become ... The option is there already, it's called "none". That's what people are asking for - they don't care who they are connecting to, just that the traffic is encrypted (be it legitimate or hacked traffic, at least it's encrypted). It's just a matter of if it's default or not. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander writes: > Bruce Momjian wrote: >> The only other approach would be to add an sslverify value of >> 'try' that tries only if root.crt exists. > Doesn't "try" make the whole check pretty pointless, and you can just > set it to "none" then? Not at all. What it means is that you control whether to make the check by putting the file there (or not). Which you have to do anyway, if you want to make the check. All that the current definition of the setting is accomplishing is forcing people to fool with their environment variables, which is a pain in the neck to varying degrees depending on platform. > Inventing a switch that makes it more or less impossible to figure out > if you are going to be secure or not makes no sense. When dealing with > security, maybe is the same as no, and you have to *know*. I am of the opinion that sslverify should have these values: off = never verify on = verify if root.crt is present (default behavior) force = verify, failing if root.crt is not present and the people who actually want to be "sure they're secure" can set the "force" value in their environment. This is not measurably different in effect from the fact that we have sslmode defaulting to "prefer" rather than "require". If you want to be "sure you're secure" you need the latter setting, but I don't believe there is even remotely a consensus for making that the default. BTW, what in the world prompted us to use "cn" as an allowed value for sslverify? It looks for all the world like a typo for "on". regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander writes: > The option is there already, it's called "none". That's what people are > asking for - No, that is NOT what people are asking for. Please stop attacking a straw man. What people are asking for is that by default, whether to make the check or not should depend on whether the necessary configuration file has been provided. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > Magnus Hagander writes: >> Bruce Momjian wrote: >>> The only other approach would be to add an sslverify value of >>> 'try' that tries only if root.crt exists. > >> Doesn't "try" make the whole check pretty pointless, and you can just >> set it to "none" then? > > Not at all. What it means is that you control whether to make the check > by putting the file there (or not). Which you have to do anyway, if you > want to make the check. Which means that every time I connect, I need to first to make sure that the file is there, and that the proper user has permissions to read the file, *before* I connect. > All that the current definition of the setting > is accomplishing is forcing people to fool with their environment variables, > which is a pain in the neck to varying degrees depending on platform. That, or un-breaking their environment. >> Inventing a switch that makes it more or less impossible to figure out >> if you are going to be secure or not makes no sense. When dealing with >> security, maybe is the same as no, and you have to *know*. > > I am of the opinion that sslverify should have these values: > > off = never verify > on = verify if root.crt is present (default behavior) > force = verify, failing if root.crt is not present > > and the people who actually want to be "sure they're secure" can set the > "force" value in their environment. Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and something like "maybe" or "external" or "file". I'd find it very bad if you can say "sslverify=on" and then *not* end up getting it because of some external factor. That needs to be clear in the naming of the value if we go down that path. Plus you somehow need to overload it with the cn vs certificate only part. The ability to not do full hostname verification has been specifically asked for. > This is not measurably different in effect from the fact that we have > sslmode defaulting to "prefer" rather than "require". If you want to be > "sure you're secure" you need the latter setting, but I don't believe > there is even remotely a consensus for making that the default. That's a whole mess in itself, really. Originally, we had SSL on or off. If you set it to on, it required SSL. If you set it to off, it wouldn't use SSL. "sslmode=prefer" honestly makes no sense - if I don't care if it ends up encrypted or not (which it means), then why not just run with SSL off and not have to deal with the overhead? > BTW, what in the world prompted us to use "cn" as an allowed value for > sslverify? It looks for all the world like a typo for "on". Eh, what would you call it? It enables verification of the cn field in the certificate. Another option I considered was "full", but someone said that was bad - can't recall if that was on-list or off ATM. //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander writes: > Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and > something like "maybe" or "external" or "file". I'd find it very bad if > you can say "sslverify=on" and then *not* end up getting it because of > some external factor. That needs to be clear in the naming of the value > if we go down that path. I guess you didn't think through the implications of the sslmode comment, but: this is all merest self-delusion. If a hostile server is trying to fool you, all he needs to do is configure his pg_hba.conf to accept your connection in non-SSL mode, and your super duper guaranteed-to-work ssl verification doesn't do a thing. So unless you think you can persuade us to change the default sslmode to "require", you're wasting your time making the above argument. >> BTW, what in the world prompted us to use "cn" as an allowed value for >> sslverify? It looks for all the world like a typo for "on". > Eh, what would you call it? It enables verification of the cn field in > the certificate. Another option I considered was "full", but someone > said that was bad - can't recall if that was on-list or off ATM. I would call it "on", and put the hostname behavior control somewhere else. Overloading a security-sensitive parameter's meaning isn't a particularly safe design, eh? Especially with a value that people can't even read correctly if their eyes are a bit bleary. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander wrote: Bruce Momjian wrote: Martin Pitt wrote: I do see the benefit of failing to connect to an SSL-enabled server *if* I have a root.crt which doesn't match. But why fail if I don't have one? I have digested this thread, and have done two things: improved the documentation and posted a patch to make the error message clearer. In terms of your suggestion about root.crt, I think sslverify != none should error if it can't verify the server's certificate, whether the root.crt file is there or not. If you are asking for sslverify, it should do that or error, not ignore the setting if there is no root.crt file. The only other approach would be to add an sslverify value of 'try' that tries only if root.crt exists. Doesn't "try" make the whole check pretty pointless, and you can just set it to "none" then? Yes the snapshot psqlodbc driver already set sslverify to none and can't change it though it may be differnet from the expected behavior. It was not so easy to implement because sslverify parameter is illegal for <= 8.3 libpq and the psqlodbc driver doesn't rely on environment variables at all. regards, Hiroshi Inoue -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Tom Lane wrote: > I am of the opinion that sslverify should have these values: > > off = never verify > on = verify if root.crt is present (default behavior) > force = verify, failing if root.crt is not present > > and the people who actually want to be "sure they're secure" can set the > "force" value in their environment. > > This is not measurably different in effect from the fact that we have > sslmode defaulting to "prefer" rather than "require". If you want to be > "sure you're secure" you need the latter setting, but I don't believe > there is even remotely a consensus for making that the default. > > BTW, what in the world prompted us to use "cn" as an allowed value for > sslverify? It looks for all the world like a typo for "on". l1 and 0O where taken? ;-) It would be nice if 'sslverify' mimicked 'sslmode', which has these values: disable allow prefer require I don't see how we could use 'allow', but 'disable', 'prefer', and 'require' seem to work for sslverify, like sslmode. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Bruce Momjian wrote: > It would be nice if 'sslverify' mimicked 'sslmode', which has these > values: > > disable > allow > prefer > require > > I don't see how we could use 'allow', but 'disable', 'prefer', and > 'require' seem to work for sslverify, like sslmode. OK, crazy idea --- we use the three-value mode for sslverify listed above, but we have it default to the value of sslmode. So, when sslmode is prefer (the default), sslverify is 'prefer'. When sslmode is require, so is sslverify, and of course disable sets them both to disable. This gives us good defaults (prefer), but auto-locks down the system when sslmode is 'require'. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
