On Tue, 7 May 2019 14:16:43 +0100 Dimitri John Ledkov <x...@ubuntu.com> wrote: > Hi, > > On Wed, 10 Apr 2019 15:22:09 +0200 Guilhem Moulin <guil...@debian.org> wrote: > > > > Not setting the SSL_MODE_AUTO_RETRY flag back after removing O_NONBLOCK > > (ie commenting out `Net::SSLeay::set_mode($ssl, $mode_auto_retry);` in > > the patch) solves the problem with blocking I/O and select/poll, but > > breaks programs expecting SSL_read() to block until application data > > comes in. (That is, programs not conforming to SSL_read()'s documented > > behavior — hence which would break on renegotiation with TLS <1.3; or > > programs relying on SSL_MODE_AUTO_RETRY being set, as in OpenSSL ≥1.1.1's > > default context flags.) > > > > This issue concerns me a lot at the moment. I am currently trying to > upgrade OpenSSL from 1.1.0 to 1.1.1 in Ubuntu 18.04 LTS (bionic). And > as far as I understand all the comment on this debian bug report, > current application are potentially broken and brokeness happens more > often with TLSv1.3 and the new OpenSSL 1.1.1 defaults > (SSL_MODE_AUTO_RETRY). > > As far as I understand we do not have a fixed LWP that works correctly > in blocking, non-blocking, tls 1.2 and tls 1.3. To prevent regressing > existing users further, does it make sense for me to make updates in > bionic that: > > 1) limit SSL_new and SSL_CTX_new to TLS v1.2 max > and > 2) disable SSL_MODE_AUTO_RETRY by default for TLS v1.2 connections? > > My goal is to keep existing breakages as is, without introducing new > ones, whilst getting OpenSSL 1.1.1 into bionic. Granted this will not > get TLS v1.3 enabled for perl server/clients without code changes, but > oh well. Those who want it, will be able to force / start using it.
I proposed the following patch upstream / request for comments https://github.com/radiator-software/p5-net-ssleay/pull/139 Regards, Dimitri.
