It's up to the RM on whether or not to release... one can't veto a release and a -1 is not a veto.
> On Oct 15, 2018, at 10:07 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > > > >> Am 15.10.2018 um 15:58 schrieb Jim Jagielski <j...@jagunet.com>: >> >> Considering all this, I am changing my vote from a +1 to a -1. I was not >> able to trigger this error, but this shows, at least IMO, that TLS 1.3 >> support isn't quite yet tested enough to warrant a public release, unless we >> are super clear that it is "experimental" or "early access"... > > I do not see it this black/white way. > > We have found no regression with any SSL != OpenSSL 1.1.1. > We have not even found a bug with TLSv1.3 as such. What we have found is a > behaviour change in OpenSSL where our code relied on either changed or not > well documented behaviour. > > We do not want to ship a version of httpd which has severe interop problems > with the released openssl 1.1.1. > HOWEVER: it is unclear, if this will not also trigger in some scenario when > one links 2.4.35 with OpenSSL 1.1.1. > > I am all in favor of pushing a 2.4.37 immediately after this bug is fixed. We > will not solve any remaining problems by letting it stew in the repository. > > -Stefan > >> >>> On Oct 15, 2018, at 4:06 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> >>> wrote: >>> >>> >>> >>>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri <drugg...@primary.net>: >>>> >>>> Hi, Helmut; >>>> Note that the vote may run longer than 72 hours as 72 is the minimum. As >>>> it stands now, we have more than 3 binding +1 votes, but I am waiting for >>>> closure on the conversation on-list about the tests with reported H2/TLS >>>> 1.3 failures. Since this is one of the primary features of this release, I >>>> want to be sure the topic gets due attention. >>> >>> See my mail on the other thread. It seems that h2 traffic triggers a call >>> sequence that exposes a change in OpenSSL behaviour of SSL_read() between >>> 1.1.0 and 1.1.1. It looks as if mod_ssl interpreted the return codes of >>> SSL_read() in a way that no longer works and that we need to change mod_ssl >>> handling here. >>> >>> Waiting on confirmation or rebuttal of my analysis on the other thread. >>> >>> Cheers, >>> >>> Stefan >>> >>>> -- >>>> Daniel Ruggeri >>>> >>>> On October 14, 2018 4:44:04 PM CDT, "Helmut K. C. Tessarek" >>>> <tessa...@evermeet.cx> wrote: >>>> On 2018-10-10 15:18, Daniel Ruggeri wrote: >>>> Hi, all; >>>> Please find below the proposed release tarball and signatures: >>>> https://dist.apache.org/repos/dist/dev/httpd/ >>>> >>>> I would like to call a VOTE over the next few days to release this >>>> candidate tarball as 2.4.36: >>>> [ ] +1: It's not just good, it's good enough! >>>> [ ] +0: Let's have a talk. >>>> [ ] -1: There's trouble in paradise. Here's what's wrong. >>>> >>>> The computed digests of the tarball up for vote are: >>>> sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz >>>> sha256: ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288 >>>> *httpd-2.4.36.tar.gz >>>> >>>> 72h have passed, so what is the outcome of the vote? >>>> >>> >> >
