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

[Arran Cudbard-Bell]

> 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.

-Arran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210607/40b03825/attachment.sig>