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
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 pgs
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] ERRO
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 s
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:
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 i
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 tra
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;
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 th
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 stric
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 con
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
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):
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 (aft
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 w
* 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 s
* 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
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
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 tha
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
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 configu
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 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
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
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 an
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 a
[ 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.
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
yo
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
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
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
configur
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 mak
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
Detai
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 woul
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
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. I
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.
--
Eu
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
>
* 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 peo
* 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 easi
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
mov
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
42 matches
Mail list logo
