curl release package is a debug build

[Brian Inglis]

On 2020-11-30 16:59, Brian Inglis wrote:
> On 2020-11-29 20:17, Sara Angel via Cygwin wrote:
>> curl release package being a debug build is causing it to fail on success
>> in some cases.
>>
>> e.g.
>> curl --cacert mycert.pem https://localhost:80
>> curl: (56) OpenSSL SSL_read: Connection closed abruptly, errno 0 (Fatal
>> because this is a curl debug build)
>>
>> The only thing related to this bug I could find is that msys2 had the same
>> issue in their curl package
>> https://github.com/msys2/MSYS2-packages/issues/2223
> 
> Raised issue upstream:
> https://github.com/curl/curl/issues/6266
> 
> and got upstream response pointer to:
> https://github.com/curl/curl/blob/0d75bf9ae99f62ac5aab46cd281fd5a7e0760a69/lib/vtls/openssl.c#L4244-L4259 
> 
> "For debug builds be a little stricter and error on any SSL_ERROR_SYSCALL.
> For example a server may have closed the connection abruptly without a 
> close_notify alert.
> 
> For compatibility with older peers we don't do this by default.
> https://github.com/curl/curl/issues/4624
> 
> We can use this to gauge how many users may be affected, and if it goes ok 
> eventually transition to allow in dev and release with the newest OpenSSL:
> #if (OPENSSL_VERSION_NUMBER >= 0x10101000L)"
> 
> so will disable this in a new Cygwin release which will be uploaded soon.
> 
> *Curl users should be aware that deviations from strict protocol are deprecated 
> and will be reported as errors unconditionally in a near future release.*

Other maintainers think that as this upstream behaviour will likely become the 
default in the next or a near future release, we might as well leave the 
upstream behaviour enabled in the current release. I am now more inclined to go 
along with this approach.

Alternatively we could patch the current Cygwin release to disable this feature 
for only the current release, and ensure the upstream behaviour becomes the 
default in the next release.

What do curl users and developers think should happen?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]