On Fri, Jan 5, 2018 at 7:12 AM, Tom Lane wrote:
> so this is looking mighty like a crashed and burned patch from here :-(
Sorry for arriving late to the party, timezone and such..
The lack of access to the signature algorithm type is being covered by
this commit from upstream which introduced X5
Peter Eisentraut writes:
> On 1/4/18 16:17, Tom Lane wrote:
>> dromedary is whinging about OBJ_find_sigid_algs, as well.
> Yeah, it seems like we might need to fine-tune this a bit more to make
> it work across all OpenSSL versions. I'm going to let the buildfarm
> take a run through the current
On 1/4/18 16:17, Tom Lane wrote:
> Peter Eisentraut writes:
>> Some hosts don't seem to have X509_get_signature_nid(). Looking into
>> that ...
>
> dromedary is whinging about OBJ_find_sigid_algs, as well.
Yeah, it seems like we might need to fine-tune this a bit more to make
it work across all
Peter Eisentraut writes:
> Some hosts don't seem to have X509_get_signature_nid(). Looking into
> that ...
dromedary is whinging about OBJ_find_sigid_algs, as well.
regards, tom lane
On 1/4/18 15:41, Peter Eisentraut wrote:
> On 12/28/17 02:19, Michael Paquier wrote:
>> On Wed, Dec 27, 2017 at 09:27:40AM +0900, Michael Paquier wrote:
>>> On Tue, Dec 26, 2017 at 03:28:09PM -0500, Peter Eisentraut wrote:
On 12/22/17 03:10, Michael Paquier wrote:
> Second thoughts on 0002
On 12/28/17 02:19, Michael Paquier wrote:
> On Wed, Dec 27, 2017 at 09:27:40AM +0900, Michael Paquier wrote:
>> On Tue, Dec 26, 2017 at 03:28:09PM -0500, Peter Eisentraut wrote:
>>> On 12/22/17 03:10, Michael Paquier wrote:
Second thoughts on 0002 as there is actually no need to move around
>>
On Wed, Dec 27, 2017 at 09:27:40AM +0900, Michael Paquier wrote:
> On Tue, Dec 26, 2017 at 03:28:09PM -0500, Peter Eisentraut wrote:
>> On 12/22/17 03:10, Michael Paquier wrote:
>>> Second thoughts on 0002 as there is actually no need to move around
>>> errorMessage if the PGconn* pointer is saved
On Tue, Dec 26, 2017 at 03:28:09PM -0500, Peter Eisentraut wrote:
> On 12/22/17 03:10, Michael Paquier wrote:
> > Second thoughts on 0002 as there is actually no need to move around
> > errorMessage if the PGconn* pointer is saved in the SCRAM status data
> > as both are linked. The attached simpli
On 12/22/17 03:10, Michael Paquier wrote:
> On Fri, Dec 22, 2017 at 11:59 AM, Michael Paquier
> wrote:
>> I have looked at how things could be done in symmetry for both the frontend
>> and backend code, and I have produced the attached patch 0002, which
>> can be applied on top of 0001 implementin
On Fri, Dec 22, 2017 at 11:59 AM, Michael Paquier
wrote:
> I have looked at how things could be done in symmetry for both the frontend
> and backend code, and I have produced the attached patch 0002, which
> can be applied on top of 0001 implementing tls-server-end-point. This
> simplifies the int
On Wed, Dec 20, 2017 at 09:35:55AM +0900, Michael Paquier wrote:
> However, it is possible to simply optimize the frontend code as in
> pg_SASL_init() we already know the channel binding type selected when
> calling pgtls_get_finished() and pgtls_get_peer_certificate_hash(). So
> while I agree with
On Wed, Dec 20, 2017 at 1:19 AM, Peter Eisentraut
wrote:
> I have committed 0001 and 0002 (renaming to scram_channel_binding).
Thanks!
> The 0003 patch looks mostly fine as well. The only concern I have is
> that the way it is set up now, we make the server compute the channel
> binding data fo
On 11/30/17 21:11, Michael Paquier wrote:
> OK, here is a reworked version with the following changes:
> - renamed saslchannelbinding to scramchannelbinding, with a default
> set to tls-unique.
> - An empty value of scramchannelbinding allows client to not use
> channel binding, or in short use use
On Wed, Nov 29, 2017 at 7:42 AM, Peter Eisentraut
wrote:
> On 11/28/17 17:33, Michael Paquier wrote:
>> 1) Have a special value in the parameter saslchannelbinding proposed
>> in patch 0001. For example by specifying "none" then no channel
>> binding is used.
>
> I was thinking if it's empty then
On 11/28/17 17:33, Michael Paquier wrote:
> 1) Have a special value in the parameter saslchannelbinding proposed
> in patch 0001. For example by specifying "none" then no channel
> binding is used.
I was thinking if it's empty then don't use channel binding. Right now,
empty means the same thing
On Wed, Nov 29, 2017 at 7:08 AM, Michael Paquier
wrote:
> On Wed, Nov 29, 2017 at 2:41 AM, Robert Haas wrote:
>> On Tue, Nov 28, 2017 at 11:10 AM, Peter Eisentraut
>> wrote:
>>> I also wonder whether there should be a mechanism to turn off channel
>>> binding from the client. Right now, there i
On Wed, Nov 29, 2017 at 2:41 AM, Robert Haas wrote:
> On Tue, Nov 28, 2017 at 11:10 AM, Peter Eisentraut
> wrote:
>> I also wonder whether there should be a mechanism to turn off channel
>> binding from the client. Right now, there is no way to test the
>> non-PLUS mechanism in an SSL build.
>
>
On Tue, Nov 28, 2017 at 11:10 AM, Peter Eisentraut
wrote:
> I also wonder whether there should be a mechanism to turn off channel
> binding from the client. Right now, there is no way to test the
> non-PLUS mechanism in an SSL build.
I think that would be a good thing to have.
--
Robert Haas
E
On 11/26/17 06:59, Michael Paquier wrote:
> On Tue, Nov 21, 2017 at 1:36 PM, Michael Paquier
> wrote:
>> So attached are rebased patches:
>> - 0001 to introduce the connection parameter saslchannelbinding, which
>> allows libpq to enforce the type of channel binding used during an
>> exchange.
>>
On Tue, Nov 21, 2017 at 1:36 PM, Michael Paquier
wrote:
> So attached are rebased patches:
> - 0001 to introduce the connection parameter saslchannelbinding, which
> allows libpq to enforce the type of channel binding used during an
> exchange.
> - 0002 to add tls-endpoint as channel binding type,
On Sun, Nov 19, 2017 at 8:13 AM, Michael Paquier
wrote:
> On Sun, Nov 19, 2017 at 12:56 AM, Peter Eisentraut
> wrote:
>> I'll be off for a week, so perhaps by that time you could make a rebased
>> version of the rest? I'm not sure how much more time I'll have, so
>> maybe it will end up being mo
On Sun, Nov 19, 2017 at 12:56 AM, Peter Eisentraut
wrote:
> On 11/18/17 06:32, Michael Paquier wrote:
>> + cbind_header_len = 4 + strlen(state->channel_binding_type); /*
>> p=type,, */
>> + cbind_input_len = cbind_header_len + cbind_data_len;
>> + cbind_input = malloc(cbind_input
On 11/18/17 06:32, Michael Paquier wrote:
> Here are some comments.
>
> +* The client requires channel biding. Channel binding type
> s/biding/binding/.
fixed
> if (!state->ssl_in_use)
> + /*
> +* Without SSL, we don't support ch
On Sat, Nov 18, 2017 at 4:31 AM, Peter Eisentraut
wrote:
> I made some significant changes to the logic.
Thanks!
> The selection of the channel binding flag (n/y/p) in the client seemed
> wrong. Your code treated 'y' as an error, but I think that is a
> legitimate case, for example a PG11 clien
On 11/16/17 16:50, Michael Paquier wrote:
> On Thu, Nov 16, 2017 at 10:47 PM, Peter Eisentraut
> wrote:
>> Pushed 0001, will continue with 0002.
>
> Thanks!
I have combed through the 0002 patch in detail now. I have attached my
result.
I cleaned up a bunch of variable names to be more precise.
On Thu, Nov 16, 2017 at 10:47 PM, Peter Eisentraut
wrote:
> Pushed 0001, will continue with 0002.
Thanks!
--
Michael
On 11/14/17 03:55, Michael Paquier wrote:
> On Tue, Oct 10, 2017 at 10:12 PM, Michael Paquier
> wrote:
>> Attached is a new patch set with the comments from above. On top of
>> that, I have changed a couple of things:
>> - 0001 is unchanged, still the same refactoring for the SSL tests.
>> - 0002
On Tue, Oct 10, 2017 at 10:12 PM, Michael Paquier
wrote:
> Attached is a new patch set with the comments from above. On top of
> that, I have changed a couple of things:
> - 0001 is unchanged, still the same refactoring for the SSL tests.
> - 0002 implements tls-unique, now including tests using t
28 matches
Mail list logo
