[BUGS] BUG #4753: erro
The following bug has been logged online: Bug reference: 4753 Logged by: Vlad Email address: vlads...@gmail.com.br PostgreSQL version: 8.3.7 Operating system: windons Description:erro Details: 0x274D/10061 erro no postgresql não carrega o servidor -- 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 #4754: erro
The following bug has been logged online: Bug reference: 4754 Logged by: Vlad Email address: vlads...@gmail.com PostgreSQL version: 8.3.7 Operating system: windons Description:erro Details: 0x274D/10061 erro no postgresql não carrega o servidor -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Reg: 25P02, current transaction is aborted, commands ignored until end of transaction block
Dear all,
I am trying to port my application from Oracle to PostGREs. I have a
problem while doing so. In my application i need to update record if the delete
on the respective record is failed due to Constraint Violation. But SQL Error:
0, SQLState: 25P02 ERROR [JDBCExceptionReporter] ERROR: current transaction is
aborted, commands ignored until end of transaction block is being generated
while updating the record. But with Oracle i am able to do this.
I have tried with latest Jar [postgresql-8.3-604.jdbc3.jar] too, but problem
still exists.
Here is the code that i worked on:
try{
session = sessionManager.getSession();
transaction = session.beginTransaction();
session.delete(objects[i]);
session.flush();
}catch(ConstraintViolationException e){
objects[i].setDeleted(Integer.valueOf(1));
session.saveOrUpdate(object[i]);
session.flush();
}
transaction.commit();
sessionManager.closeSession(session);
I am using platform java 1.5, jBoss 4.2.3, Hibernate v3.3, PostGREs v8.3 and OS
Windows me.
Thanks in advance,
Bhavani.G
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
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. -- 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] Reg: 25P02, current transaction is aborted, commands ignored until end of transaction block
On Fri, 10 Apr 2009 11:55:03 +0200, Durgabhavani.g wrote: I am trying to port my application from Oracle to PostGREs. I have a problem while doing so. In my application i need to update record if the delete on the respective record is failed due to Constraint Violation. But SQL Error: 0, SQLState: 25P02 ERROR [JDBCExceptionReporter] ERROR: current transaction is aborted, commands ignored until end of transaction block is being generated while updating the record. But with Oracle i am able to do this. What you may be looking for is described here: http://www.postgresql.org/docs/current/interactive/sql-savepoint.html In short: creating a savepoint, executing a query and - in case the query fails - rolling back to the savepoint created previously restores the transaction state. In your case, you should create the SAVEPOINT before executing the DELETE query, and when it fails - ROLLBACK to the savepoint and continue normally. As far as I understand your code/intentions, that is. -- ru -- 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 [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 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? Thanks for considering, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Martin Pitt writes: > 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 think I agree with Martin on this. The server doesn't fail if you don't provide it a root cert; it just doesn't try to trace client certs to the root. It is not apparent why the client should be stricter than that, and definitely not apparent why such strictness should be the default behavior. 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: > Martin Pitt writes: >> 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 think I agree with Martin on this. The server doesn't fail if you > don't provide it a root cert; it just doesn't try to trace client certs > to the root. It is not apparent why the client should be stricter than > that, and definitely not apparent why such strictness should be the > default behavior. It's "secure by default". Without it, most people will *never* get protected by verifying the certificate because they will not manually copy root certificates there. And it would open up a big window for making a very simple mistake (file missing or wrong name) that would then silently disable SSL verification completely. Arguably it's a bug to silently install a snakeoil cert by default. But I realize that you have issues with backwards compatibility. How about changing it so it points PGSSLROOTCERT to a system wide location that holds the root.crt file? The user can then override this if proper verification of a real certificate is wanted. (you could also disable certificate verification by setting PGSSLVERIFY=none, but that seems like a much worse fix) //Mangus -- 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: > Tom Lane wrote: >> It is not apparent why the client should be stricter than >> that, and definitely not apparent why such strictness should be the >> default behavior. > It's "secure by default". In my experience ssh itself isn't this strict. Why should libpq be? I think most users will see this as a bug, not as being secure. 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: >> Tom Lane wrote: >>> It is not apparent why the client should be stricter than >>> that, and definitely not apparent why such strictness should be the >>> default behavior. > >> It's "secure by default". > > In my experience ssh itself isn't this strict. Why should libpq be? > I think most users will see this as a bug, not as being secure. ssh prompts the user when this happens. We don't have a mechanism for prompting the user. IIRC when you run ssh in a mode where it can't prompt the user, it will refuse to connect, thus being just as strict as we are. //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: > Tom Lane wrote: >> In my experience ssh itself isn't this strict. Why should libpq be? > ssh prompts the user when this happens. We don't have a mechanism for > prompting the user. In the first place, I have never seen such a prompt, despite the fact that I use ssh constantly to connect to machines that I know do not have properly signed certificates. If there is such a prompt, it isn't the default behavior. In the second place, unconditionally failing isn't a particularly nice emulation of a prompting behavior. Perhaps a suitable compromise is to have the failure message include a hint about how to prevent the failure if you don't want it? 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: >> Tom Lane wrote: >>> In my experience ssh itself isn't this strict. Why should libpq be? > >> ssh prompts the user when this happens. We don't have a mechanism for >> prompting the user. > > In the first place, I have never seen such a prompt, despite the fact > that I use ssh constantly to connect to machines that I know do not have > properly signed certificates. If there is such a prompt, it isn't the > default behavior. In the second place, unconditionally failing isn't a > particularly nice emulation of a prompting behavior. *really*? Here's what I get as an example (after removing the trust): h...@mha-laptop:~/.ssh$ ssh cvs.postgresql.org The authenticity of host 'cvs.postgresql.org (217.196.146.206)' can't be established. DSA key fingerprint is 54:27:10:f3:48:0a:f0:b6:c3:14:79:7e:49:c0:75:f3. Are you sure you want to continue connecting (yes/no)? ^C Are you saying you're not getting that? I've got that (or similar) on every single platform I recall having used... ssh doesn't use certificates, actually, it uses known host keys. The difference being that with certificates you trust the root and thereby everything under it. For ssh, afaik, you need to trust each host individually. > Perhaps a suitable compromise is to have the failure message include > a hint about how to prevent the failure if you don't want it? That would definitely work for me. //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: > Tom Lane wrote: >> In the first place, I have never seen such a prompt, despite the fact >> that I use ssh constantly to connect to machines that I know do not have >> properly signed certificates. > *really*? Here's what I get as an example (after removing the trust): > h...@mha-laptop:~/.ssh$ ssh cvs.postgresql.org > The authenticity of host 'cvs.postgresql.org (217.196.146.206)' can't be > established. > DSA key fingerprint is 54:27:10:f3:48:0a:f0:b6:c3:14:79:7e:49:c0:75:f3. > Are you sure you want to continue connecting (yes/no)? ^C This simply tells you that the machine has a new key since last time you talked to it. It doesn't have anything to do with whether the machine's cert has been signed by anybody. It also doesn't prevent you from operating without a root.crt file of your own. 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: >> Tom Lane wrote: >>> In the first place, I have never seen such a prompt, despite the fact >>> that I use ssh constantly to connect to machines that I know do not have >>> properly signed certificates. > >> *really*? Here's what I get as an example (after removing the trust): > >> h...@mha-laptop:~/.ssh$ ssh cvs.postgresql.org >> The authenticity of host 'cvs.postgresql.org (217.196.146.206)' can't be >> established. >> DSA key fingerprint is 54:27:10:f3:48:0a:f0:b6:c3:14:79:7e:49:c0:75:f3. >> Are you sure you want to continue connecting (yes/no)? ^C > > This simply tells you that the machine has a new key since last time you > talked to it. It doesn't have anything to do with whether the machine's > cert has been signed by anybody. It also doesn't prevent you from > operating without a root.crt file of your own. SSH doesn't have certificates. The trusted key is as close as you get. You can compare it to ssl with *only* self-signed-certificate. Where it prompts you to authenticate the fingerprint of said self-signed-certificate. They do it through a prompt. We do it through a file. But as long as you in pg only deal with self-signed certs, the outcome is pretty much the same. //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
On Friday 10 April 2009 17:13:55 Martin Pitt wrote: > 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. This is not a question of new client with old server. The new version of the client has a more secure default that will possibly prevent it from connecting to *any* server that is not adequately configured. But it's a default, so the user can change it. Consider the analogy that a new web browser comes out that verifies server certificates (as of course all respectable browsers do nowadays) whereas the previous version one didn't. The right fix there is certainly not to downgrade this to a warning when connecting to an older web server. Not to mention the security implications: A rogue server could simply pretend to be of an older version to circumvent the client's security check. -- 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 (t...@sss.pgh.pa.us) wrote: > I think I agree with Martin on this. The server doesn't fail if you > don't provide it a root cert; it just doesn't try to trace client certs > to the root. It is not apparent why the client should be stricter than > that, and definitely not apparent why such strictness should be the > default behavior. I agree with this. Avoiding spoofing is good, but so is on the wire encryption even if you don't have anti-spoofing. This is a reasonable set-up and we shouldn't just fail on it. Stephen signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
* Peter Eisentraut (pete...@gmx.net) wrote: > This is not a question of new client with old server. The new version of the > client has a more secure default that will possibly prevent it from > connecting > to *any* server that is not adequately configured. A properly configured server could cause a failure too unless the client is *also* properly configured. Sure, it's good for people to do. No, I don't think we should break things if people don't build out a whole PKI for PG and configure all their certs correctly. It's pie-in-the-sky to think everyone will do that, and in the end most will just say "SSL breaks stuff, so we'll disable it" which certainly isn't better. > But it's a default, so the user can change it. It should be the default to connect, maybe with a warning. > Consider the analogy that a new web browser comes out that verifies server > certificates (as of course all respectable browsers do nowadays) whereas the > previous version one didn't. The right fix there is certainly not to > downgrade this to a warning when connecting to an older web server. Uh, no, the right fix is to have a warning/prompt (as pretty much all web browsers today do) but then continue to connect. Also, the web-browser analogy completely falls apart when you consider that the use case is significantly different (how many times have you connected to a PG server that you didn't know?). Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] possible bug not in open items
Jeff Davis writes: > Here is a patch that does what I think Heikki was suggesting. If a > proper fix is non-trivial, then I assume there's some problem with my > patch, but I'll post it for the archives anyway. This patch is so wrong that it's scary. You can't have ImmediateInterruptOK true over the duration of any significant amount of backend processing --- as an example, if you take control away in the middle of a malloc call, you'll probably be left with a corrupt malloc arena. It doesn't even work to try to take control away while control is inside, say, the OpenSSL code. The reason we have the prepare_for_client_read/client_read_ended hooks is to allow the flag to be turned on over a sufficiently narrow scope --- to wit, the recv() kernel call and nothing else --- that it's safe. AFAICS, a safe patch for this has got to involve teaching those hooks about COPY mode. 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
Stephen Frost wrote: -- Start of PGP signed section. > * Peter Eisentraut (pete...@gmx.net) wrote: > > This is not a question of new client with old server. The new version of > > the > > client has a more secure default that will possibly prevent it from > > connecting > > to *any* server that is not adequately configured. > > A properly configured server could cause a failure too unless the client > is *also* properly configured. Sure, it's good for people to do. No, I > don't think we should break things if people don't build out a whole PKI > for PG and configure all their certs correctly. It's pie-in-the-sky to > think everyone will do that, and in the end most will just say "SSL > breaks stuff, so we'll disable it" which certainly isn't better. > > > But it's a default, so the user can change it. > > It should be the default to connect, maybe with a warning. > > > Consider the analogy that a new web browser comes out that verifies server > > certificates (as of course all respectable browsers do nowadays) whereas > > the > > previous version one didn't. The right fix there is certainly not to > > downgrade this to a warning when connecting to an older web server. > > Uh, no, the right fix is to have a warning/prompt (as pretty much all > web browsers today do) but then continue to connect. Also, the > web-browser analogy completely falls apart when you consider that the > use case is significantly different (how many times have you connected > to a PG server that you didn't know?). The problem is that libpq doesn't have any ability to warn/prompt like SSH and web browsers do, so I think Magnus patterned the libpq behavior around cases where warning/prompt failed in these environments. I am not saying the current behavior is correct, only why it was configured that way. -- 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
On Friday 10 April 2009 21:27:54 Stephen Frost wrote: > I agree with this. Avoiding spoofing is good, but so is on the wire > encryption even if you don't have anti-spoofing. This is a reasonable > set-up and we shouldn't just fail on it. This whole debate hinges on the argument that encryption without anti-spoofing is *not* useful. -- 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
On Friday 10 April 2009 21:32:29 Stephen Frost wrote: > A properly configured server could cause a failure too unless the client > is *also* properly configured. Sure, it's good for people to do. No, I > don't think we should break things if people don't build out a whole PKI > for PG and configure all their certs correctly. It's pie-in-the-sky to > think everyone will do that, and in the end most will just say "SSL > breaks stuff, so we'll disable it" which certainly isn't better. That's debatable. I think it's better. > > But it's a default, so the user can change it. > > It should be the default to connect, maybe with a warning. If you connect with a warning, you have possibly already given up sensitive information. That's no good. > > Consider the analogy that a new web browser comes out that verifies > > server certificates (as of course all respectable browsers do nowadays) > > whereas the previous version one didn't. The right fix there is > > certainly not to downgrade this to a warning when connecting to an older > > web server. > > Uh, no, the right fix is to have a warning/prompt (as pretty much all > web browsers today do) but then continue to connect. Yes, this was under discussion a while ago but no one wanted to implement it. > Also, the > web-browser analogy completely falls apart when you consider that the > use case is significantly different (how many times have you connected > to a PG server that you didn't know?). This is a fuzzy argument. What do you mean by "know", and how do you verify what you "know" and whether what you "know" is correct? And why are you using SSL at all if you think you "know" everything? -- 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 writes: > On Friday 10 April 2009 21:27:54 Stephen Frost wrote: >> I agree with this. Avoiding spoofing is good, but so is on the wire >> encryption even if you don't have anti-spoofing. This is a reasonable >> set-up and we shouldn't just fail on it. > This whole debate hinges on the argument that encryption without > anti-spoofing is *not* useful. If we believe that then we need to also change the server to require a root.crt. I do not believe it --- there is a significant difference in the difficulty of passive listening and active spoofing. 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
On Friday 10 April 2009 22:44:44 Bruce Momjian wrote: > The problem is that libpq doesn't have any ability to warn/prompt like > SSH and web browsers do, so I think Magnus patterned the libpq behavior > around cases where warning/prompt failed in these environments. > > I am not saying the current behavior is correct, only why it was > configured that way. Of course. But if we really wanted to, this is nothing that can't be solved with callbacks or something like that. -- 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
On Friday 10 April 2009 21:32:29 Stephen Frost wrote: > Uh, no, the right fix is to have a warning/prompt (as pretty much all > web browsers today do) but then continue to connect. On that matter, it is interesting to observe where web browsers are heading today. It used to be that web browsers said, "Cannot verify server certificate. Continue? [Yes] [No]" and everyone clicked yes. The new firefox just says "invalid certificate" and nothing else, and then somewhere below there is a small link to "Add an exception" and you need a total of four clicks to proceed. So that looks a lot like that they are moving away from easily allowing unverifyable server certificates as well. -- 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
On Friday 10 April 2009 22:50:02 Tom Lane wrote: > Peter Eisentraut writes: > > On Friday 10 April 2009 21:27:54 Stephen Frost wrote: > >> I agree with this. Avoiding spoofing is good, but so is on the wire > >> encryption even if you don't have anti-spoofing. This is a reasonable > >> set-up and we shouldn't just fail on it. > > > > This whole debate hinges on the argument that encryption without > > anti-spoofing is *not* useful. > > If we believe that then we need to also change the server to require > a root.crt. That would make sense if the server required SSL in the first place. But the default configuration of the server is to take anything. It would conceivably be proper to require a stronger client authentication mechanism than "trust" on hostssl lines. (This doesn't have to be SSL-based client authentication.) But we ship the server with a wide-open client access policy. Do you want to change that? I think not. But if packagers want to change that, by all means set up something stronger. > I do not believe it --- there is a significant difference > in the difficulty of passive listening and active spoofing. Sure, there is a difference. But what is it, and what percentage of users do you think are affected by it and can judge the difference? -- 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 writes: > On Friday 10 April 2009 22:50:02 Tom Lane wrote: >> I do not believe it --- there is a significant difference >> in the difficulty of passive listening and active spoofing. > Sure, there is a difference. But what is it, and what percentage of users do > you think are affected by it and can judge the difference? I don't know, and I don't wish to be forcing a decision about it on users. 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
[ sorry for double reply, but I missed answering this point ] Peter Eisentraut writes: > On Friday 10 April 2009 22:50:02 Tom Lane wrote: >> If we believe that then we need to also change the server to require >> a root.crt. > That would make sense if the server required SSL in the first place. But the > default configuration of the server is to take anything. It would conceivably > be proper to require a stronger client authentication mechanism than "trust" > on hostssl lines. (This doesn't have to be SSL-based client authentication.) I guess I was insufficiently precise, because you seem to be responding to a different point than I intended to make. What I should have said was "change the server to require a root.crt in order to successfully establish an SSL connection". Not that you have to have such a file even if you don't care about SSL. But if we are going to enforce that SSL implies verification on the client side, then surely it should also imply that on the server side. 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 escreveu: Peter Eisentraut writes: On Friday 10 April 2009 22:50:02 Tom Lane wrote: I do not believe it --- there is a significant difference in the difficulty of passive listening and active spoofing. Sure, there is a difference. But what is it, and what percentage of users do you think are affected by it and can judge the difference? I don't know, and I don't wish to be forcing a decision about it on users. Why don't we follow Magnus suggestion? HINT: you could disable certificate verification by setting PGSSLVERIFY=none -- Euler Taveira de Oliveira http://www.timbira.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] possible bug not in open items
On Fri, 2009-04-10 at 14:47 -0400, Tom Lane wrote: > This patch is so wrong that it's scary. You can't have > ImmediateInterruptOK true over the duration of any significant amount of > backend processing --- as an example, if you take control away in the > middle of a malloc call, you'll probably be left with a corrupt malloc > arena. > Thank you for the explanation. My initial thinking was that either DoingCommandRead would protect us (for SIGINT to the backend), or we were going to terminate the process anyway (for SIGTERM). But it sounds like it leaves us in a state so unsafe that we can't even abort the transaction nicely. Regards, Jeff Davis -- 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] possible bug not in open items
Jeff Davis writes: > Thank you for the explanation. My initial thinking was that either > DoingCommandRead would protect us (for SIGINT to the backend), or we > were going to terminate the process anyway (for SIGTERM). But it sounds > like it leaves us in a state so unsafe that we can't even abort the > transaction nicely. Well, we could presumably do exit(1) regardless. But if the idea is to have a clean shutdown, you have to get through proc_exit(), and that requires essentially all the backend subsystems to be alive and undamaged. 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
Peter Eisentraut [2009-04-10 22:46 +0300]: > This whole debate hinges on the argument that encryption without > anti-spoofing > is *not* useful. I don't disagree, but it is not *worse* than having no encryption at all. The reason why Debian/Ubuntu install a snakeoil SSL certificate and configure all packages to use it by default is not because we think that this default configuration is "secure" in any way. The reason is that configuring it that way is that it becomes darn easy to make your entire server with all daemons such as postgresql, postfix, dovecot, etc. trusted by simply replacing that central certificate. You can still configure individual services to use a different one. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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 writes: > The reason why Debian/Ubuntu install a snakeoil SSL certificate and > configure all packages to use it by default is not because we think > that this default configuration is "secure" in any way. The reason is > that configuring it that way is that it becomes darn easy to make your > entire server with all daemons such as postgresql, postfix, dovecot, > etc. trusted by simply replacing that central certificate. You can > still configure individual services to use a different one. This seems a bit handwavy --- there's a difference between the machine's own cert and what it thinks is a root cert. How do you deal with that? If the root cert is real, how do you put in self-signed server 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
[BUGS] BUG #4755: lost graphical relationship between tables in DbVis w/ new PG release
The following bug has been logged online: Bug reference: 4755 Logged by: Ellen Strnod Email address: estr...@annealsoft.com PostgreSQL version: 8.3.7 Operating system: OS X 10.4.11 Description:lost graphical relationship between tables in DbVis w/ new PG release Details: I don't know for sure where the problem lies but as all other things are equal, and this worked in PostgreSQL 8.0.3, I suspect it is an issue with the newer PostgreSQL version I have downloaded (8.3.7) The JDBC driver configured in my installation of DBVisualizer 6.5.5 being used to connect to both versions of the PG database is postgresql-8.3-604.jdbc3.jar. This is the DDL for two related tables: CREATE TABLE wine_variety ( id INTEGER NOT NULL, name CHARACTER VARYING(50) NOT NULL, PRIMARY KEY (id) ); CREATE TABLE wine_tasting ( brand CHARACTER VARYING(50) NOT NULL, variety_id INTEGER NOT NULL, region CHARACTER VARYING(50), YEAR INTEGER, description CHARACTER VARYING(500), store_rating INTEGER, my_rating INTEGER, id INTEGER NOT NULL, PRIMARY KEY (id), CONSTRAINT wine_tasting_fk1 FOREIGN KEY (variety_id) REFERENCES wine_variety (id) ); When I select the wine-tasting table in DBVisualizer for the PostgreSQL 8.0.3 db and select the "References" tab, it correctly shows both tables in the diagram, with a relationship line from wine-tasting to wine-variety (labeled wine_tasting_fk1). When I view it in the PostgreSQL 8.3.7 db, it shows only the wine-tasting table in the diagram. The foreign key constraint is in effect in the new db, if I test by adding a record with an invalid foreign key, so I suspect the information is coming from another attribute - some metadata perhaps? -- 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 [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. 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). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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 [2009-04-10 19:14 +0200]: > It's "secure by default". Without it, most people will *never* get > protected by verifying the certificate because they will not manually > copy root certificates there. The problem and fallacy with security is that if you make it too tight, people will just disable it. I'd be the happiest man on the world if the internet would stop using bad SSL certificates, and all those browsers which try to educate the users about exceptions could just refuse the site and do nothing. But unfortunately the world doesn't work that way. Similarly, my concern is that people would rather disable SSL than trying to get all their db users to put a certificate into their home directory (t least this should be configurable at the system-wide level, like checking whether a cert in /etc/ssl/certs/* matches; or making this more flexible to configure the default on a system level at least.) So the nice thing about a warning is that it will stay around and nag people, instead of dragging them into a kneejerk reaction to "fix" their systems which suddenly got "broken". But thanks to everyone for chiming in. Initially I thought it was just a subtle regression. Since it doesn't seem to be, I'll just adapt my test suite if this is going to stay like it is right now. I'm still concerned about the potential confusion, though. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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 [2009-04-10 19:01 -0400]: > This seems a bit handwavy --- there's a difference between the machine's > own cert and what it thinks is a root cert. Sure. > How do you deal with that? If the root cert is real, how do you put > in self-signed server certs? I'm afraid I don't understand. If an admin replaces the default snakeoil cert with a real one which he got signed by a CA, then of course he would replace the standard system SSL cert (which all the servers default to, and which is initially the snakeoil one) with the "good" certificate. I don't see a reason why an admin would replace a self-signed cert with another self-signed cert? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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 #4755: lost graphical relationship between tables in DbVis w/ new PG release
Ellen Strnod escreveu: The foreign key constraint is in effect in the new db, if I test by adding a record with an invalid foreign key, so I suspect the information is coming from another attribute - some metadata perhaps? This is not a PostgreSQL bug. Blame DBVisualizer guys, not us. -- Euler Taveira de Oliveira http://www.timbira.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] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Martin Pitt writes: > Tom Lane [2009-04-10 19:01 -0400]: >> How do you deal with that? If the root cert is real, how do you put >> in self-signed server certs? > I'm afraid I don't understand. If an admin replaces the default > snakeoil cert with a real one which he got signed by a CA, then of > course he would replace the standard system SSL cert (which all the > servers default to, and which is initially the snakeoil one) with the > "good" certificate. I don't see a reason why an admin would replace a > self-signed cert with another self-signed cert? What I'm wondering about, given your emphasis on system-wide certs, is how you deal with the fact that some apps (like web browsers) are going to need a "real" root certificate, but you also want to have a self-signed certificate that isn't traceable to the real root. This may just indicate my ignorance of standard SSL operating procedures ... 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
* Peter Eisentraut (pete...@gmx.net) wrote: > On Friday 10 April 2009 21:32:29 Stephen Frost wrote: > > A properly configured server could cause a failure too unless the client > > is *also* properly configured. Sure, it's good for people to do. No, I > > don't think we should break things if people don't build out a whole PKI > > for PG and configure all their certs correctly. It's pie-in-the-sky to > > think everyone will do that, and in the end most will just say "SSL > > breaks stuff, so we'll disable it" which certainly isn't better. > > That's debatable. I think it's better. I don't see it as debatable at all, but let's turn it around. If the client hasn't been configured with a root cert to check against, it will *always* fail. That's the *default*. Web browsers, on the other hand, are configured with a whole slew of root CAs, many of which are questionable at best. > > > But it's a default, so the user can change it. > > > > It should be the default to connect, maybe with a warning. > > If you connect with a warning, you have possibly already given up sensitive > information. That's no good. The same is true for the non-SSL case, except there also won't be encryption. Again, when SSL starts to break things for people, they'll disable it. I really don't see much value in trying to save the people who are configuring their passwords into files on disk either. What do you think they're going to do? > > Uh, no, the right fix is to have a warning/prompt (as pretty much all > > web browsers today do) but then continue to connect. > > Yes, this was under discussion a while ago but no one wanted to implement it. That's understandable, I'm not a fan of implementing something like this in a library either. > > Also, the > > web-browser analogy completely falls apart when you consider that the > > use case is significantly different (how many times have you connected > > to a PG server that you didn't know?). > > This is a fuzzy argument. What do you mean by "know", and how do you verify > what you "know" and whether what you "know" is correct? And why are you > using > SSL at all if you think you "know" everything? Because SSL offers *encryption*, which is honestly what it's primairly useful for out on the interwebs. And by 'know', what I'm referring to primairly is the server's DNS being controlled by someone you know/trust, and close enough to not be an issue. Perhaps put another way, I've never even heard of someone trying to spoof a PG server because people simply don't make them generally available to the world, with good reason. Breaking support for getting encryption by default just isn't justified. We could disable non-SSL by default too because it'd be a more secure default, but does that make sense? PKI is something that takes real effort to put together and make work. The web browser situation is about the worst possible implementation you can have and is only questionably better than just having encryption. People who care will take the effort to set it up correctly and use it. Of course, people who care will gripe up and down that we don't have support for client-certificate based authentication. I spend a fair bit of effort setting up and using a Kerberos-based infrastructure to deal with authentication (client and server). I'd like clients to not break by default if I havn't also got a PKI set up and configured on all the clients because it's overkill. All I really need or want SSL in PG for is encryption. The same is going to be true for anyone who sets up PG with Kerberos/GSSAPI/SSPI (uh, Windows Active Directory, that rather popular system out there). Perhaps that can be solved by using Kerberos encryption, but I don't think we've implemented that yet (Magnus?). Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
* Peter Eisentraut (pete...@gmx.net) wrote: > The new firefox just says "invalid certificate" and nothing else, and then > somewhere below there is a small link to "Add an exception" and you need a > total of four clicks to proceed. So that looks a lot like that they are > moving away from easily allowing unverifyable server certificates as well. Yes, it's extremely obnoxious and hasn't actually changed anything. We often use certificates at work for internal web sites that aren't signed by the santified CAs simply because it's not worth it. That causes problems for our users when they're going to sites that are about a billion times less likely to have been cracked into than Joe's crab shop out on the internet. Encouraging people to believe that the PKI that's currently being used for the web is actually meaningful is really the first mistake. Stephen signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Stephen Frost wrote: * Peter Eisentraut (pete...@gmx.net) wrote: The new firefox just says "invalid certificate" and nothing else, and then somewhere below there is a small link to "Add an exception" and you need a total of four clicks to proceed. So that looks a lot like that they are moving away from easily allowing unverifyable server certificates as well. Yes, it's extremely obnoxious and hasn't actually changed anything. We often use certificates at work for internal web sites that aren't signed by the santified CAs simply because it's not worth it. That causes problems for our users when they're going to sites that are about a billion times less likely to have been cracked into than Joe's crab shop out on the internet. Encouraging people to believe that the PKI that's currently being used for the web is actually meaningful is really the first mistake. for self-signed certs, you first create a rootca, you can import the rootca public key/cert to your browser, by offering it as the proper mime type (I forget the specifics), once accepted into your browser, the browser will trust any certs created off that root, same as if they are signed by any of the 'commercial' CAs..of course, if you do this, you need to keep your rootca private keys safe. -- 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
John R Pierce wrote: for self-signed certs, you first create a rootca, you can import the rootca public key/cert to your browser, by offering it as the proper mime type (I forget the specifics), once accepted into your browser, the browser will trust any certs created off that root, same as if they are signed by any of the 'commercial' CAs..of course, if you do this, you need to keep your rootca private keys safe. ok, I found my notes on this... you put your root-certificate.crt on a webserver, and offer it via a link with mime-type application/x-x509-ca-cert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
