You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Daniel Ruggeri <dr...@primary.net> on 2018/10/10 19:18:45 UTC
[VOTE] Release httpd-2.4.36
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
--
Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.36
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Oct 10, 2018 at 02:18:45PM -0500, 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:
> [x] +1: It's not just good, it's good enough!
+1 for release, looks good and passes tests on Fedora 28. Thanks a lot
for RMing again Daniel!
Regards, Joe
Re: [VOTE] Release httpd-2.4.36
Posted by de...@gmail.com,
de...@gmail.com.
+1
FreeBSD 11.2-RELEASE-p4
security/openssl111 - 1.1.1_1
Hosting several live sites without errors or issues on this release candidate.
TLSv1.3 successfully negotiated for capable browsers.
Regards,
Dennis
Re: [VOTE] Release httpd-2.4.36
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
Le 10/10/2018 à 21:18, Daniel Ruggeri a écrit :
> 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:
> [X] +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
>
+1, Good to go for me.
Tested on Ubuntu 18.04, compiled with gcc 8.1.0.
Tested with event, prefork and worker.
Test coverage data from my test environment attached.
However, I have:
t/modules/info.t                 (Wstat: 0 Tests: 1 Failed: 1)
 Failed test: 1
t/security/CVE-2005-3352.t       (Wstat: 0 Tests: 2 Failed: 1)
 Failed test: 2
t/security/CVE-2007-5000.t       (Wstat: 0 Tests: 2 Failed: 1)
 Failed test: 1
