From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin@cygwin.com
Subject: Re: curl release package is a debug build
Date: Wed, 2 Dec 2020 15:17:59 -0700 [thread overview]
Message-ID: <67598ad8-00c0-c8f2-1f6b-3f6f3bb93a21@SystematicSw.ab.ca> (raw)
In-Reply-To: <a3488e6b-eab1-a667-d9f6-eac4395efa0e@SystematicSw.ab.ca>
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.]
prev parent reply other threads:[~2020-12-02 22:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 3:17 Sara Angel
2020-11-30 23:59 ` Brian Inglis
2020-12-02 22:17 ` Brian Inglis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67598ad8-00c0-c8f2-1f6b-3f6f3bb93a21@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).