> On Oct 15, 2018, at 10:20 AM, Stefan Eissing <[email protected]>
> wrote:
>
>
>
>> Am 15.10.2018 um 16:11 schrieb Jim Jagielski <[email protected]>:
>>
>> 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.
>
> Huh? I was referring to "TLS 1.3 support isn't quite yet tested enough to
> warrant a public release". I wanted to point out that without attempting a
> public release, we may not have found this bug for months
Agreed.
> . I am -1 on 2.4.36 as well, in case that was not clear. Don't know how this
> "veto" came into this...
It wasn't directed at anyone, just a general statement...
>
> -Stefan
>
>>> On Oct 15, 2018, at 10:07 AM, Stefan Eissing <[email protected]>
>>> wrote:
>>>
>>>
>>>
>>>> Am 15.10.2018 um 15:58 schrieb Jim Jagielski <[email protected]>:
>>>>
>>>> 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
>>>>> <[email protected]> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri <[email protected]>:
>>>>>>
>>>>>> 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"
>>>>>> <[email protected]> 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?
>>>>>>
>>>>>
>>>>
>>>
>>
>
