| 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: | Whole Thread | Raw Message | 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 |