Re: Allow ssl_renegotiation_limit in PG 9.5

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Shay Rojansky <roji(at)roji(dot)org>, "Pgsql-hackers(at)postgresql(dot)org" <Pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow ssl_renegotiation_limit in PG 9.5
Date: 2015-10-14 17:39:46
Message-ID: 31677.1444844386@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Andres Freund wrote:
>> On 2015-10-14 14:19:40 -0300, Alvaro Herrera wrote:
>>> I think we could continue to have the parameter except that it throws an
>>> error if you try to set it to something other than 0.

>> That'll make it hard to ever remove it tho.

> What would you recommend then? Forcing the user to specify the version
> before the connection is established is not nice.

Yeah. I thought about telling Shay to set the variable after establishing
the connection, but there's a problem with that: if the user issues RESET
ALL then his setting would go away. (IIRC, settings established in the
connection packet are considered to be what to reset to; but a SET sent
just after connection would not be.)

The only other alternative is to make a second connection attempt if the
first fails, which is pretty messy.

If we think it's legit for npgsql to try to force renegotiation off,
then we have to give pretty serious consideration to putting the variable
back as Alvaro suggests.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2015-10-14 17:40:42 Re: Can extension build own SGML document?
Previous Message Amir Rohan 2015-10-14 17:39:08 Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files