On Wed, Apr 29, 2020 at 10:33:26PM +0200, Peter Eisentraut wrote:
> This looks good to me, except that
>
> xreflabel="ssl-min-protocol-version"
>
> etc. needs to be changed to use underscores.
Indeed, thanks. I have fixed this part and applied the patch.
--
Michael
signature.asc
Description:
On 2020-04-27 07:45, Michael Paquier wrote:
On Sun, Apr 26, 2020 at 11:20:01PM +0200, Daniel Gustafsson wrote:
That was the preferred name by Michael too elsewhere in the thread, so went
ahead and made it so.
Thanks Daniel.
I would, however, prefer to also rename the internal symbols.
On Sun, Apr 26, 2020 at 11:20:01PM +0200, Daniel Gustafsson wrote:
> That was the preferred name by Michael too elsewhere in the thread, so went
> ahead and made it so.
Thanks Daniel.
>> I would, however, prefer to also rename the internal symbols.
>
> Done in the attached v2.
What you have
> On 26 Apr 2020, at 14:01, Peter Eisentraut
> wrote:
>
> On 2020-04-24 14:03, Daniel Gustafsson wrote:
>>> On 24 Apr 2020, at 12:56, Peter Eisentraut
>>> wrote:
>>>
>>> Can we reconsider whether we really want to name the new settings like
>>> "sslminprotocolversion", or whether we could
On 2020-04-24 14:03, Daniel Gustafsson wrote:
On 24 Apr 2020, at 12:56, Peter Eisentraut
wrote:
Can we reconsider whether we really want to name the new settings like
"sslminprotocolversion", or whether we could add some underscores, both for
readability and for consistency with the
On Fri, Apr 24, 2020 at 02:03:04PM +0200, Daniel Gustafsson wrote:
> That was brought up by Michael in the thread, but none of us followed up on it
> it seems. The current name was chosen to be consistent with the already
> existing ssl* client-side settings, but I don't really have strong
> On 24 Apr 2020, at 12:56, Peter Eisentraut
> wrote:
>
> Can we reconsider whether we really want to name the new settings like
> "sslminprotocolversion", or whether we could add some underscores, both for
> readability and for consistency with the server-side options?
That was brought up
Can we reconsider whether we really want to name the new settings like
"sslminprotocolversion", or whether we could add some underscores, both
for readability and for consistency with the server-side options?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development,
On Tue, Jan 28, 2020 at 11:29:39AM +0100, Daniel Gustafsson wrote:
> You don't really qualify as the target audience for basic, yet not always
> universally known/understood, sections in the documentation though =)
Likely I don't.
> I've heard enough complaints that it's complicated to set up
> On 28 Jan 2020, at 04:53, Michael Paquier wrote:
> Now, we already mention in the docs which values the min and max
> bounds support, and that the version of OpenSSL used by the backend
> and the frontend are impacted by that depending on what version of
> OpenSSL one or the other link to.
On Mon, Jan 27, 2020 at 09:49:09AM +0100, Daniel Gustafsson wrote:
>> On 27 Jan 2020, at 07:01, Michael Paquier wrote:
> Ok. I prefer to keep the TLS code collected in fe-secure.c, but I don't have
> strong enough opinions to kick up a fuzz.
They are parameter-related, so fe-connect.c made the
> On 27 Jan 2020, at 07:01, Michael Paquier wrote:
>
> On Fri, Jan 24, 2020 at 12:19:31PM +0100, Daniel Gustafsson wrote:
>> Attached is a v5 of the patch which hopefully address all the comments
>> raised,
>> sorry for the delay.
>
> Thanks for the new version.
Thanks for review and hackery!
On Fri, Jan 24, 2020 at 12:19:31PM +0100, Daniel Gustafsson wrote:
> Attached is a v5 of the patch which hopefully address all the comments raised,
> sorry for the delay.
Thanks for the new version.
psql: error: could not connect to server: invalid or unsupported
maximum protocol version
> On 17 Jan 2020, at 03:38, Michael Paquier wrote:
>
> On Fri, Jan 17, 2020 at 10:09:54AM +0900, Michael Paquier wrote:
>> Could you please rebase and fix the remaining pieces of the patch?
>
> And while I remember, you may want to add checks for incorrect bounds
> when validating the values in
On Fri, Jan 17, 2020 at 10:09:54AM +0900, Michael Paquier wrote:
> Could you please rebase and fix the remaining pieces of the patch?
And while I remember, you may want to add checks for incorrect bounds
when validating the values in fe-connect.c... The same arguments as
for the backend part
On Thu, Jan 16, 2020 at 09:56:01AM +0100, Daniel Gustafsson wrote:
> The patch looks fine to me, I don't an issue with splitting it into a
> refactoring patch and a TLS min/max version patch.
Thanks, committed the refactoring part then. If the buildfarm breaks
for a reason or another, the window
> On 16 Jan 2020, at 04:22, Michael Paquier wrote:
>
> On Wed, Jan 15, 2020 at 02:58:09PM +0900, Michael Paquier wrote:
>> On Tue, Jan 14, 2020 at 11:01:00PM +0100, Daniel Gustafsson wrote:
>>> Files renamed to match existing naming convention, the rest of the patch
>>> left
>>> unchanged.
>>
On Wed, Jan 15, 2020 at 02:58:09PM +0900, Michael Paquier wrote:
> On Tue, Jan 14, 2020 at 11:01:00PM +0100, Daniel Gustafsson wrote:
>> Files renamed to match existing naming convention, the rest of the patch left
>> unchanged.
>
> [previous review]
One thing I remembered after sleeping on it is
On Tue, Jan 14, 2020 at 11:01:00PM +0100, Daniel Gustafsson wrote:
> Files renamed to match existing naming convention, the rest of the patch left
> unchanged.
+ if ((pg_strcasecmp("tlsv1", protocol) == 0) || pg_strcasecmp("tlsv1.0",
protocol) == 0)
+ return TLS1_VERSION;
"TLSv1.0" is
> On 14 Jan 2020, at 16:15, Daniel Gustafsson wrote:
>
>> On 14 Jan 2020, at 15:49, Tom Lane wrote:
>>
>> Daniel Gustafsson writes:
> On 11 Jan 2020, at 03:49, Michael Paquier wrote:
> One thing I noticed when looking at it is that we now have sha2_openssl.c
> and
>
> On 14 Jan 2020, at 15:49, Tom Lane wrote:
>
> Daniel Gustafsson writes:
On 11 Jan 2020, at 03:49, Michael Paquier wrote:
One thing I noticed when looking at it is that we now have sha2_openssl.c
and
openssl_protocol.c in src/common. For easier visual grouping of OpenSSL
Daniel Gustafsson writes:
>> On 11 Jan 2020, at 03:49, Michael Paquier wrote:
>>> One thing I noticed when looking at it is that we now have sha2_openssl.c
>>> and
>>> openssl_protocol.c in src/common. For easier visual grouping of OpenSSL
>>> functionality, it makes sense to me to rename
> On 11 Jan 2020, at 03:49, Michael Paquier wrote:
> Heuh. It would be perfect to rely only on OpenSSL for that part
> to bring some sanity, and compare the results fetched from the SSL
> context so as we don't have to worry about special cases in with the
> GUC reload if the parameter is
On Fri, Jan 10, 2020 at 12:01:36AM +0100, Daniel Gustafsson wrote:
> I looked into this and it turns out that OpenSSL does nothing to prevent the
> caller from setting a nonsensical protocol range like min=tlsv1.3,max=tlsv1.1.
> Thus, it's quite easy to screw up the backend server config and get
Thanks for review everyone! A v2 of the patch which I believe addresses all
concerns raised is attached.
> On 6 Jan 2020, at 07:01, Michael Paquier wrote:
>
> On Thu, Jan 02, 2020 at 09:46:44PM +, cary huang wrote:
>> I agree with Arthur that it makes sense to check the validity of
>>
On Mon, Jan 06, 2020 at 09:37:54AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
>> Not having thought about it in much detail, but it's a fairly common
>> scenario to have a much newer version of libpq (and the platform it's
>> built on) than the server. E.g. a v12 libpq against a v9.6
Magnus Hagander writes:
> Not having thought about it in much detail, but it's a fairly common
> scenario to have a much newer version of libpq (and the platform it's
> built on) than the server. E.g. a v12 libpq against a v9.6 postgres
> server is very common. For example, debian based systems
On Mon, Jan 6, 2020 at 7:02 AM Michael Paquier wrote:
>
> On Thu, Jan 02, 2020 at 09:46:44PM +, cary huang wrote:
> > I agree with Arthur that it makes sense to check the validity of
> > "conn->sslmaxprotocolversion" first before checking if it is larger
> > than "conn->sslminprotocolversion"
On Thu, Jan 02, 2020 at 09:46:44PM +, cary huang wrote:
> I agree with Arthur that it makes sense to check the validity of
> "conn->sslmaxprotocolversion" first before checking if it is larger
> than "conn->sslminprotocolversion"
Here I don't agree. Why not just let OpenSSL handle things
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Hello
I have applied the patch and did some basic testing with
Hello,
On 2019/12/04 2:37, Daniel Gustafsson wrote:
The attached patch implements two new connection string variables for minimum
and maximum TLS protocol version, mimicking how it's done in the backend. This
does duplicate a bit of code from be-secure-openssl.c to cope with older
versions of
Responding to the recent thread on bumping the default TLS version, I realized
that we don't have a way to set the minimum/maximum TLS protocol version in
clientside libpq. Setting the maximum protocol version obviously not terribly
important (possibly with the exception of misbehaving
32 matches
Mail list logo
