I checked through the rest of the SSL code and caught a few more cases.
The strange part here is that COMMERROR is for cases where the client
might not exist, and obviously you are seeing that. The problem is that
these errors can happen when the client _does_ exist too. Not sure how
to handle
Ok, I think I've gotten this figured out now. I saw this comment in pqcomm.c,
switched the ERROR logs to COMMERROR logs and it all works. I've attached a
patch to be-secure.c that fixes all my problems. Hopefully this is the right fix.
--Nate
/*
* Careful: an elog() that tri
Nathan Mueller wrote:
> Ok, I tested this out with TLSv1 and it worked fine. I found that the
> same mistake was being made on the client side of things too so I
> included a patch for that too.
OK, attached is the patch that I applied. It does strerror() but no
elog(ERROR) on the server side if
I will manually apply this.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Nathan Muell
Ick, my email client wrapped that really weird. That's why the
double strerror is there too -- the first one should be part of the
previous line.
I've found that you can still get the server to crash in the other
error cases or when SSL_read/write returns -1. Since that happens
whenever you try to
OK, I can apply this. One question I have is why the double strerror()
in the first patch chunk. Also, I will need to manually patch this
because your system has formatted the code quite unusually:
> libpq_g-
>
Ok, I tested this out with TLSv1 and it worked fine. I found that the
same mistake was being made on the client side of things too so I
included a patch for that too.
--Nate
Index: src/backend/libpq/be-secure.c
===
RCS file:
> There was a conscious decision in 7.3 to require only 7.3 clients when
> using SSL. I don't remember how many people were involved in that
> discussion, but I know it was made. In fact, there was so much new SSL
> code in 7.3, I suspected we couldn't even make it work with pre-7.2
> clients. I am
I am glad you found out the cause of your problems.
I am reluctant to apply this patch because the original author
recommended TLSv1 specifically because it was more secure, especially
compared to SSLv2.
There was a conscious decision in 7.3 to require only 7.3 clients when
using SSL. I don't
> tested it with openssl 0.9.6e and it worked on BSD/OS 4.2. The author
> is only involved intermittently. I worked with him to get it
> working on
> 7.3. It is certainly possible there are other bugs in there.
Slow night so I learned a little about SSL and figured this out. The
following patch
Nathan Mueller wrote:
> > > In 7.3 if a client exists without disconnecting from the
> > > database the
> > > backend dumps core.
> >
> > I can't reproduce that.
>
> I'm sorry but you're going to have to send me more info about your
> setup. I just did a fresh build on my home machine against Red
> > In 7.3 if a client exists without disconnecting from the
> > database the
> > backend dumps core.
>
> I can't reproduce that.
I'm sorry but you're going to have to send me more info about your
setup. I just did a fresh build on my home machine against Red Hat's
openssl and the problems got eve
> > In 7.3 if a client exists without disconnecting from the
> > database the
> > backend dumps core.
>
> I can't reproduce that.
What version of openssl are you using?
--Nate
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[EMAIL PROTECTED] writes:
> In 7.3 if a client exists without disconnecting from the database the
> backend dumps core.
I can't reproduce that.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at
14 matches
Mail list logo
