[BUGS] BUG #5471: Postgres License Url is Misspelled
The following bug has been logged online: Bug reference: 5471 Logged by: Christopher Hotchkiss Email address: christopher.hotchk...@gmail.com PostgreSQL version: 8.4 Operating system: Win32 Description:Postgres License Url is Misspelled Details: On the postgresql.org, about page, there is a link to the license page (http://www.postgresql.org/about/licence). The link name is correct but the url is misspelled. -- 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 #5471: Postgres License Url is Misspelled
On Tue, May 25, 2010 at 10:53 AM, Christopher Hotchkiss wrote: > > The following bug has been logged online: > > Bug reference: 5471 > Logged by: Christopher Hotchkiss > Email address: christopher.hotchk...@gmail.com > PostgreSQL version: 8.4 > Operating system: Win32 > Description: Postgres License Url is Misspelled > Details: > > On the postgresql.org, about page, there is a link to the license page > (http://www.postgresql.org/about/licence). The link name is correct but the > url is misspelled. Not on this side of the pond. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Craig Ringer writes: > Bug 5245 is not the same issue. They're talking about the server not > sending the full certificate chain for the cert that identifies the > server (server.crt). It's nothing to do with client certificates. > Without the full chain, the client can't verify the server unless it > happens to already have the intermediate certs between the server's cert > and the trusted root that signed it installed locally. I haven't > encountered #5245 myself, but will test it shortly to verify. It'd > certainly count as a significant bug, as it would make it impossible to > use indirect trust to verify a server (as is the case when a corporate > CA signed by a "big name" CA is in use). BTW, does anyone know exactly how to fix that? I'm looking at a related request internal to Red Hat right now. 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] BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On Tue, May 25, 2010 at 17:48, Tom Lane wrote: > Craig Ringer writes: >> Bug 5245 is not the same issue. They're talking about the server not >> sending the full certificate chain for the cert that identifies the >> server (server.crt). It's nothing to do with client certificates. >> Without the full chain, the client can't verify the server unless it >> happens to already have the intermediate certs between the server's cert >> and the trusted root that signed it installed locally. I haven't >> encountered #5245 myself, but will test it shortly to verify. It'd >> certainly count as a significant bug, as it would make it impossible to >> use indirect trust to verify a server (as is the case when a corporate >> CA signed by a "big name" CA is in use). > > BTW, does anyone know exactly how to fix that? I'm looking at a related > request internal to Red Hat right now. I have it on my TODO to figure it out, but from what I can tell it's very close to being undocumented, like most of OpenSSL. So it will need research of how others do it, etc. Unless someone can figure out how to do it, and I can stick to juts reviewing it, there is pretty much zero chance that I can get that done for 9.0 (even if we call it a bugfix) due to lack of time over the next couple of weeks. (and yes, I intend to get back in on the rest of this thread as well once I've cleared my pgcon-induced backlog) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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 #5472: Postgres hard crash in ...WHERE IN (SELECT * FROM (VALUES (),...) AS t(col))
The following bug has been logged online: Bug reference: 5472 Logged by: Vlad Romascanu Email address: vromasc...@accurev.com PostgreSQL version: 8.4.3 Operating system: Windows, Linux Description:Postgres hard crash in ...WHERE IN (SELECT * FROM (VALUES (),...) AS t(col)) Details: The following reproducibly crashes Postgres 8.4.3 (segfault) inside int84eq() on both Windows and Linux, but works just fine in 8.3.4: CREATE TABLE t1 ( col1 bigint NOT NULL, col2 integer NOT NULL, CONSTRAINT t1_pkey PRIMARY KEY (col1, col2) ); INSERT INTO t1 (col1, col2) VALUES (0,1),(1,2),(2,3); SELECT col1, col2 FROM t1 WHERE col1 IN ( SELECT * FROM (VALUES (1),(2)) AS t2(col1) ) Changing the above to... SELECT col1, col2 FROM t1 WHERE col1::integer IN ( SELECT * FROM (VALUES (1),(2)) AS t2(col1) ) ...works again. -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Magnus Hagander writes: > On Tue, May 25, 2010 at 17:48, Tom Lane wrote: >> Craig Ringer writes: >>> Bug 5245 is not the same issue. >> >> BTW, does anyone know exactly how to fix that? I'm looking at a related >> request internal to Red Hat right now. > I have it on my TODO to figure it out, but from what I can tell it's > very close to being undocumented, like most of OpenSSL. I've been googling this a bit, and the theory I have at the moment is that Craig's proposed fix for #5468 will *also* fix #5245. However, I'm not too adept at using openssl so actually testing that will probably take a bit of time. Are you in a position to check it quickly? 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] BUG #5472: Postgres hard crash in ...WHERE IN (SELECT * FROM (VALUES (),...) AS t(col))
On Tue, May 25, 2010 at 10:39, Vlad Romascanu wrote: > The following reproducibly crashes Postgres 8.4.3 (segfault) inside > int84eq() on both Windows and Linux, but works just fine in 8.3.4: Hrm... Both work for me (8.4.3 and 8.4.4). -- => SELECT col1, col2 FROM t1 WHERE col1 IN ( SELECT * FROM (VALUES (1),(2)) AS (> t2(col1) ) -> ; col1 | col2 --+-- 1 |2 2 |3 => SELECT col1, col2 FROM t1 WHERE col1::integer IN ( SELECT * FROM (VALUES (> (1),(2)) AS t2(col1) ); col1 | col2 --+-- 1 |2 2 |3 -- 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 #5472: Postgres hard crash in ...WHERE IN (SELECT * FROM (VALUES (),...) AS t(col))
On Tue, May 25, 2010 at 11:26, Alex Hunsaker wrote: > On Tue, May 25, 2010 at 10:39, Vlad Romascanu wrote: > >> The following reproducibly crashes Postgres 8.4.3 (segfault) inside >> int84eq() on both Windows and Linux, but works just fine in 8.3.4: > > Hrm... Both work for me (8.4.3 and 8.4.4). Ahh it breaks on 32 bit Program received signal SIGSEGV, Segmentation fault. 0x08276adf in int84eq (fcinfo=0xbfad27cc) at int8.c:271 271 PG_RETURN_BOOL(val1 == val2); (gdb) bt #0 0x08276adf in int84eq (fcinfo=0xbfad27cc) at int8.c:271 #1 0x082ee0bb in FunctionCall2 (flinfo=0x8923578, arg1=2, arg2=1) at fmgr.c:1309 #2 0x0818c27e in execTuplesMatch (slot1=0x89228b8, slot2=0x8922878, numCols=1, matchColIdx=0x891e628, eqfunctions=0x8923578, evalContext=0x890c720) at execGrouping.c:97 #3 0x081a479b in ExecUnique (node=0x8922e08) at nodeUnique.c:88 #4 0x08190278 in ExecProcNode (node=0x8922e08) at execProcnode.c:439 #5 0x081a2a6b in ExecNestLoop (node=0x8922c78) at nodeNestloop.c:120 #6 0x081902f8 in ExecProcNode (node=0x8922c78) at execProcnode.c:404 #7 0x0818f368 in ExecutePlan (queryDesc=0x891ab98, direction=ForwardScanDirection, count=0) at execMain.c:1504 -- 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 #5472: Postgres hard crash in ...WHERE IN (SELECT * FROM (VALUES (),...) AS t(col))
"Vlad Romascanu" writes: > Description:Postgres hard crash in ...WHERE IN (SELECT > * FROM (VALUES (),...) AS t(col)) Fixed, thanks for the report! Patch is here if you need it: http://archives.postgresql.org/message-id/20100525174447.c0b00754...@cvs.postgresql.org 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] BUG #5472: Postgres hard crash in ...WHERE IN (SELECT * FROM (VALUES (),...) AS t(col))
Alex Hunsaker writes: > On Tue, May 25, 2010 at 10:39, Vlad Romascanu wrote: >> The following reproducibly crashes Postgres 8.4.3 (segfault) inside >> int84eq() on both Windows and Linux, but works just fine in 8.3.4: > Hrm... Both work for me (8.4.3 and 8.4.4). I think it wouldn't crash if you're using a build with pass-by-value int8. It might even accidentally give correct answers, depending on endianness etc. 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] BUG #5472: Postgres hard crash in ...WHERE IN (SELECT * FROM (VALUES (),...) AS t(col))
Interesting. I forgot to mention both the Linux and Windows Postgres builds
I'm reproducing this on are 32-bit (!) builds, which is probably highly
relevant. I was able to also reproduce the crash with 8.4.4-1 in addition to
8.4.3 on Windows (in both cases using the official builds from the Download
Page), haven't tried 8.4.4-1 on Linux yet (I imagine it's also reproducible
there -- again, 32-bit builds) but here's what I get with 8.4.3 on Linux:
db=# SELECT version();
version
---
PostgreSQL 8.4.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.6 20060404
(Red Hat 3.4.6-3), 32-bit
(1 row)
db=# CREATE TABLE t1 (
db(# col1 bigint NOT NULL,
db(# col2 integer NOT NULL,
db(# CONSTRAINT t1_pkey PRIMARY KEY (col1, col2)
db(# );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey" for
table "t1"
CREATE TABLE
db=# INSERT INTO t1 (col1, col2) VALUES (0,1),(1,2),(2,3);
INSERT 0 3
db=# SELECT col1, col2 FROM t1 WHERE col1 IN ( SELECT * FROM (VALUES (1),(2))
AS t2(col1) );
***crash during SELECT***
Program received signal SIGSEGV, Segmentation fault.
0x082a9c53 in int84eq (fcinfo=0xbff41850) at int8.c:268
268 int64 val1 = PG_GETARG_INT64(0);
(gdb) bt 10
#0 0x082a9c53 in int84eq (fcinfo=0xbff41850) at int8.c:268
#1 0x08333479 in FunctionCall2 (flinfo=0x96cda28, arg1=2, arg2=1) at
fmgr.c:1309
#2 0x0819408c in execTuplesMatch (slot1=0x96ccd68, slot2=0x96ccd28, numCols=1,
matchColIdx=0x96ca5d0, eqfunctions=0x96cda28, evalContext=0x96af1c8) at
execGrouping.c:97
#3 0x081b0413 in ExecUnique (node=0x96cd2b8) at nodeUnique.c:88
#4 0x08198b4c in ExecProcNode (node=0x96cd2b8) at execProcnode.c:439
#5 0x081ae201 in ExecNestLoop (node=0x96cd128) at nodeNestloop.c:120
#6 0x08198a9c in ExecProcNode (node=0x96cd128) at execProcnode.c:404
#7 0x08196765 in ExecutePlan (estate=0x96ccc98, planstate=0x96cd128,
operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection,
dest=0x96cb558) at execMain.c:1504
#8 0x08194edc in standard_ExecutorRun (queryDesc=0x96bcc10,
direction=ForwardScanDirection, count=0) at execMain.c:309
#9 0x08194e13 in ExecutorRun (queryDesc=0x96bcc10,
direction=ForwardScanDirection, count=0) at execMain.c:258
(More stack frames follow...)
(gdb) list
263 * Is 64-bit val1 relop 32-bit val2?
264 */
265 Datum
266 int84eq(PG_FUNCTION_ARGS)
267 {
268 int64 val1 = PG_GETARG_INT64(0);
269 int32 val2 = PG_GETARG_INT32(1);
270
271 PG_RETURN_BOOL(val1 == val2);
272 }
(gdb) info locals
val1 = -4294967296
val2 = -1074522056
(gdb) print fcinfo->arg
$2 = {2, 1, 158151112, 138821913, 3220445320, 157483904, 3220445336, 137092009,
158151112, 138821913, 2, 3051643714, 2300, 2, 3220445368, 137002246, 2,
158151112, 1, 0,
158151112, 2, 3220445944, 137573318, 3220445408, 1, 3220445400, 135003796, 1,
4294967295, 3220445448, 158151112, 158152572, 0, 0, 73472, 2, 1, 0, 0,
3081857364, 16777217,
3220445496, 137720153, 860040, 158042512, 256, 860040, 0, 0, 3220445495, 1,
1, 21509248, 3220445544, 137480840, 134842733, 23, 2868, 0, 0, 3220445560,
136675993, 5, 23,
158119256, 3220445816, 137487882, 158002664, 3051025560, 23, 3220445587,
5856, 23, 3051025560, 1, 7156544, 23, 3220445676, 4294967295, 16780084, 0,
158042512, 0, 3051025520,
3051025528, 824, 1671777080, 0, 262142, 0, 137093708, 3, 1, 2, 1, 1,
158134024, 3220445704, 4}
(gdb) print sizeof(fcinfo->arg[0])
$3 = 4
The problem, it seems to me, is that the 64-bit quantity is passed by-value
(squeezed into fcinfo->arg[0]'s 32-bits), whereas DatumGetInt64 expects it to
have been passed by reference (this being a 32-bit build and all.)
I imagine all of the above will pass with flying colours on 64-bit builds if
USE_FLOAT8_BYVAL ends up being #defined.
Cheers,
V.
-Original Message-
From: Alex Hunsaker [mailto:bada...@gmail.com]
Sent: Tuesday, May 25, 2010 1:27 PM
To: Vlad Romascanu
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #5472: Postgres hard crash in ...WHERE IN
(SELECT * FROM (VALUES (),...) AS t(col))
On Tue, May 25, 2010 at 10:39, Vlad Romascanu wrote:
> The following reproducibly crashes Postgres 8.4.3 (segfault) inside
> int84eq() on both Windows and Linux, but works just fine in 8.3.4:
Hrm... Both work for me (8.4.3 and 8.4.4).
--
=> SELECT col1, col2 FROM t1 WHERE col1 IN ( SELECT * FROM (VALUES (1),(2)) AS
(> t2(col1) )
-> ;
col1 | col2
--+--
1 |2
2 |3
=> SELECT col1, col2 FROM t1 WHERE col1::integer IN ( SELECT * FROM (VALUES
(> (1),(2)) AS t2(col1) );
col1 | col2
--+--
1 |2
2 |3
--
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 #5471: Postgres License Url is Misspelled
Fair enough but that is the sole use of that spelling on the website. Every other usage including the visible text uses "license". Sent from my iPhone On May 25, 2010, at 11:36 AM, Dave Page wrote: On Tue, May 25, 2010 at 10:53 AM, Christopher Hotchkiss wrote: The following bug has been logged online: Bug reference: 5471 Logged by: Christopher Hotchkiss Email address: christopher.hotchk...@gmail.com PostgreSQL version: 8.4 Operating system: Win32 Description:Postgres License Url is Misspelled Details: On the postgresql.org, about page, there is a link to the license page (http://www.postgresql.org/about/licence). The link name is correct but the url is misspelled. Not on this side of the pond. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On Tue, May 25, 2010 at 18:44, Tom Lane wrote: > Magnus Hagander writes: >> On Tue, May 25, 2010 at 17:48, Tom Lane wrote: >>> Craig Ringer writes: Bug 5245 is not the same issue. >>> >>> BTW, does anyone know exactly how to fix that? I'm looking at a related >>> request internal to Red Hat right now. > >> I have it on my TODO to figure it out, but from what I can tell it's >> very close to being undocumented, like most of OpenSSL. > > I've been googling this a bit, and the theory I have at the moment is > that Craig's proposed fix for #5468 will *also* fix #5245. However, > I'm not too adept at using openssl so actually testing that will > probably take a bit of time. Are you in a position to check it quickly? 'fraid not. I'm doing intensive training this week, so the first chance I'll have to give a proper check of it will be next week. sorry. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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 #5473: problema para reinstalar postgresql
The following bug has been logged online: Bug reference: 5473 Logged by: carolina Email address: caro.herrer...@hotmail.com PostgreSQL version: postgresql 8.4 Operating system: windows xp Description:problema para reinstalar postgresql Details: Hola..tengo el siquiente problema, por razones tecnicas tuve que desinstalar postgresql de mi maquina, al final de la desinstalacion me envio un mensaje donde me decia que ni el usuario ni la base se habian eliminado. Cuando Quise volver a instalarlo, se instalo pero al tratar de ejecutarlo me sale el siguiente error: Server doesn't listen The server doesn't accept connections: the connection library reports could not connect to server: Connection refused (0x274D/10061) Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432? Por lo que me fui a archivos de programa y borre una carpeta que estaba de nombre postgresql y tambien borre el usuario postgres, sin embargo nada funciona, solo se instala el pgadminIII pero no puedo crear una base de datos porque cada vez q lo intento me sale el mismo error. Tambien entre por modo a prueba de fallos y busque todo lo que tuviera nombre postgres y lo elimine y volvi a instalar pero nada me funciona..que puedo hacer?? -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Magnus Hagander writes: > On Tue, May 25, 2010 at 17:48, Tom Lane wrote: >> Craig Ringer writes: >>> Bug 5245 is not the same issue. They're talking about the server not >>> sending the full certificate chain for the cert that identifies the >>> server (server.crt). It's nothing to do with client certificates. >>> Without the full chain, the client can't verify the server unless it >>> happens to already have the intermediate certs between the server's cert >>> and the trusted root that signed it installed locally. I haven't >>> encountered #5245 myself, but will test it shortly to verify. It'd >>> certainly count as a significant bug, as it would make it impossible to >>> use indirect trust to verify a server (as is the case when a corporate >>> CA signed by a "big name" CA is in use). >> >> BTW, does anyone know exactly how to fix that? I'm looking at a related >> request internal to Red Hat right now. > I have it on my TODO to figure it out, but from what I can tell it's > very close to being undocumented, like most of OpenSSL. I spent some time experimenting with this. I set up a self-signed root CA, then an intermediate CA signed by the root, and then created server and client certs signed by the intermediate CA. I find that everything appears to work just fine if (1) the server's root.crt contains both the intermediate and root certs, and (2) the client's root.crt contains the root cert. (Most other combinations don't work, in particular if I give the client only the intermediate CA's cert, it rejects connections.) This leaves me a bit mystified as to what all the squawking is about. IIUC, putting the full chain of CA certs into server.crt is the standard way to set up a server that is signed by a non-root CA. Maybe we just need to document that? It certainly appears to me that the server sends all those certs to the client, because the client wouldn't be able to verify the server's cert without the intermediate CA cert, which it hasn't got on its end. (Either that, or there's something seriously broken in libpq's checking of server certs :-() I notice that the complaint in bug #5245, like the one in #5468, refers specifically to Java client behavior. I'm suspicious that what we're dealing with is a Java requirement that openssl itself does not have. 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] BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On 25/05/10 23:48, Tom Lane wrote: Craig Ringer writes: Bug 5245 is not the same issue. They're talking about the server not sending the full certificate chain for the cert that identifies the server (server.crt). It's nothing to do with client certificates. Without the full chain, the client can't verify the server unless it happens to already have the intermediate certs between the server's cert and the trusted root that signed it installed locally. I haven't encountered #5245 myself, but will test it shortly to verify. It'd certainly count as a significant bug, as it would make it impossible to use indirect trust to verify a server (as is the case when a corporate CA signed by a "big name" CA is in use). BTW, does anyone know exactly how to fix that? I'm looking at a related request internal to Red Hat right now. The first thing to test is whether concatenating the root cert onto the server cert in 'server.crt' does the trick. Though, really, OpenSSL should do the right thing automatically so long as it has the CA certificate loaded. Certainly my (patched) server is doing the right thing and sending the certificate. I'm 99% sure it did so before patching, though, just from having root.crt installed. However, this only works because the CA I want to validate clients against happens to be the same CA that signed my server's certificate, which is frequently *not* the case. I do *not* have the CA cert concatenated onto server.crt. I'll have to see if that works, because that's how it's usually done with OpenSSL. BTW, the little Java app I posted for client certifiate testing will let you get detailed tracing of a Pg SSL connection. Just run it with the default sslsocketfactory and no client cert: java -jar PgClientCertDemo.jar default '' '' '' \ jdbc:postgresql://YOURSERVER/YOURDATABASE?ssl=true&user=blah&password=blah and you'll get detailed trace information (possibly followed by an exception if it couldn't negotiate for some reason). Search for 'ServerHello' to find the start of the area of interest in the negotiation. Search for 'chain [' to find the server certificate chain entries. -- Craig Ringer -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Craig Ringer writes: > I do *not* have the CA cert concatenated onto server.crt. I'll have to > see if that works, because that's how it's usually done with OpenSSL. Hmm. That case doesn't work for me; what does work is including the intermediate cert in the server's root.crt. 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] BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On 26/05/10 07:37, Tom Lane wrote: Craig Ringer writes: I do *not* have the CA cert concatenated onto server.crt. I'll have to see if that works, because that's how it's usually done with OpenSSL. Hmm. That case doesn't work for me; what does work is including the intermediate cert in the server's root.crt. Sorry, that was my poor choice of words. s/the CA cert/the full certificate chain/g It is the intermediate certs that the client may not have that are the important ones. 'the CA' I was referring to was the _intermediate_ CA, eg the company sub-CA; I just needed to be (a lot) clearer about it. -- Craig Ringer -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Craig Ringer writes: > On 26/05/10 07:37, Tom Lane wrote: >> Craig Ringer writes: >>> I do *not* have the CA cert concatenated onto server.crt. I'll have to >>> see if that works, because that's how it's usually done with OpenSSL. >> >> Hmm. That case doesn't work for me; what does work is including the >> intermediate cert in the server's root.crt. > Sorry, that was my poor choice of words. > s/the CA cert/the full certificate chain/g What I meant to question is *which* file the intermediate CA certs go into. It doesn't seem tremendously sensible to me to put them into the server.crt file, since that's intended to define exactly one cert, namely the one identifying the server. On the other hand, putting them into the root.crt file implies that the intermediate certs are as good as the real root CA for trust purposes, which might not quite be the right thing either. 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] BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Craig Ringer writes: > BTW, the little Java app I posted for client certifiate testing will let > you get detailed tracing of a Pg SSL connection. Where did you post that exactly? I'm sure not finding it in this thread. 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] BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
* Tom Lane (t...@sss.pgh.pa.us) wrote: > What I meant to question is *which* file the intermediate CA certs > go into. It doesn't seem tremendously sensible to me to put them into > the server.crt file, since that's intended to define exactly one cert, > namely the one identifying the server. On the other hand, putting them > into the root.crt file implies that the intermediate certs are as good > as the real root CA for trust purposes, which might not quite be the > right thing either. root CA's are self-signed. intermediate CAs are not. They typically both go into directories/files like 'cacerts' (eg: Strongswan expects them in the cacerts directory). Most systems (uh, all?) will validate all the way up to a self-signed cert- intermediate CAs are only used as a mechanism to get to the root CA. I don't believe there's any confusion about intermediate CAs being accepted as root CAs just because they're in the same file or directory. All that being said- I don't think anyone would really complain if intermediate CAs and root CAs were stored in different directories/files. That's how Windows has certificates separated out. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
I wrote: > What I meant to question is *which* file the intermediate CA certs > go into. I did some more experimentation using "openssl s_client" to look at the cert exchange (after lobotomizing the postmaster so that it'd start a TLS exchange immediately upon connection, without our normal startup protocol). It appears to be the case that there are two configurations that work for CA chains: 1. server.crt can include just the server's own cert, if all intermediate certs up to and including the root are listed in root.crt. 2. server.crt can include the server's own cert plus all intermediate certs *up to and including the root*. In this case just the root need be listed in root.crt. One would think that the root cert could be omitted from server.crt if it's given in root.crt, but apparently this is not so, except for the special case where the server cert is directly signed by a root CA. I am now of the opinion that bug #5245 is in fact an exact dup of bug #5468. The previous reporter was jumping to conclusions about what his problem was: it was not that the server didn't send the full cert chain, but that Java couldn't do the right thing without having the list of cert names. It's possible, depending on exactly what Java does in these cases, that it has to have cert names given to it for the intermediate certs as well as the root. This would imply that only configuration #1 will work with Java clients, even after we add the SSL_CTX_set_client_CA_list call. That would be too bad, since configuration #2 is probably a bit preferable from the point of view of considering fewer certs to be fully trusted. In any case I'm thinking that we need to document how to set up configurations with chains of CA certs. 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] BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On 26/05/10 09:35, Tom Lane wrote: > I am now of the opinion that bug #5245 is in fact an exact dup of > bug #5468. The previous reporter was jumping to conclusions about what > his problem was: it was not that the server didn't send the full cert > chain, but that Java couldn't do the right thing without having the list > of cert names. No, they ARE NOT the same thing. #5468 is about *CLIENT* *CERTIFICATE* *AUTHENTICATION* where the *SERVER* VALIDATES THE *CLIENT* after the server sends a ServerHello. #5245 is about *CLIENT* *VALIDATION* *OF* *THE* *SERVER*, where the *CLIENT* VALIDATES THE *SERVER* after the server sends a CertificateRequest. You are confusing these two unrelated phases of SSL negotiation. For the complaint in #5245 to be addressed, the server must send the full certificate chain for the certificate the server is using to identify its self as pgserver.domain.com to the client during the ServerHello phase of SSL negotiation. If correctly configured, the server already does this, and #5245 really just needs some documentation improvements. For #5468 to be addressed, the server must send the CA certificates (not necessarily the full chain) of any CAs it trusts to identify clients to the client during the optional CertificateRequest phase of SSL negotiaton. This is only important if clientcert=1 is specified in pg_hba.conf . Sorry to continue "squarking" about this, but I just don't know how to explain it any better without stepping through the full SSL negotiation. It's frustrating that you're focusing on #5245 (which I didn't bring up and isn't the same thing at all) and disregarding the issue I'm trying to get fixed because #5245 is related to server misconfiguration. Hang on, I'll send side-by-side comparisons of patched and unnpatched server chat along with why they differ and why it's important in a min. > It's possible, depending on exactly what Java does in these cases, that > it has to have cert names given to it for the intermediate certs as well > as the root. (this relates to #5245 **NOT** #5468) Java, exactly like OpenSSL, needs *SOME* way to obtain any certificates between the a CA the client trusts and the server's certificate. If the client has the required intermidiate certs pre-installed, the server doesn't have to send them. If the client doesn't have them pre-installed, the server must send them or the server has no way to verify the chain of trust. This is bog-standard SSL stuff. > In any case I'm thinking that we need to document how to set up > configurations with chains of CA certs. Yes, and patch the server to send the list of trusted CAs to the client during client certificate negotiaton to fix #5468 . -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On 26/05/10 09:59, Craig Ringer wrote: > On 26/05/10 09:35, Tom Lane wrote: > >> I am now of the opinion that bug #5245 is in fact an exact dup of >> bug #5468. The previous reporter was jumping to conclusions about what >> his problem was: it was not that the server didn't send the full cert >> chain, but that Java couldn't do the right thing without having the list >> of cert names. > > No, they ARE NOT the same thing. > > #5468 is about *CLIENT* *CERTIFICATE* *AUTHENTICATION* where the > *SERVER* VALIDATES THE *CLIENT* after the server sends a > ServerHello. > > #5245 is about *CLIENT* *VALIDATION* *OF* *THE* *SERVER*, where the > *CLIENT* VALIDATES THE *SERVER* after the server sends a > CertificateRequest. Argh, now I'm getting MYSELF backwards. Correction: #5468 is about *CLIENT* *CERTIFICATE* *AUTHENTICATION* where the *SERVER* VALIDATES THE *CLIENT* after the server sends a *CertificateRequest*. <-- Was reversed above #5245 is about *CLIENT* *VALIDATION* *OF* *THE* *SERVER*, where the *CLIENT* VALIDATES THE *SERVER* after the server sends a *ServerHello*. <-- Was reversed above -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Craig Ringer writes: > You are confusing these two unrelated phases of SSL negotiation. No, I don't think so. > For the complaint in #5245 to be addressed, the server must send the > full certificate chain for the certificate the server is using to > identify its self as pgserver.domain.com to the client during the > ServerHello phase of SSL negotiation. If correctly configured, the > server already does this, and #5245 really just needs some documentation > improvements. As best I can tell, the server already does that, if correctly configured, and the configuration described in #5245 is correct. Therefore, it's failing because of something else. What the reporter of #5245 *says* the bug is is not necessarily what it *actually* is. What I believe his *actual* problem is is that Java is unable to verify the cert chain without a name for (at least) the root cert. That makes it the same as #5468, or at least it has the same fix. I have found an additional bug here, but it's in libpq not the server, and thus not responsible for either your bug report or his. I'll start a new thread about that in a minute. 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] BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On 26/05/10 10:16, Tom Lane wrote:
> Craig Ringer writes:
>> You are confusing these two unrelated phases of SSL negotiation.
>
> No, I don't think so.
http://www.cgisecurity.com/owasp/html/ch07s04.html
See in the second part, the new entry #5 "client request"
("CertificateRequest") ? That's the big Pg gets wrong at the moment.
It's not the same as #2 in that diagram, which is what #5245 talks about.
I'm going to send you a canned configuration to demonstrate this, along
with network traces from wireshark and a session log from the test app.
Give me an hour or so to put it together.
--
Craig Ringer
Tech-related writing: http://soapyfrogs.blogspot.com/
--
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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
All, Sorry, I havn't really been following this thread. * Craig Ringer (cr...@postnewspapers.com.au) wrote: > #5245 is about *CLIENT* *VALIDATION* *OF* *THE* *SERVER*, where the > *CLIENT* VALIDATES THE *SERVER* after the server sends a > CertificateRequest. > > For #5468 to be addressed, the server must send the CA certificates (not > necessarily the full chain) of any CAs it trusts to identify clients to > the client during the optional CertificateRequest phase of SSL > negotiaton. This is only important if clientcert=1 is specified in > pg_hba.conf . Yeah, this is right. I've had similar issues in the past, and what's better, some systems are too stupid to realize that they need to ignore CAs which aren't ones that they trust (hello Winbloze IPSEC). Being able to specificially say what CA cert should be sent to a given client in pg_hba.conf would certainly be nice. I don't know if any of the systems which talk to PG will have this problem (hopefully they'll all use libpq...), but it's definitely something I've run into in the past. > Java, exactly like OpenSSL, needs *SOME* way to obtain any certificates > between the a CA the client trusts and the server's certificate. If the > client has the required intermidiate certs pre-installed, the server > doesn't have to send them. If the client doesn't have them > pre-installed, the server must send them or the server has no way to > verify the chain of trust. > > This is bog-standard SSL stuff. Right, this should be supported and handled correctly (though, to be fair, alot of times people just configure the clients with the intermediate certs needed.. I realize that's not ideal though, since they can change over time and make things more difficult.). > > In any case I'm thinking that we need to document how to set up > > configurations with chains of CA certs. > > Yes, and patch the server to send the list of trusted CAs to the client > during client certificate negotiaton to fix #5468 . Agreed. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On 26/05/10 10:25, Stephen Frost wrote: >>> In any case I'm thinking that we need to document how to set up >>> configurations with chains of CA certs. >> >> Yes, and patch the server to send the list of trusted CAs to the client >> during client certificate negotiaton to fix #5468 . > > Agreed. Yeah, I'd really love to focus on the issue I reported (#5468) not an earlier issue that was bought up during the conversation... I'm putting together a completely self-contained test case ( database, home-made CA, client and server SSL certs, pg_hba.conf, client application, etc ) to demonstrate this at the moment, as I haven't been successful in explaining it despite my best efforts. Meanwhile, the mailing list seems to be silently eating my test program. So: you can download it from: executable jar with built-in usage/help: http://www.postnewspapers.com.au/~craig/PgClientCertDemo.jar sources and README: http://www.postnewspapers.com.au/~craig/PgClientCertDemo.zip Run the jar as: java -jar PgClientCertDemo.jar for help. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On 26/05/10 10:25, Stephen Frost wrote: >>> In any case I'm thinking that we need to document how to set up >>> configurations with chains of CA certs. >> >> Yes, and patch the server to send the list of trusted CAs to the client >> during client certificate negotiaton to fix #5468 . > > Agreed. A quick update on my own testing: I've found that the Sun PKCS#12 keystore provider behaves just like OpenSSL. It unconditionally sends the one and only client cert it has to the server - after all, there's only one to choose from. This is a royal pain to use, though, and requires the app's security to be configured from the command line at each launch, or the app to override all user settings and thus disable use of PKCS#11 hardware keys, etc. The issue only arises if there is a keystore in use where the client may have more than one client certificate/key availible to it and must pick which one to send to the server. This is true of the default Sun JKS keystore format, and for PKCS#11 stores like hardware crypto keys. My self-contained test case will demonstrate both PKCS#12 file and JKS keystore cases. Give me a bit to put it all together and you'll have something you can play with, watch chat on the network, etc. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> What I meant to question is *which* file the intermediate CA certs >> go into. It doesn't seem tremendously sensible to me to put them into >> the server.crt file, since that's intended to define exactly one cert, > root CA's are self-signed. intermediate CAs are not. They typically > both go into directories/files like 'cacerts' (eg: Strongswan expects > them in the cacerts directory). Most systems (uh, all?) will validate > all the way up to a self-signed cert- intermediate CAs are only used as > a mechanism to get to the root CA. I don't believe there's any > confusion about intermediate CAs being accepted as root CAs just because > they're in the same file or directory. > All that being said- I don't think anyone would really complain if > intermediate CAs and root CAs were stored in different > directories/files. That's how Windows has certificates separated out. After some more testing I think I've wrapped my head around how this really ought to be documented, and it goes like this: * server.crt is about proving the server's identity to the clients. It must contain a cert or cert chain that leads to a CA that is trusted by the clients (ie, is listed in the client-side root.crt files). * root.crt is about proving the clients' identities to the server. It lists the root CAs that the server trusts for that purpose. * Similarly, the client-side postgresql.crt contains a cert (or, if we fix libpq's bugs, a cert chain) that leads to a CA trusted by the server, while the client-side root.crt lists the root CAs that the client trusts for verifying the server. In principle, you could have the server and clients using totally nonoverlapping sets of trusted CAs (nonoverlapping root.crt lists), as long as each can chain its identity up to a CA the other trusts. So it's all nice and symmetrical. The experimentation I did earlier indicates that there's some leakage whereby openssl will pick up intermediate certs that are listed in root.crt and use them to form a chain supporting the server.crt certificate, but that doesn't fit nicely into the mental model. I'm now of the opinion that we shouldn't recommend or even document that way of doing things. 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] Ola
2010/5/21 Nelson da Silva da Silva : > Qualquer versao que instalo da erro conforme abaixo : > > An error ocurred executing the Microsoft VC++ runtime installer, poderiam me > dar uma dica de solução ? This is an English-language mailing list; we do have some mailing lists in other languages - see the following URL, under "regional lists". http://www.postgresql.org/community/lists/ Also, you probably need to provide a bit more detail for anyone to help you. http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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 #5469: regexp_matches() has poor behaviour and more poor documentation
On Mon, May 24, 2010 at 9:16 AM, Daniele Varrazzo wrote: > regexp_matches() has been recently discussed > (http://archives.postgresql.org/pgsql-bugs/2010-04/msg00026.php): it is a > setof function and as such it can drop results. > > Unfortunately it is an useful function to newcomers who use SQL, use regexps > but don't arrive to read the chapter 34.4.7. (i.e. Extending SQL -> Query > Language (SQL) Functions -> SQL Functions Returning Sets) and are not so > enlightened to know that "setof text[]" means "if it doesn't match, it drops > the record". They just expect the function to be a LIKE on steroids. > > Please describe the behavior in the documentation of the function (i.e. > table 9-6. and section 9.7.3), possibly provide a function with a saner > interface, i.e. returning a text[] of the first match or NULL on no match, > or document a workaround (suitable for an user knowing regexps but not > setof-returning functions) to make the function not dropping record (e.g. I > fixed the "bug" adding a "|" at the end of the pattern, so that the function > returns an array of NULL in case of no match: I don't think it is a trivial > workaround). I'm not sure that it's very productive to refer to the behavior of our code as insane. We do document this in section 9.7.3, pretty explicitly: "The regexp_matches function returns all of the captured substrings resulting from matching a POSIX regular expression pattern. It has the syntax regexp_matches(string, pattern [, flags ]). If there is no match to the pattern, the function returns no rows. If there is a match, the function returns a text array whose n'th element is the substring matching the n'th parenthesized subexpression of the pattern (not counting "non-capturing" parentheses; see below for details)." I think that's pretty clear. Your mileage may vary, of course. I'm less confident than what we have in table 9-6 (other string functions, in section 9.4, string functions and operators) is clear on first reading, but neither do I immediately know how to improve it. Perhaps instead of critiquing our insanity you could provide some specific suggestions for improvement. Similarly, if you think we should have another function besides regexp_matches(), rather than just complaining that we don't, it would be more useful to suggest a name and a specific behavior and ideally maybe even provide a patch (or just the docs portion of a patch) - especially if you can point to a specific use-case that is hard to do with the SRF but would be easier with a function with a different interface. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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 #5469: regexp_matches() has poor behaviour and more poor documentation
On 26/05/10 15:51, Robert Haas wrote: I'm not sure that it's very productive to refer to the behavior of our code as insane. Not meaning to single you out Robert, but typically folk are honest with their impression of the code without worrying about feather ruffling too much e.g: searching for "brain dead" in the pg-hackers archives returns a sizeable collection of reading material. Personally I think it is good to be blunt about code we consider not well thought out or well behaved. Obviously in some cases such comments may turn out to be incorrect or misleading (e.g user error or not reading the docs), but I don't think we should try (too hard anyway) to smother any strong criticism. regards Mark -- 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 #5468: Pg doesn't send accepted root CA list to client during SSL client cert request
On 26/05/10 11:01, Tom Lane wrote: > In principle, you could have the server and clients using totally > nonoverlapping sets of trusted CAs (nonoverlapping root.crt lists), > as long as each can chain its identity up to a CA the other trusts. > So it's all nice and symmetrical. ... and it's exactly this cases that confuses keystore based clients that may have multiple certs installed. See the self-contained test case here: http://www.postnewspapers.com.au/~craig/testcase.zip ... which includes a Pg datadir and configuration, the certificate authority, the certificates, a detailed log of test case setup, the test programs, logs of test output along with explanation of those logs, etc. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
