As much as the default behaviour is questionable, I don't fully agree with the assessment: this is in fact a curl documentation problem. As a multi-protocol li

As much as the default behaviour is questionable, I don't fully agree with the assessment: this is in fact a curl documentation problem. As a multi-protocol lib, curl does not in fact implement all of them directly, instead relying on transitive dependencies which act as "backends" to outsource, in most cases, decoding the low-level bits. For some of the protocols, and for good reason, it incorporates support for multiple alternative libraries. The downside of that approach is that it is hard, if not impossible, to ensure common behaviour across independent backends which may not cover all of the same features, provide incomplete APIs, or, such as in this case do not provide a way to patch some of its default behaviour. Libressl is not a bit-for-bit reimplementation of openssl, and are under no obligation to mimic its API fully (however convenient that would be for us all). In such cases, and given the reluctance of upstream to fix it, curl is left with 2 possibilities: drop support for said library, or document the quirk. Given the downside of breaking user code of following the former, it should at least do the latter. All this being said, I do agree with the main sentiment that this is a flawed approach from a security standpoint of libressl, and there's probably reason to open a CVE, but it should be on libressl.