All are related to mod_imagemap. It was not activated in my test
environment before, so I don't know how it was previously.
According to the test coverage data, the 'imap_handler' function is
never called!?!?
It is likely a miss configuration in my test environment, but wanted to
report if it rings a bell to someone.
CJ
Re: [VOTE] Release httpd-2.4.36
Posted by Stefan Eissing <st...@greenbytes.de>.
+1
* macOS 10.14.0, XCode 10, OpenSSL 1.0.2: mod_http2, mod_md tests pass
* macOS 10.14.0, XCode 10, OpenSSL 1.1.1: mod_http2, mod_md tests pass
* ubuntu 18.04 LTS, gcc 7.3.0, openssl 1.1.0g: mod_http2 tests pass
> Am 10.10.2018 um 21:18 schrieb Daniel Ruggeri <dr...@primary.net>:
>
> 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
>
> --
> Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.36
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1:
o macOS 10.13.6, Xcode 10, OpenSSL 1.1.1
o CentOS 5&6, OpenSSL 1.0.2, 64bit
Will try to test against CentOS7 and Ubuntu 14.04LTS tomorrow
Thx for RMing!
> On Oct 10, 2018, at 3:18 PM, Daniel Ruggeri <DR...@primary.net> 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
>
> --
> Daniel Ruggeri
Re: t/modules/buffer.t failing in 2.4.36, LWP bug [Was: [VOTE]
Release httpd-2.4.36]
Posted by Ruediger Pluem <rp...@apache.org>.
On 10/14/2018 04:20 PM, Mark Blackman wrote:
>
>
>> On 14 Oct 2018, at 12:33, Rainer Jung <rainer.jung@kippdata.de <ma...@kippdata.de>> wrote:
>>
>> Am 13.10.2018 um 11:46 schrieb Rainer Jung:
>>> Am 11.10.2018 um 20:55 schrieb Ruediger Pluem:
>>>>
>>>>
>>>> On 10/11/2018 08:10 PM, Christophe JAILLET wrote:
>>>>> No issue on my Ubuntu 18.04 VM.
>>>>>
>>>>> On what configuration are you running your tests, Rüdiger? macOS, just like Jim?
>>>>
>>>> Centos 7.5 64 Bit
>>>>
>>>> Regards
>>>>
>>>> Rüdiger
>>> The test fails for me as well for 2.4.36 on SLES12. Small bodies are OK, large not. The limit is somewhere between
>>> 1.3 and 1.5 MB, not always the same. The test hangs there until mod_reqtimeout times out after a minute, complaining
>>> that it could not read more data from the client. If I reduce the multiplicator 1000000 to eg. 200000 it always passes.
>>> If I start the test server using "t/TEST -start-httpd" and then use curl to POST data, I can even POST much bigger
>>> data and get the correct result back. I use
>>> curl -v --data-binary @BIGFILE http://localhost:8529/apache/buffer_in/ > response-body
>>> So I assume it is a problem of interaction between the server reading the POST body and the client sending it.
>>> My test framework was freshly assembled recently, so lots of current modules.
>>> The setup is based on OpenSSL 1.1.1 in the server and in the test framework, but the actual test runs over http, so I
>>> don't expect any OpenSSL related reason for the failure.
>>
>> I did some more tests including using LWP directly and sniffing the packets on the network plus with mod_dumpio and
>> also doing truss / strace.
>>
>> I can reproduce even when sending using LWP directly or just the POST binary coming with LWP. I can not reproduce with
>> curl.
>>
>> With mod_dumpio and in a network sniff plus truss it looks like the client simply stops sending once it got the first
>> response bytes. LWP seems to select the socket FD for read and write. As long as only write gets signalled, it happily
>> sends data. Once it gets write plus read signalled, it switches over to read and no longer checks for write. Since our
>> server side implementation is streaming and starts to send the reflected bytes right away, this LWP behavior breaks
>> the request.
>
> Hmm, it almost seems like that test/reflector module doesn’t reflect the protocol definition
> though, https://tools.ietf.org/html/rfc7231#section-1
>
> "A server listens on a connection for a request,
> parses each message received, interprets the message semantics in
> relation to the identified request target, and responds to that
> request with one or more response messages”
>
> I would interpret that “message received" as the server is expected to wait until the entire request is received, aside from the case of "Expect: 100-continue” and even that alludes to waiting.
>
> https://tools.ietf.org/html/rfc7231#section-6.2.1
>
> "The server intends to send a final response after the request has been fully received and acted upon."
>
> What do you think?
Actually good points. mod_proxy_http e.g. first processes the whole message received before it cares to look for an
answer. I guess in the light of the above this is a perfectly reasonable approach for a client. Having LWP acting this
way which it currently does not as I understand could still cause the test to fail if the output (server) /
input(client) TCP buffers get filled and then the input (server) / output (client) buffers get filled. This would cause
the connection to become stalled and finally run in a timeout. I remember bug reports for mod_proxy_http being used as
reverse proxy where clients expected to already have a response without sending the full request (aka. parts of the
request body still not sent). Given the above from RFC a client cannot be expected to read a response before it
completely wrote the request.
Regards
Rüdiger
Re: t/modules/buffer.t failing in 2.4.36, LWP bug [Was: [VOTE]
Release httpd-2.4.36]
Posted by Mark Blackman <ma...@exonetric.com>.
> On 14 Oct 2018, at 12:33, Rainer Jung <ra...@kippdata.de> wrote:
>
> Am 13.10.2018 um 11:46 schrieb Rainer Jung:
>> Am 11.10.2018 um 20:55 schrieb Ruediger Pluem:
>>>
>>>
>>> On 10/11/2018 08:10 PM, Christophe JAILLET wrote:
>>>> No issue on my Ubuntu 18.04 VM.
>>>>
>>>> On what configuration are you running your tests, Rüdiger? macOS, just like Jim?
>>>
>>> Centos 7.5 64 Bit
>>>
>>> Regards
>>>
>>> Rüdiger
>> The test fails for me as well for 2.4.36 on SLES12. Small bodies are OK, large not. The limit is somewhere between 1.3 and 1.5 MB, not always the same. The test hangs there until mod_reqtimeout times out after a minute, complaining that it could not read more data from the client. If I reduce the multiplicator 1000000 to eg. 200000 it always passes.
>> If I start the test server using "t/TEST -start-httpd" and then use curl to POST data, I can even POST much bigger data and get the correct result back. I use
>> curl -v --data-binary @BIGFILE http://localhost:8529/apache/buffer_in/ > response-body
>> So I assume it is a problem of interaction between the server reading the POST body and the client sending it.
>> My test framework was freshly assembled recently, so lots of current modules.
>> The setup is based on OpenSSL 1.1.1 in the server and in the test framework, but the actual test runs over http, so I don't expect any OpenSSL related reason for the failure.
>
> I did some more tests including using LWP directly and sniffing the packets on the network plus with mod_dumpio and also doing truss / strace.
>
> I can reproduce even when sending using LWP directly or just the POST binary coming with LWP. I can not reproduce with curl.
>
> With mod_dumpio and in a network sniff plus truss it looks like the client simply stops sending once it got the first response bytes. LWP seems to select the socket FD for read and write. As long as only write gets signalled, it happily sends data. Once it gets write plus read signalled, it switches over to read and no longer checks for write. Since our server side implementation is streaming and starts to send the reflected bytes right away, this LWP behavior breaks the request.
Hmm, it almost seems like that test/reflector module doesn’t reflect the protocol definition though, https://tools.ietf.org/html/rfc7231#section-1
"A server listens on a connection for a request,
parses each message received, interprets the message semantics in
relation to the identified request target, and responds to that
request with one or more response messages”
I would interpret that “message received" as the server is expected to wait until the entire request is received, aside from the case of "Expect: 100-continue” and even that alludes to waiting.
https://tools.ietf.org/html/rfc7231#section-6.2.1 <https://tools.ietf.org/html/rfc7231#section-6.2.1>
"The server intends to send a final response after the request has been fully received and acted upon."
What do you think?
- Mark
t/modules/buffer.t failing in 2.4.36, LWP bug [Was: [VOTE] Release
httpd-2.4.36]
Posted by Rainer Jung <ra...@kippdata.de>.
Am 13.10.2018 um 11:46 schrieb Rainer Jung:
> Am 11.10.2018 um 20:55 schrieb Ruediger Pluem:
>>
>>
>> On 10/11/2018 08:10 PM, Christophe JAILLET wrote:
>>> No issue on my Ubuntu 18.04 VM.
>>>
>>> On what configuration are you running your tests, Rüdiger? macOS,
>>> just like Jim?
>>
>> Centos 7.5 64 Bit
>>
>> Regards
>>
>> Rüdiger
>
> The test fails for me as well for 2.4.36 on SLES12. Small bodies are OK,
> large not. The limit is somewhere between 1.3 and 1.5 MB, not always the
> same. The test hangs there until mod_reqtimeout times out after a
> minute, complaining that it could not read more data from the client. If
> I reduce the multiplicator 1000000 to eg. 200000 it always passes.
>
> If I start the test server using "t/TEST -start-httpd" and then use curl
> to POST data, I can even POST much bigger data and get the correct
> result back. I use
>
> curl -v --data-binary @BIGFILE
> http://localhost:8529/apache/buffer_in/ > response-body
>
> So I assume it is a problem of interaction between the server reading
> the POST body and the client sending it.
>
> My test framework was freshly assembled recently, so lots of current
> modules.
>
> The setup is based on OpenSSL 1.1.1 in the server and in the test
> framework, but the actual test runs over http, so I don't expect any
> OpenSSL related reason for the failure.
I did some more tests including using LWP directly and sniffing the
packets on the network plus with mod_dumpio and also doing truss / strace.
I can reproduce even when sending using LWP directly or just the POST
binary coming with LWP. I can not reproduce with curl.
With mod_dumpio and in a network sniff plus truss it looks like the
client simply stops sending once it got the first response bytes. LWP
seems to select the socket FD for read and write. As long as only write
gets signalled, it happily sends data. Once it gets write plus read
signalled, it switches over to read and no longer checks for write.
Since our server side implementation is streaming and starts to send the
reflected bytes right away, this LWP behavior breaks the request.
I opened an issue under
https://github.com/libwww-perl/libwww-perl/issues/299
I don't know how to work around this in the test suite. If we had an
external curl or similar available it would work. Or if we would code
ourselves sending a raw request on the socket and reading the raw request.
Depending on timing the test could break even for small POST sizes. Eg.
on my Solaris system it already breaks around 128KB, but theoretically
it could happen even much earlier.
Regards,
Rainer
Re: [VOTE] Release httpd-2.4.36
Posted by Rainer Jung <ra...@kippdata.de>.
Am 11.10.2018 um 20:55 schrieb Ruediger Pluem:
>
>
> On 10/11/2018 08:10 PM, Christophe JAILLET wrote:
>> No issue on my Ubuntu 18.04 VM.
>>
>> On what configuration are you running your tests, Rüdiger? macOS, just like Jim?
>
> Centos 7.5 64 Bit
>
> Regards
>
> Rüdiger
The test fails for me as well for 2.4.36 on SLES12. Small bodies are OK,
large not. The limit is somewhere between 1.3 and 1.5 MB, not always the
same. The test hangs there until mod_reqtimeout times out after a
minute, complaining that it could not read more data from the client. If
I reduce the multiplicator 1000000 to eg. 200000 it always passes.
If I start the test server using "t/TEST -start-httpd" and then use curl
to POST data, I can even POST much bigger data and get the correct
result back. I use
curl -v --data-binary @BIGFILE
http://localhost:8529/apache/buffer_in/ > response-body
So I assume it is a problem of interaction between the server reading
the POST body and the client sending it.
My test framework was freshly assembled recently, so lots of current
modules.
The setup is based on OpenSSL 1.1.1 in the server and in the test
framework, but the actual test runs over http, so I don't expect any
OpenSSL related reason for the failure.
Regards,
Rainer
>> Le 11/10/2018 à 13:35, Jim Jagielski a écrit :
>>> FWIW, on macOS, both trunk and httpd-2.4 fail on this test:
>>>
>>> t/modules/buffer.t .................. 3/12 # Failed test 4 in t/modules/buffer.t at line 32
>>> t/modules/buffer.t .................. 7/12 # Failed test 8 in t/modules/buffer.t at line 32 fail #2
>>> t/modules/buffer.t .................. 11/12 # Failed test 12 in t/modules/buffer.t at line 32 fail #3
>>> t/modules/buffer.t .................. Failed 3/12 subtests
>>>
>>>
>>>> On Oct 11, 2018, at 7:15 AM, Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com> wrote:
>>>>
>>>> Do you know if the failure is a regression over 2.4.35?
>>>> Regards
>>>> Rüdiger
>>>> Von: Marion et Christophe JAILLET <ch...@wanadoo.fr>
>>>> Gesendet: Donnerstag, 11. Oktober 2018 13:13
>>>> An: dev@httpd.apache.org
>>>> Betreff: re: AW: [VOTE] Release httpd-2.4.36
>>>> Waouh!
>>>>
>>>>
>>>> This would mean I've provided a new useful test!
>>>>
>>>> (it has been added recently in r1841508)
>>>>
>>>>
>>>> :)
>>>>
>>>>
>>>> I definitely need to document how to generate and use test-coverage data when running the test framework.
>>>>
>>>> This helps to spot where new tests are needed.
>>>>
>>>>
>>>> CJ
>>>>
>>>>
>>>>
>>>>
>>>>> Message du 11/10/18 10:08
>>>>> De : "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com>
>>>>> A : "dev@httpd.apache.org" <de...@httpd.apache.org>
>>>>> Copie à :
>>>>> Objet : AW: [VOTE] Release httpd-2.4.36
>>>>>
>>>>> Anyone else seeing
>>>>>
>>>>> t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
>>>>> Failed tests: 8, 12
>>>>>
>>>>> ?
>>>>>
>>>>> I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs.
>>>>>
>>>>> Regards
>>>>>
>>>>> Rüdiger
Re: [VOTE] Release httpd-2.4.36
Posted by Ruediger Pluem <rp...@apache.org>.
On 10/11/2018 08:10 PM, Christophe JAILLET wrote:
> No issue on my Ubuntu 18.04 VM.
>
> On what configuration are you running your tests, Rüdiger? macOS, just like Jim?
Centos 7.5 64 Bit
Regards
Rüdiger
>
> CJ
>
> Le 11/10/2018 à 13:35, Jim Jagielski a écrit :
>> FWIW, on macOS, both trunk and httpd-2.4 fail on this test:
>>
>> t/modules/buffer.t .................. 3/12 # Failed test 4 in t/modules/buffer.t at line 32
>> t/modules/buffer.t .................. 7/12 # Failed test 8 in t/modules/buffer.t at line 32 fail #2
>> t/modules/buffer.t .................. 11/12 # Failed test 12 in t/modules/buffer.t at line 32 fail #3
>> t/modules/buffer.t .................. Failed 3/12 subtests
>>
>>
>>> On Oct 11, 2018, at 7:15 AM, Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com> wrote:
>>>
>>> Do you know if the failure is a regression over 2.4.35?
>>> Regards
>>> Rüdiger
>>> Von: Marion et Christophe JAILLET <ch...@wanadoo.fr>
>>> Gesendet: Donnerstag, 11. Oktober 2018 13:13
>>> An: dev@httpd.apache.org
>>> Betreff: re: AW: [VOTE] Release httpd-2.4.36
>>> Waouh!
>>>
>>>
>>> This would mean I've provided a new useful test!
>>>
>>> (it has been added recently in r1841508)
>>>
>>>
>>> :)
>>>
>>>
>>> I definitely need to document how to generate and use test-coverage data when running the test framework.
>>>
>>> This helps to spot where new tests are needed.
>>>
>>>
>>> CJ
>>>
>>>
>>>
>>>
>>>> Message du 11/10/18 10:08
>>>> De : "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com>
>>>> A : "dev@httpd.apache.org" <de...@httpd.apache.org>
>>>> Copie à :
>>>> Objet : AW: [VOTE] Release httpd-2.4.36
>>>>
>>>> Anyone else seeing
>>>>
>>>> t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
>>>> Failed tests: 8, 12
>>>>
>>>> ?
>>>>
>>>> I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs.
>>>>
>>>> Regards
>>>>
>>>> Rüdiger
>
>
Re: [VOTE] Release httpd-2.4.36
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
No issue on my Ubuntu 18.04 VM.
On what configuration are you running your tests, Rüdiger? macOS, just
like Jim?
CJ
Le 11/10/2018 à 13:35, Jim Jagielski a écrit :
> FWIW, on macOS, both trunk and httpd-2.4 fail on this test:
>
> t/modules/buffer.t .................. 3/12 # Failed test 4 in t/modules/buffer.t at line 32
> t/modules/buffer.t .................. 7/12 # Failed test 8 in t/modules/buffer.t at line 32 fail #2
> t/modules/buffer.t .................. 11/12 # Failed test 12 in t/modules/buffer.t at line 32 fail #3
> t/modules/buffer.t .................. Failed 3/12 subtests
>
>
>> On Oct 11, 2018, at 7:15 AM, Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com> wrote:
>>
>> Do you know if the failure is a regression over 2.4.35?
>>
>> Regards
>>
>> Rüdiger
>>
>> Von: Marion et Christophe JAILLET <ch...@wanadoo.fr>
>> Gesendet: Donnerstag, 11. Oktober 2018 13:13
>> An: dev@httpd.apache.org
>> Betreff: re: AW: [VOTE] Release httpd-2.4.36
>>
>> Waouh!
>>
>>
>>
>> This would mean I've provided a new useful test!
>>
>> (it has been added recently in r1841508)
>>
>>
>>
>> :)
>>
>>
>>
>> I definitely need to document how to generate and use test-coverage data when running the test framework.
>>
>> This helps to spot where new tests are needed.
>>
>>
>>
>> CJ
>>
>>
>>
>>
>>
>>
>>
>>> Message du 11/10/18 10:08
>>> De : "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com>
>>> A : "dev@httpd.apache.org" <de...@httpd.apache.org>
>>> Copie à :
>>> Objet : AW: [VOTE] Release httpd-2.4.36
>>>
>>> Anyone else seeing
>>>
>>> t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
>>> Failed tests: 8, 12
>>>
>>> ?
>>>
>>> I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs.
>>>
>>> Regards
>>>
>>> Rüdiger
Re: [VOTE] Release httpd-2.4.36
Posted by Jim Jagielski <ji...@jaguNET.com>.
Oh, and it's not a regression since, at least, 2.4.34 (at least for me)
> On Oct 11, 2018, at 7:35 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> FWIW, on macOS, both trunk and httpd-2.4 fail on this test:
>
> t/modules/buffer.t .................. 3/12 # Failed test 4 in t/modules/buffer.t at line 32
> t/modules/buffer.t .................. 7/12 # Failed test 8 in t/modules/buffer.t at line 32 fail #2
> t/modules/buffer.t .................. 11/12 # Failed test 12 in t/modules/buffer.t at line 32 fail #3
> t/modules/buffer.t .................. Failed 3/12 subtests
>
>
>> On Oct 11, 2018, at 7:15 AM, Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com> wrote:
>>
>> Do you know if the failure is a regression over 2.4.35?
>>
>> Regards
>>
>> Rüdiger
>>
>> Von: Marion et Christophe JAILLET <ch...@wanadoo.fr>
>> Gesendet: Donnerstag, 11. Oktober 2018 13:13
>> An: dev@httpd.apache.org
>> Betreff: re: AW: [VOTE] Release httpd-2.4.36
>>
>> Waouh!
>>
>>
>>
>> This would mean I've provided a new useful test!
>>
>> (it has been added recently in r1841508)
>>
>>
>>
>> :)
>>
>>
>>
>> I definitely need to document how to generate and use test-coverage data when running the test framework.
>>
>> This helps to spot where new tests are needed.
>>
>>
>>
>> CJ
>>
>>
>>
>>
>>
>>
>>
>>> Message du 11/10/18 10:08
>>> De : "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com>
>>> A : "dev@httpd.apache.org" <de...@httpd.apache.org>
>>> Copie à :
>>> Objet : AW: [VOTE] Release httpd-2.4.36
>>>
>>> Anyone else seeing
>>>
>>> t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
>>> Failed tests: 8, 12
>>>
>>> ?
>>>
>>> I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs.
>>>
>>> Regards
>>>
>>> Rüdiger
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Daniel Ruggeri <dr...@primary.net>
>>>> Gesendet: Donnerstag, 11. Oktober 2018 02:27
>>>> An: dev@httpd.apache.org
>>>> Betreff: Re: [VOTE] Release httpd-2.4.36
>>>>
>>>> +1 from me (talking to myself).
>>>>
>>>> Test environment follows. I observe only one failure of the test suite
>>>> (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
>>>>
>>>> system:
>>>> kernel:
>>>> name: Linux
>>>> release: 3.16.0-4-amd64
>>>> version: #1 SMP Debian 3.16.51-3 (2017-12-13)
>>>> machine: x86_64
>>>>
>>>> libraries:
>>>> openssl: "1.1.1"
>>>> openldap: "2.4.46"
>>>> apr: "1.6.5"
>>>> apr-util: "1.6.1"
>>>> iconv: "1.2.2"
>>>> brotli: "1.0.6"
>>>> nghttp2: "1.34.0"
>>>> zlib: "1.2.11"
>>>> pcre: "8.42"
>>>> libxml2: "2.9.8"
>>>> php: "5.6.38"
>>>> lua: "5.3.5"
>>>> curl: "7.61.1"
>>>>
>>>> --
>>>> Daniel Ruggeri
>>>>
>>>> On 10/10/2018 2:18 PM, 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
>>>>>
>>>
>>>
>
Re: [VOTE] Release httpd-2.4.36
Posted by Jim Jagielski <ji...@jaguNET.com>.
FWIW, on macOS, both trunk and httpd-2.4 fail on this test:
t/modules/buffer.t .................. 3/12 # Failed test 4 in t/modules/buffer.t at line 32
t/modules/buffer.t .................. 7/12 # Failed test 8 in t/modules/buffer.t at line 32 fail #2
t/modules/buffer.t .................. 11/12 # Failed test 12 in t/modules/buffer.t at line 32 fail #3
t/modules/buffer.t .................. Failed 3/12 subtests
> On Oct 11, 2018, at 7:15 AM, Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com> wrote:
>
> Do you know if the failure is a regression over 2.4.35?
>
> Regards
>
> Rüdiger
>
> Von: Marion et Christophe JAILLET <ch...@wanadoo.fr>
> Gesendet: Donnerstag, 11. Oktober 2018 13:13
> An: dev@httpd.apache.org
> Betreff: re: AW: [VOTE] Release httpd-2.4.36
>
> Waouh!
>
>
>
> This would mean I've provided a new useful test!
>
> (it has been added recently in r1841508)
>
>
>
> :)
>
>
>
> I definitely need to document how to generate and use test-coverage data when running the test framework.
>
> This helps to spot where new tests are needed.
>
>
>
> CJ
>
>
>
>
>
>
>
> > Message du 11/10/18 10:08
> > De : "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com>
> > A : "dev@httpd.apache.org" <de...@httpd.apache.org>
> > Copie à :
> > Objet : AW: [VOTE] Release httpd-2.4.36
> >
> > Anyone else seeing
> >
> > t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
> > Failed tests: 8, 12
> >
> > ?
> >
> > I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs.
> >
> > Regards
> >
> > Rüdiger
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Daniel Ruggeri <dr...@primary.net>
> > > Gesendet: Donnerstag, 11. Oktober 2018 02:27
> > > An: dev@httpd.apache.org
> > > Betreff: Re: [VOTE] Release httpd-2.4.36
> > >
> > > +1 from me (talking to myself).
> > >
> > > Test environment follows. I observe only one failure of the test suite
> > > (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
> > >
> > > system:
> > > kernel:
> > > name: Linux
> > > release: 3.16.0-4-amd64
> > > version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> > > machine: x86_64
> > >
> > > libraries:
> > > openssl: "1.1.1"
> > > openldap: "2.4.46"
> > > apr: "1.6.5"
> > > apr-util: "1.6.1"
> > > iconv: "1.2.2"
> > > brotli: "1.0.6"
> > > nghttp2: "1.34.0"
> > > zlib: "1.2.11"
> > > pcre: "8.42"
> > > libxml2: "2.9.8"
> > > php: "5.6.38"
> > > lua: "5.3.5"
> > > curl: "7.61.1"
> > >
> > > --
> > > Daniel Ruggeri
> > >
> > > On 10/10/2018 2:18 PM, 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
> > > >
> >
> >
re: AW: AW: [VOTE] Release httpd-2.4.36
Posted by Marion et Christophe JAILLET <ch...@wanadoo.fr>.
No, I don't know and won't be able to check before tomorrow evening.
I would say that these tests were passing with 2.4.x when it was added (~3 weeks ago), so it could be a regression.
But it needs to be checked to be sure about it.
Nothing obvious in the recent commits look related to a change of behavior in this area.
CJ
> Message du 11/10/18 13:15
> De : "Plüm, Rüdiger, Vodafone Group"
> A : "dev@httpd.apache.org"
> Copie à :
> Objet : AW: AW: [VOTE] Release httpd-2.4.36
>
>
Do you know if the failure is a regression over 2.4.35?
Regards
Rüdiger
Von: Marion et Christophe JAILLET
> Gesendet: Donnerstag, 11. Oktober 2018 13:13
> An: dev@httpd.apache.org
> Betreff: re: AW: [VOTE] Release httpd-2.4.36
> Waouh!
>
> This would mean I've provided a new useful test!
> (it has been added recently in r1841508)
>
> :)
>
> I definitely need to document how to generate and use test-coverage data when running the test framework.
> This helps to spot where new tests are needed.
>
> CJ
>
>
>
> Message du 11/10/18 10:08
> > De : "Plüm, Rüdiger, Vodafone Group"
> > A : "dev@httpd.apache.org"
> > Copie à :
> > Objet : AW: [VOTE] Release httpd-2.4.36
> >
> > Anyone else seeing
> >
> > t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
> > Failed tests: 8, 12
> >
> > ?
> >
> > I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs.
> >
> > Regards
> >
> > Rüdiger
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Daniel Ruggeri
> > > Gesendet: Donnerstag, 11. Oktober 2018 02:27
> > > An: dev@httpd.apache.org
> > > Betreff: Re: [VOTE] Release httpd-2.4.36
> > >
> > > +1 from me (talking to myself).
> > >
> > > Test environment follows. I observe only one failure of the test suite
> > > (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
> > >
> > > system:
> > > kernel:
> > > name: Linux
> > > release: 3.16.0-4-amd64
> > > version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> > > machine: x86_64
> > >
> > > libraries:
> > > openssl: "1.1.1"
> > > openldap: "2.4.46"
> > > apr: "1.6.5"
> > > apr-util: "1.6.1"
> > > iconv: "1.2.2"
> > > brotli: "1.0.6"
> > > nghttp2: "1.34.0"
> > > zlib: "1.2.11"
> > > pcre: "8.42"
> > > libxml2: "2.9.8"
> > > php: "5.6.38"
> > > lua: "5.3.5"
> > > curl: "7.61.1"
> > >
> > > --
> > > Daniel Ruggeri
> > >
> > > On 10/10/2018 2:18 PM, 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
> > > >
> >
> >
AW: AW: [VOTE] Release httpd-2.4.36
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
Do you know if the failure is a regression over 2.4.35?
Regards
Rüdiger
Von: Marion et Christophe JAILLET <ch...@wanadoo.fr>
Gesendet: Donnerstag, 11. Oktober 2018 13:13
An: dev@httpd.apache.org
Betreff: re: AW: [VOTE] Release httpd-2.4.36
Waouh!
This would mean I've provided a new useful test!
(it has been added recently in r1841508)
:)
I definitely need to document how to generate and use test-coverage data when running the test framework.
This helps to spot where new tests are needed.
CJ
> Message du 11/10/18 10:08
> De : "Plüm, Rüdiger, Vodafone Group" <ru...@vodafone.com>>
> A : "dev@httpd.apache.org<ma...@httpd.apache.org>" <de...@httpd.apache.org>>
> Copie à :
> Objet : AW: [VOTE] Release httpd-2.4.36
>
> Anyone else seeing
>
> t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
> Failed tests: 8, 12
>
> ?
>
> I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs.
>
> Regards
>
> Rüdiger
>
> > -----Ursprüngliche Nachricht-----
> > Von: Daniel Ruggeri <dr...@primary.net>>
> > Gesendet: Donnerstag, 11. Oktober 2018 02:27
> > An: dev@httpd.apache.org<ma...@httpd.apache.org>
> > Betreff: Re: [VOTE] Release httpd-2.4.36
> >
> > +1 from me (talking to myself).
> >
> > Test environment follows. I observe only one failure of the test suite
> > (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
> >
> > system:
> > kernel:
> > name: Linux
> > release: 3.16.0-4-amd64
> > version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> > machine: x86_64
> >
> > libraries:
> > openssl: "1.1.1"
> > openldap: "2.4.46"
> > apr: "1.6.5"
> > apr-util: "1.6.1"
> > iconv: "1.2.2"
> > brotli: "1.0.6"
> > nghttp2: "1.34.0"
> > zlib: "1.2.11"
> > pcre: "8.42"
> > libxml2: "2.9.8"
> > php: "5.6.38"
> > lua: "5.3.5"
> > curl: "7.61.1"
> >
> > --
> > Daniel Ruggeri
> >
> > On 10/10/2018 2:18 PM, 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
> > >
>
>
re: AW: [VOTE] Release httpd-2.4.36
Posted by Marion et Christophe JAILLET <ch...@wanadoo.fr>.
Waouh!
This would mean I've provided a new useful test!
(it has been added recently in r1841508)
:)
I definitely need to document how to generate and use test-coverage data when running the test framework.
This helps to spot where new tests are needed.
CJ
> Message du 11/10/18 10:08
> De : "Plüm, Rüdiger, Vodafone Group"
> A : "dev@httpd.apache.org"
> Copie à :
> Objet : AW: [VOTE] Release httpd-2.4.36
>
> Anyone else seeing
>
> t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
> Failed tests: 8, 12
>
> ?
>
> I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs.
>
> Regards
>
> Rüdiger
>
> > -----Ursprüngliche Nachricht-----
> > Von: Daniel Ruggeri
> > Gesendet: Donnerstag, 11. Oktober 2018 02:27
> > An: dev@httpd.apache.org
> > Betreff: Re: [VOTE] Release httpd-2.4.36
> >
> > +1 from me (talking to myself).
> >
> > Test environment follows. I observe only one failure of the test suite
> > (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
> >
> > system:
> > kernel:
> > name: Linux
> > release: 3.16.0-4-amd64
> > version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> > machine: x86_64
> >
> > libraries:
> > openssl: "1.1.1"
> > openldap: "2.4.46"
> > apr: "1.6.5"
> > apr-util: "1.6.1"
> > iconv: "1.2.2"
> > brotli: "1.0.6"
> > nghttp2: "1.34.0"
> > zlib: "1.2.11"
> > pcre: "8.42"
> > libxml2: "2.9.8"
> > php: "5.6.38"
> > lua: "5.3.5"
> > curl: "7.61.1"
> >
> > --
> > Daniel Ruggeri
> >
> > On 10/10/2018 2:18 PM, 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
> > >
>
>
AW: [VOTE] Release httpd-2.4.36
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
Anyone else seeing
t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
Failed tests: 8, 12
?
I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs.
Regards
Rüdiger
> -----Ursprüngliche Nachricht-----
> Von: Daniel Ruggeri <dr...@primary.net>
> Gesendet: Donnerstag, 11. Oktober 2018 02:27
> An: dev@httpd.apache.org
> Betreff: Re: [VOTE] Release httpd-2.4.36
>
> +1 from me (talking to myself).
>
> Test environment follows. I observe only one failure of the test suite
> (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
>
> system:
> kernel:
> name: Linux
> release: 3.16.0-4-amd64
> version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> machine: x86_64
>
> libraries:
> openssl: "1.1.1"
> openldap: "2.4.46"
> apr: "1.6.5"
> apr-util: "1.6.1"
> iconv: "1.2.2"
> brotli: "1.0.6"
> nghttp2: "1.34.0"
> zlib: "1.2.11"
> pcre: "8.42"
> libxml2: "2.9.8"
> php: "5.6.38"
> lua: "5.3.5"
> curl: "7.61.1"
>
> --
> Daniel Ruggeri
>
> On 10/10/2018 2:18 PM, 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
> >
Re: [VOTE] Release httpd-2.4.36
Posted by Daniel Ruggeri <dr...@primary.net>.
+1 from me (talking to myself).
Test environment follows. I observe only one failure of the test suite
(mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
system:
kernel:
name: Linux
release: 3.16.0-4-amd64
version: #1 SMP Debian 3.16.51-3 (2017-12-13)
machine: x86_64
libraries:
openssl: "1.1.1"
openldap: "2.4.46"
apr: "1.6.5"
apr-util: "1.6.1"
iconv: "1.2.2"
brotli: "1.0.6"
nghttp2: "1.34.0"
zlib: "1.2.11"
pcre: "8.42"
libxml2: "2.9.8"
php: "5.6.38"
lua: "5.3.5"
curl: "7.61.1"
--
Daniel Ruggeri
On 10/10/2018 2:18 PM, 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
>
Re: [VOTE] Release httpd-2.4.36
Posted by Daniel Ruggeri <dr...@apache.org>.
Hi, all;
As a result of testing and further analysis of this release, I am calling this release dead on the vine and shall not pursue publishing it. We have -1 votes based on the recently discovered OpenSSL 1.1.1 behavior change [1].
Although this tag shall not become a release, I'd like to thank all testers and those who have put effort into getting us to this point as well as catching an error that could impact our users. I consider this a victory :-)
I will follow up with another proposal to T&R when we resolve the issue.
Cheers!
[1] https://lists.apache.org/thread.html/cff9db75d9e281f116382f090b3079dedc2c9842192d213ae4948e15@%3Cdev.httpd.apache.org%3E
--
Daniel Ruggeri
On 2018/10/10 19:18:45, Daniel Ruggeri <dr...@primary.net> 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
>
> --
> Daniel Ruggeri
>
Re: [VOTE] Release httpd-2.4.36
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/14/2018 05:46 PM, Daniel Ruggeri wrote:
> 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.
> --
> Daniel Ruggeri
I was working on a "clean room" build and test but kept getting pulled
aside into other peoples problems. I'll try to get moving.
Dennis
Re: [VOTE] Release httpd-2.4.36
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 15.10.2018 um 15:51 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
>
>
>
> On Mon, Oct 15, 2018 at 3:06 AM Stefan Eissing <st...@greenbytes.de> wrote:
>
> 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.
>
> Stefan, thanks for the detailed analysis else-thread, and thank you Rainer for the detailed defect report. It would be interesting to trigger this deliberately in the test framework.
>
> > On October 14, 2018 4:44:04 PM CDT, "Helmut K. C. Tessarek" <te...@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.
>
> Based on the observed change of SSL_read which we had not entirely accounted for, I'm -1 for GA release.
>
> I don't think it's helpful for us to ship this defect in any alpha or beta of trunk. I'd consider it a showstopper.
Agreed.
Re: [VOTE] Release httpd-2.4.36
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Oct 15, 2018 at 3:06 AM Stefan Eissing <st...@greenbytes.de>
wrote:
>
> 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.
>
Stefan, thanks for the detailed analysis else-thread, and thank you Rainer
for the detailed defect report. It would be interesting to trigger this
deliberately in the test framework.
> > On October 14, 2018 4:44:04 PM CDT, "Helmut K. C. Tessarek" <
> tessarek@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.
>
Based on the observed change of SSL_read which we had not entirely
accounted for, I'm -1 for GA release.
I don't think it's helpful for us to ship this defect in any alpha or beta
of trunk. I'd consider it a showstopper.
Re: [VOTE] Release httpd-2.4.36
Posted by Daniel Gruno <hu...@apache.org>.
On 10/15/2018 04:20 PM, Stefan Eissing wrote:
>
>
>> Am 15.10.2018 um 16:11 schrieb Jim Jagielski <ji...@jaguNET.com>:
>>
>> 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. I am -1 on 2.4.36 as well, in case that was not clear. Don't know how this "veto" came into this...
I don't think it was directed at anyone, just a general note that even
if we find faults with 2.4.36 we can't pull the release with a -1 unless
everyone changes their minds, as releases can't be vetoed. The RM can
choose to re-roll after some fixes have been done, but 2.4.36 will be
burned off then.
>
> -Stefan
>
>>> On Oct 15, 2018, at 10:07 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>>>
>>>
>>>
>>>> Am 15.10.2018 um 15:58 schrieb Jim Jagielski <ji...@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 <st...@greenbytes.de> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri <dr...@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" <te...@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?
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [VOTE] Release httpd-2.4.36
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Oct 15, 2018, at 10:20 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>
>
>
>> Am 15.10.2018 um 16:11 schrieb Jim Jagielski <ji...@jaguNET.com>:
>>
>> 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 <st...@greenbytes.de> wrote:
>>>
>>>
>>>
>>>> Am 15.10.2018 um 15:58 schrieb Jim Jagielski <ji...@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 <st...@greenbytes.de> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri <dr...@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" <te...@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?
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [VOTE] Release httpd-2.4.36
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 15.10.2018 um 16:11 schrieb Jim Jagielski <ji...@jaguNET.com>:
>
> 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. I am -1 on 2.4.36 as well, in case that was not clear. Don't know how this "veto" came into this...
-Stefan
>> On Oct 15, 2018, at 10:07 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>>
>>
>>
>>> Am 15.10.2018 um 15:58 schrieb Jim Jagielski <ji...@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 <st...@greenbytes.de> wrote:
>>>>
>>>>
>>>>
>>>>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri <dr...@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" <te...@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?
>>>>>
>>>>
>>>
>>
>
Re: [VOTE] Release httpd-2.4.36
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <st...@greenbytes.de> wrote:
>
>
>
>> Am 15.10.2018 um 15:58 schrieb Jim Jagielski <ji...@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 <st...@greenbytes.de> wrote:
>>>
>>>
>>>
>>>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri <dr...@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" <te...@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?
>>>>
>>>
>>
>
Re: [VOTE] Release httpd-2.4.36
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 15.10.2018 um 15:58 schrieb Jim Jagielski <ji...@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 <st...@greenbytes.de> wrote:
>>
>>
>>
>>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri <dr...@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" <te...@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?
>>>
>>
>
Re: [VOTE] Release httpd-2.4.36
Posted by Jim Jagielski <ji...@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"...
> On Oct 15, 2018, at 4:06 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>
>
>
>> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri <dr...@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" <te...@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?
>>
>
Re: [VOTE] Release httpd-2.4.36
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri <dr...@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" <te...@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?
>
Re: [VOTE] Release httpd-2.4.36
Posted by Daniel Ruggeri <dr...@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.
--
Daniel Ruggeri
On October 14, 2018 4:44:04 PM CDT, "Helmut K. C. Tessarek" <te...@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?
>
>
>--
>regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
>Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
>
>/*
> Thou shalt not follow the NULL pointer for chaos and madness
> await thee at its end.
>*/
Re: [VOTE] Release httpd-2.4.36
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
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?
--
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/