What's the rationale behind ssl-trace not being built by default?

[Matt Caswell]

On 08/06/2021 00:09, Arran Cudbard-Bell wrote:
> 
> 
>> On Jun 7, 2021, at 4:57 PM, Matt Caswell <matt at openssl.org> wrote:
>>
>>
>>
>> On 07/06/2021 20:01, Arran Cudbard-Bell wrote:
>>> The tables to convert extension IDs and compression methods to humanly readable names are not available outside ssl/t1_trace.c.
>>> SSL_trace() itself produces reams of helpful information as handshakes progress, and is particularly useful for dealing with encrypted handshakes, where wireshark et al don't provide useful output.
>>> What is the rationale for ssl-trace to be disabled by default?  Was it purely to keep binary sizes down, or was there a security aspect to the decision?
>>
>> Its a really good question and I've often wondered the same thing. The decision was made before my time. I suspect it was about keeping binary sizes down, but I can't imagine it would make that much difference. I have previously considered turning it on by default but never quite got around to it.
> 
> If you don't have any objections I could submit a PR to enable it by default?  I'd image that the platforms that'd care about a few extra kb are in the minority, and it makes such a huge difference having SSL_trace() when trying to debug TLS 1.3 issues.

I have no objections although you'll have to be quick if you want it 
considered for 3.0. Since it would just be about changing the default 
people that care about the extra kb can still disable it.

Matt