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

[Matt Caswell]

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.

Matt