From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Question regarding SSL code in backend and frontend |
Date: | 2012-04-05 06:00:49 |
Message-ID: | 20120405.150049.1139277216417686423.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> Those code fragment judges the return value from
>> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
>> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
>> when SSL_ERROR_WANT_READ. It seems they are not consistent. Comments?
>
> There's no particular reason why they should be consistent, I think.
> The assumptions for nonblocking operation are different.
Ok. Thanks.
BTW, usage of SSL_CTX_new() is different among frontend and backend as
well.
fe-secure.c: SSL_context = SSL_CTX_new(TLSv1_method());
be-secure.c: SSL_context = SSL_CTX_new(SSLv23_method());
In my understanding by using SSLV23_method, it is compatible with
SSLv2, SSLv3, and TLSv1 protocol. So it seems there's no particular
reason to use TLSv1_method(). Am I missing something?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2012-04-05 06:02:16 | Re: [PATCH] lock_timeout and common SIGALRM framework |
Previous Message | Tom Lane | 2012-04-05 03:56:59 | Re: pg_upgrade improvements |