Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
Dan Kaminsky wrote: > >> 1) No roots (but still works for some unknown reason) > >> 2) Explicitly configured corporate roots > >> 3) Explicitly configured corporate roots, AND global roots > >> 4) Global roots (but still works for some unknown reason) > So, if you do nothing special, it's #1? Sounds like the path of least > resistance is no security. Uh oh. Yeah, in the average, if not common case, a user interested in SSL use would probably just follow the recipe in the documentation for creating and installing a self-signed certificate with no certificate checking in the client. Which, as you correctly observe, is pretty much completely useless. Someone should probably redesign, reconfigure, and redocument this. -- 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 #4340: SECURITY: Is SSL Doing Anything?
Peter Eisentraut wrote: > Dan Kaminsky wrote: 1) No roots (but still works for some unknown reason) 2) Explicitly configured corporate roots 3) Explicitly configured corporate roots, AND global roots 4) Global roots (but still works for some unknown reason) > >> So, if you do nothing special, it's #1? Sounds like the path of least >> resistance is no security. Uh oh. > > Yeah, in the average, if not common case, a user interested in SSL use would > probably just follow the recipe in the documentation for creating and > installing a self-signed certificate with no certificate checking in the > client. Which, as you correctly observe, is pretty much completely useless. > > Someone should probably redesign, reconfigure, and redocument this. Agreed. I'd like to suggest that for the "easy fix" (without supporting custom callbacks and whatever) we create a new connection parameter called "sslverifypeer". It can be set to "verifypeer", "verifycert" or "off". When set to "verifypeer", we will verify the peer name and the certificate. When "verifycert" we just verify the certificate, fail if we can't find a root certificate, but ignore the common name. "off" should be self-explaining. I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with a default of "off". That way we don't break existing setups, but give users the ability to verify if if they want to. Comments? //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] BUG #4340: SECURITY: Is SSL Doing Anything?
Magnus Hagander <[EMAIL PROTECTED]> writes: > I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with > a default of "off". That way we don't break existing setups, but give > users the ability to verify if if they want to. This seems a bit large/invasive/new-feature-ish for a backpatch. 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 #4340: SECURITY: Is SSL Doing Anything?
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with >> a default of "off". That way we don't break existing setups, but give >> users the ability to verify if if they want to. > > This seems a bit large/invasive/new-feature-ish for a backpatch. I agree in principle, but I really didn't want to leave our "old" users in the cold, unable to actually use SSL to secure their systems.. The code is there, actually, it's just #ifdef NOT_USED :-) From a *long* time ago, and the commit message just says "silence compiler warnings", so I've not managed to figure out why... //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] BUG #4340: SECURITY: Is SSL Doing Anything?
Magnus Hagander <[EMAIL PROTECTED]> writes: > The code is there, actually, it's just #ifdef NOT_USED :-) From a *long* > time ago, and the commit message just says "silence compiler warnings", > so I've not managed to figure out why... I think the commit you're looking for is this one: 2002-09-26 00:41 momjian * doc/src/sgml/runtime.sgml, src/backend/libpq/be-secure.c, src/interfaces/libpq/fe-secure.c: Allow SSL to work withouth client-side certificate infrastructure. so you'd probably need to root around in the archives from around then to see why this was considered a good idea. 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 #4340: SECURITY: Is SSL Doing Anything?
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> The code is there, actually, it's just #ifdef NOT_USED :-) From a *long* >> time ago, and the commit message just says "silence compiler warnings", >> so I've not managed to figure out why... > > I think the commit you're looking for is this one: > > 2002-09-26 00:41 momjian > > * doc/src/sgml/runtime.sgml, src/backend/libpq/be-secure.c, > src/interfaces/libpq/fe-secure.c: Allow SSL to work withouth > client-side certificate infrastructure. > > so you'd probably need to root around in the archives from around then > to see why this was considered a good idea. No, that's not the one. It's the one after that one, at: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-secure.c.diff?r1=1.14;r2=1.15 In general, that code needs a look-over, I think. There may be more changes required. //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] BUG #4340: SECURITY: Is SSL Doing Anything?
Magnus Hagander <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I think the commit you're looking for is this one: >> 2002-09-26 00:41 momjian > No, that's not the one. It's the one after that one, at: No, that one is just fallout from having removed the *use* of the function in the earlier patch. 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 #4340: SECURITY: Is SSL Doing Anything?
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> I think the commit you're looking for is this one: >>> 2002-09-26 00:41 momjian > >> No, that's not the one. It's the one after that one, at: > > No, that one is just fallout from having removed the *use* of the > function in the earlier patch. Hmm. Bummer, that's right. Anyway. The code should be fairly usable I think, but we'll see that once there is some code to test... If the method I suggested seems good I'll work along that line, and we'll see when it's done if it's reasonable to backpatch it or not. If it seems the wrong track, I'm interested in suggestions on which direction we should be going in :-) //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] BUG #4340: SECURITY: Is SSL Doing Anything?
Magnus Hagander <[EMAIL PROTECTED]> writes: > In general, that code needs a look-over, I think. There may be more > changes required. Yeah, even assuming that it did what is wanted in the first place, it's been #ifdef NOT_USED for an awfully long time. I'd suggest looking for thread-safety and Windows-portability issues ... 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 #4340: SECURITY: Is SSL Doing Anything?
Magnus Hagander wrote: > Tom Lane wrote: > > Magnus Hagander <[EMAIL PROTECTED]> writes: > >> The code is there, actually, it's just #ifdef NOT_USED :-) From a *long* > >> time ago, and the commit message just says "silence compiler warnings", > >> so I've not managed to figure out why... > > > > I think the commit you're looking for is this one: > > > > 2002-09-26 00:41 momjian > > > > * doc/src/sgml/runtime.sgml, src/backend/libpq/be-secure.c, > > src/interfaces/libpq/fe-secure.c: Allow SSL to work withouth > > client-side certificate infrastructure. > > > > so you'd probably need to root around in the archives from around then > > to see why this was considered a good idea. > > No, that's not the one. It's the one after that one, at: > > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-secure.c.diff?r1=1.14;r2=1.15 > > In general, that code needs a look-over, I think. There may be more > changes required. I found the reason for the patch; the SSL guy at that time, "Bear", disappeared, and our code required SSL certificates at that point, so I removed the requrement: http://archives.postgresql.org/pgsql-hackers/2002-09/msg01522.php I will work with Magnus on cleaning this up. -- Bruce Momjian <[EMAIL PROTECTED]>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 #4340: SECURITY: Is SSL Doing Anything?
Bruce Momjian <[EMAIL PROTECTED]> writes: > I found the reason for the patch; the SSL guy at that time, "Bear", > disappeared, and our code required SSL certificates at that point, so I > removed the requrement: Hmm, according to that thread the code that got diked out "didn't work according to Peter", but I can't find anything in Sept 2002 pgsql-hackers suggesting exactly what was wrong. 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 #4340: SECURITY: Is SSL Doing Anything?
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I found the reason for the patch; the SSL guy at that time, "Bear", > > disappeared, and our code required SSL certificates at that point, so I > > removed the requrement: > > Hmm, according to that thread the code that got diked out "didn't work > according to Peter", but I can't find anything in Sept 2002 > pgsql-hackers suggesting exactly what was wrong. I looked back in hackers through June 2002 and found no mention of why it didn't work either. -- Bruce Momjian <[EMAIL PROTECTED]>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 #4271: dropped columns conflict with returning rules
Added to TODO: Enable creation of RETURNING rules on inherited tables that have dropped columns http://archives.postgresql.org/pgsql-bugs/2008-06/msg00183.php --- Tom Lane wrote: > "Alexey Bashtanov" <[EMAIL PROTECTED]> writes: > > I have created a partitioned table cache with partitions cache_id_g_4184088 > > and cache_id_le_4184088 those inherit cache. > > I provided insert by the following rule: > > CREATE RULE cache_partic AS ON INSERT TO cache DO INSTEAD INSERT INTO > > cache_id_g_4184088 VALUES (new.*) RETURNING cache_id_g_4184088.*; > > > after I ran > > ALTER TABLE cache add column foo > > ALTER TABLE cache add column bar > > ALTER TABLE cache drop column bar > > ALTER TABLE cache add column quackquack > > > this rule started to work incorrectly: it did not store foo and quackquack > > values but used nulls instead. > > This is expected behavior because the * expressions are expanded when > the rule is defined: > > regression=# create table foo(f1 int, f2 int, f3 int); > CREATE TABLE > regression=# create table foo1() inherits (foo); > CREATE TABLE > regression=# create rule redirect as on insert to foo do instead > insert into foo1 values(new.*) returning foo1.*; > CREATE RULE > regression=# \d foo > Table "public.foo" > Column | Type | Modifiers > +-+--- > f1 | integer | > f2 | integer | > f3 | integer | > Rules: > redirect AS > ON INSERT TO foo DO INSTEAD INSERT INTO foo1 (f1, f2, f3) > VALUES (new.f1, new.f2, new.f3) > RETURNING foo1.f1, foo1.f2, foo1.f3 > > regression=# alter table foo add column f4 int; > ALTER TABLE > regression=# \d foo > Table "public.foo" > Column | Type | Modifiers > +-+--- > f1 | integer | > f2 | integer | > f3 | integer | > f4 | integer | > Rules: > redirect AS > ON INSERT TO foo DO INSTEAD INSERT INTO foo1 (f1, f2, f3) > VALUES (new.f1, new.f2, new.f3) > RETURNING foo1.f1, foo1.f2, foo1.f3 > > Of course you can redefine the rule after adding a column: > > regression=# create or replace rule redirect as on insert to foo do instead > insert into foo1 values(new.*) returning foo1.*; > CREATE RULE > regression=# \d foo > Table "public.foo" > Column | Type | Modifiers > +-+--- > f1 | integer | > f2 | integer | > f3 | integer | > f4 | integer | > Rules: > redirect AS > ON INSERT TO foo DO INSTEAD INSERT INTO foo1 (f1, f2, f3, f4) > VALUES (new.f1, new.f2, new.f3, new.f4) > RETURNING foo1.f1, foo1.f2, foo1.f3, foo1.f4 > > > > When I tried to ReCREATE this rule, POSTGRESQL said 'ERROR: cannot convert > > relation containing dropped columns to view' > > What did you do *exactly*? I tried > > regression=# alter table foo add column f5 int; > ALTER TABLE > regression=# alter table foo drop column f5; > ALTER TABLE > regression=# create or replace rule redirect as on insert to foo do instead > insert into foo1 values(new.*) returning foo1.*; > ERROR: RETURNING list has too few entries > > which does seem like a bug but it's not what you are describing. > > 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 -- Bruce Momjian <[EMAIL PROTECTED]>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
[BUGS] BUG #4365: Need 24x 7 monitoring software for Postgresql
The following bug has been logged online: Bug reference: 4365 Logged by: Gregg Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Sus 10 Description:Need 24x 7 monitoring software for Postgresql Details: I need 24 x7 monitoring software for Database to give stats and status on the databases -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
