On Fri, Mar 10, 2023 at 10:42:08AM +0900, Michael Paquier wrote:
> Perhaps you are right and there is no actual reason to worry here.
I have been thinking about that for the last few days, and yes a
backpatch should be OK, so done now down to 12.
--
Michael
signature.asc
Description: PGP
On Thu, Mar 09, 2023 at 09:51:09AM -0500, Stephen Frost wrote:
> I agree with matching how SSL is handled here and in a review of the
> patch proposed didn't see any issues with it. Seems like it's probably
> something that should also be back-patched and it doesn't look terribly
> risky to do
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Feb 17, 2023 at 09:01:43AM -0800, Jacob Champion wrote:
> > On Thu, Feb 16, 2023 at 10:59 PM Michael Paquier
> > wrote:
> >> I am adding Stephen Frost
> >> in CC to see if he has any comments about all this part of the logic
>
On Fri, Feb 17, 2023 at 09:01:43AM -0800, Jacob Champion wrote:
> On Thu, Feb 16, 2023 at 10:59 PM Michael Paquier wrote:
>> I am adding Stephen Frost
>> in CC to see if he has any comments about all this part of the logic
>> with gssencmode.
>
> Sounds good.
Hearing nothing on this part,
On Thu, Feb 16, 2023 at 10:59 PM Michael Paquier wrote:
> I am adding Stephen Frost
> in CC to see if he has any comments about all this part of the logic
> with gssencmode.
Sounds good.
> I agree that
> PQconnectPoll() has grown beyond the point of making it easy to
> maintain. I am wondering
On Thu, Feb 16, 2023 at 09:59:54AM -0800, Jacob Champion wrote:
> On Thu, Feb 16, 2023 at 3:31 AM Jelte Fennema wrote:
>> Patch looks good to me. Definitely an improvement over the status quo.
>
> Thanks for the review!
I was looking at that a second time, and with fresh eyes I can see
that we
On Thu, Feb 16, 2023 at 3:31 AM Jelte Fennema wrote:
>
> Patch looks good to me. Definitely an improvement over the status quo.
Thanks for the review!
> Looking at the TLS error handling though I see these two lines:
>
> && conn->allow_ssl_try/* redundant? */
> && !conn->wait_ssl_try) /*
Patch looks good to me. Definitely an improvement over the status quo.
Looking at the TLS error handling though I see these two lines:
&& conn->allow_ssl_try/* redundant? */
&& !conn->wait_ssl_try) /* redundant? */
Are they actually redundant like the comment suggests? If so, we
should
Hi all,
During the gssencmode CVE discussion, we noticed that PQconnectPoll()
handles the error cases for TLS and GSS transport encryption slightly
differently. After TLS fails, the connection handle is dead and future
calls to PQconnectPoll() return immediately. But after GSS encryption
fails,
