From: David Timber Date: Mon, 02 Mar 2026 03:16:40 GMT Subject: [PATCH v2 0/1] send-email: add client certificate options Message-ID: <20260302032048.260209-1-dxdt@dev.snart.me> In-Reply-To: I'm sorry that I missed last week's submission deadline. On 2/21/26 01:35, Junio C Hamano wrote: > Shouldn't there be a word "require" somewhere in the above to > clarify why a user may want to use this option? A server may > optionally verify a certificate only when it is given one, but if it > lets us do what we want without such verification, we do not have > much incentive to give them a certificate. RFC 8446 section 4.3.2: > The client MUST send a Certificate message if and only if the server > has requested client authentication via a CertificateRequest message > (Section 4.3.2). In other words, the client won't send its cert to the server unless requested by the server. So, the client presenting its cert to the server in the client hello from the get-go is in violation of this requirement. I reflected that in the reroll. Also, removed the `$ret{SSL_use_cert} = 1;` line in the code to be in line with the requirement. That line was confusing and unnecessary in the first place. Whether to use a client cert or not should be up to the underlying implementation to decide. Removed the whole PKCS#12 vs PEM debacle in the change as I reckon it's a behaviour that could change overnight without a warning. Feels kind of defensive, but a reasonable change all things considered. Users affected by such library behaviour change can always refer to the manual. David Timber (1): send-email: add client certificate options Documentation/config/sendemail.adoc | 16 ++++++++++ Documentation/git-send-email.adoc | 19 ++++++++++++ git-send-email.perl | 47 ++++++++++++++++++++++------- 3 files changed, 71 insertions(+), 11 deletions(-) -- 2.53.0.1.ga224b40d3f.dirty