On Fri, Jan 17, 2020 at 03:09:53PM +0100, Tim Düsterhus wrote:
> Elliot,
>
> Am 17.01.20 um 14:57 schrieb Elliot Otchet:
> > Thanks again. Update provided: - Fixes the issue Tim points out by using
> > strcmp. - Corrects the argument spacing - Updates to include my name in the
> > patch
Elliot,
Am 17.01.20 um 14:57 schrieb Elliot Otchet:
> Thanks again. Update provided: - Fixes the issue Tim points out by using
> strcmp. - Corrects the argument spacing - Updates to include my name in the
> patch submission. Yes, you can use my name.
You missed on the commit message
Tim, Willy,
Thanks again. Update provided: - Fixes the issue Tim points out by using
strcmp. - Corrects the argument spacing - Updates to include my name in the
patch submission. Yes, you can use my name.
Thanks!
-Elliot
On Friday, January 17, 2020, 5:58:43 AM EST, Willy Tarreau
wrote:
On Fri, Jan 17, 2020 at 11:45:17AM +0100, Tim Düsterhus wrote:
> I did not test, but if I am not mistaken this would allow "rfc2253XXX"
> as the format parameter, no? Meaning: It allows one to append arbitrary
> garbage to the rfc2253 value.
> Judging from `smp_check_const_bool` in sample.c a
Elliot,
Am 17.01.20 um 05:35 schrieb Elliot Otchet:
> An updated patch for your consideration. Let me know what you think.
>
I have some very minor suggestions:
> Subject: [PATCH] MEDIUM: ssl: Add support for returning the dn samples from
> ssl_(c|f)_(i|s)_dn in LDAP v3 (RFC2253) format.
>
Great feedback guys. Thank you.
I think I've incorporated all of it including
WIlly's requests for:- A better commit message- Fixing the unnecessary edits
(spaces vs tabs)- strcomp instead of strcasecmp
Tim's request for: - Correcting the documentation bracket bugs - Fixing the
typo I
Elliot,
Am 15.01.20 um 14:24 schrieb Elliot Otchet:
> As always, feedback is greatly appreciated. If acceptable, what are the next
> steps to get this accepted?
I have a few more suggestions on top of the ones from Willy:
> @@ -15246,7 +15246,7 @@ ssl_c_err : integer
>to your SSL
Hi Elliot,
On Wed, Jan 15, 2020 at 01:24:33PM +, Elliot Otchet wrote:
> Willy,
> The patch attached implements as close to your intent as I could get without
> making changes outside of ssl_sock.c.
> If you remember, you had asked for a patch that implemented extending the
> current
Willy,
The patch attached implements as close to your intent as I could get without
making changes outside of ssl_sock.c.
If you remember, you had asked for a patch that implemented extending the
current methods with a third option to indicate the DN output should be in RFC
2253 e.g.
Willy,
Thanks for the note back. Your suggestion seems like a good approach. I'll
submit a new patch when I have this worked up and tested for a bit.
Regards,
Elliot
On Thursday, January 9, 2020, 12:42:36 AM EST, Willy Tarreau
wrote:
Hi Elliot & Chris,
On Sun, Jan 05, 2020 at
Hi Elliot & Chris,
On Sun, Jan 05, 2020 at 09:09:18PM +, Elliot Otchet wrote:
> Hi,
> An updated patch is attached for the implementation that adds documentation
> to the doc/configuration.txt and fixes an issue identified during testing.
> I couldn't locate tests for the preexisting
Hi,
An updated patch is attached for the implementation that adds documentation to
the doc/configuration.txt and fixes an issue identified during testing.
I couldn't locate tests for the preexisting ssl_c_s_dn and related parameters.
I'd be happy to add tests for the new ones if someone could
Hi Chris.
I can't verify the c code. I just ask to add a documentation to the patch. Can
the sample be tested with vtest?
It would be nice to mention that rfc2253 is LDAP v3. :-)
Regards
Aleks.
Jan 2, 2020 3:41:35 PM Chris Software :
> Hello haproxy,
> My team member has completed a patch
Hello haproxy,
My team member has completed a patch which allows someone to* configure* the
format of the proxied certificate's DN and Issuer DN.
I have attached the patch here. How can we submit this for inclusion to
haproxy?
Chris
On Fri, Dec 20, 2019 at 12:53 PM Chris Software
wrote:
>
Hello,
This is an update on the offchance that some diligent team member is
spinning their wheels on this.
Some team members of mine are modifying the haproxy ssl.c file to make the
format of the ssl_c_s_dn variable configurable, and editing for simplicity
to use standard openssl function
I am running haproxy in an Alpine Docker container. It is doing SSL
termination for https and injecting the client DN into the X-ForwardedFor
HTTP Header. But the format it uses for the client DN is not one that my
application supports.
Can I change the format somehow, perhaps using openssl.cnf?
16 matches
Mail list logo