Re: [VOTE] Release httpd-2.4.36

[Daniel Ruggeri]

+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: NOTICE: Intent to T 2.4.36

[Gregg Smith]

FWIW, I've been running 2.4.36-dev at revision 1841586 for 19 days 35 
minutes as of this writing and I've seen no problems up to this point. 
Granted I only get a few thousand hits a day and not millions but so far 
so good. Haven't had many tls/1.3 but I would assume that's to be 
expected for another week or two until Chrome 70 and Firefox 63 come out.


Now off to build .36

On 10/10/2018 1:29 PM, William A Rowe Jr wrote:

On Wed, Oct 10, 2018, 14:53 Mark Blackman  wrote:



Does the TLSv1.3 support need to be production ready?

TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger
existing behaviours, I would have assumed it’s relatively safe to release
with caveats in the docs.
Of course, once there’s more take-up of TLSv1.3, then the test suite needs
to be useful. Getting real-world feedback about something completely new
that doesn’t endanger existing behaviours outside of TLSv1.3 is probably
worthwhile.



Were it so easy...

It turns out httpd through 2.4.35 remain incompatible with changes to
openssl 1.1.1. This was disappointing from this project's perspective, the
issues are tracked on openssl project GitHub tickets.

If everything is good about this candidate, it should build and run against
1.1.0, or 1.1.1, whether or not TLS 1.3 is enabled or avoided.

Ben Laurie last decade tried to address this with mod_tls, but mod_ssl
remains deeply tied to the internal behavior of libssl and libcrypto, to a
degree that it is effectively impossible to drop in 1.1.1 due to mechanical
changes in the protocol.

Dropping httpd 2.4.any into openssl 1.1.1 is a mess that several committers
have applied a great deal of attention to. We've undergone the same
problems with 1.1.0, 1.0.1, 1.0.0 and 0.9.8, so this didn't come as a
surprise.

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018, 14:53 Mark Blackman  wrote:

>
> Does the TLSv1.3 support need to be production ready?
>
> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger
> existing behaviours, I would have assumed it’s relatively safe to release
> with caveats in the docs.
> Of course, once there’s more take-up of TLSv1.3, then the test suite needs
> to be useful. Getting real-world feedback about something completely new
> that doesn’t endanger existing behaviours outside of TLSv1.3 is probably
> worthwhile.
>

Were it so easy...

It turns out httpd through 2.4.35 remain incompatible with changes to
openssl 1.1.1. This was disappointing from this project's perspective, the
issues are tracked on openssl project GitHub tickets.

If everything is good about this candidate, it should build and run against
1.1.0, or 1.1.1, whether or not TLS 1.3 is enabled or avoided.

Ben Laurie last decade tried to address this with mod_tls, but mod_ssl
remains deeply tied to the internal behavior of libssl and libcrypto, to a
degree that it is effectively impossible to drop in 1.1.1 due to mechanical
changes in the protocol.

Dropping httpd 2.4.any into openssl 1.1.1 is a mess that several committers
have applied a great deal of attention to. We've undergone the same
problems with 1.1.0, 1.0.1, 1.0.0 and 0.9.8, so this didn't come as a
surprise.

Re: NOTICE: Intent to T 2.4.36

[Mark Blackman]

> On 10 Oct 2018, at 21:04, Jim Jagielski  wrote:
> 
>> 
>> Does the TLSv1.3 support need to be production ready?
>> 
>> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger 
>> existing behaviours, I would have assumed it’s relatively safe to release 
>> with caveats in the docs. 
>> Of course, once there’s more take-up of TLSv1.3, then the test suite needs 
>> to be useful. Getting real-world feedback about something completely new 
>> that doesn’t endanger existing behaviours outside of TLSv1.3 is probably 
>> worthwhile.
> 
> The issue is that such a major feature enhancement touches a lot of code. 
> That can cause regressions.
> 
> Sometimes, some people try to reduce and restrict development and new 
> features using that as an argument. I, and numerous others, have consistently 
> disagreed with that as a convincing argument against adding stuff to 2.4.x. 
> In this particular situation, the "usual suspect(s)" were actually very 
> gung-ho on release, despite this being the exact kind of situation they would 
> normally balk against. I was noting the discrepancy and wondering the 
> reasoning…

Fair enough, I hadn’t checked to see how invasive the change was. I had assumed 
a lot of "#ifdef TLSV13” protecting current behaviours.

- Mark

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018, 14:46 Jim Jagielski  wrote:

>
> On Oct 10, 2018, at 3:37 PM, William A Rowe Jr 
> wrote:
>
> On Wed, Oct 10, 2018, 14:28 Jim Jagielski  wrote:
>
>>
>> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr 
>> wrote:
>>
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:
>>
>>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>>>
>>> If that's not ready for prime time, then why a release??
>>>
>>
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
>> we will continue to see odd test results.
>>
>> The question is How Comfortable Are We That TLSv1.3 Support Is Production
>> Ready?
>>
>
"We" answer that question by voting on a release candidate.

This release seems very, very rushed to me. It seems strange that for
>> someone who balks against releasing s/w that hasn't been sufficiently
>> tested, or could cause regressions, and that the sole reason for this
>> particular release is TLSv1.3 support which seems insufficiently tested,
>> you are uncharacteristic cool with all this.
>>
>
> You elided the other half of my answer, you might want to read the entire
> comment.
>
> If we can exercise the same discipline with 2.4.37 that we showed with
> 2.4.35, then instead of producing a string of releases with a string of
> regressions, we still come out ahead for all users.
>
>
> You wrote:
>It was my hope we would push this out as 2.5.1-alpha, as now synced
>with 2.4.x branch, and let the eager early adopters help us uncover any
>unforeseen issues. Think we have a handle on, and have addressed
>the anticipated issues.
>
> So "eager early adopters" are OK with modules *you* wish to push out, even
> if they aren't quite ready, but NOT OK with modules and features others
> want, even if they also agree that they 'have a handle on, and have
> addressed the anticipated issues'
>

Do you actually remember what an -alpha release was? I know we've thrown
all the s&$# against the wall that would stick for the past 8 years,
waiting until it was announced to find out how much would slide back on the
floor.

What I just wrote above is that I think 2.4.36 is premature, but a release
for users to test is not. But since all of our discussions of reversioning
end up as immature as your silly provocation above, I've been done
debating. I haven't said yes or no to 2.4.36, I only started promoting the
idea of 2.5 alpha again, and even had a brief hope you supported the idea,
before you suggested throwing the contents of trunk en masse back into the
maintenance branch 2.4. That's when I checked out of the discussion, no
desire to keep beating my head against that brick wall.

In other words: would anyone else have suggested adding a major feature
> such as this, with somewhat questionable testing as well as it being the
> sole reason for said release, you would have complained and dismissed such
> explanations as 'eager early adopters' as facetious. I am glad that this is
> no longer the case and you have Seen The Light! As long as we can show an
> attempt at testing, and convince ourselves we have a "handle on" anything
> that might pop up, and addressed any anticipated issues, we can continue
> adding new features as we have been and still come out ahead for all users.
> Again, this is what I and others have been pushing and promoting for years
> so I am again glad that you have finally agreed.
>
> It's the inconsistency that is bothersome.
>

I've stated repeatedly that so long as httpd project members remain split
on offering a security and defect-fix maintenance branch, and in violent
opposition to moving forward with an enhancement 2.next or even 3.0
release, I've checked out from expressing an opinion on the way the project
manages the release branch, or the readiness of that branch, and I'll just
pay attention to trunk, which is interesting to me.

My only recent input was a plea to get out the first regression fix,
security and maintenance release out since 2.4.18 or so (looks that we
succeeded with .35), support for the proposal to start moving on
2.5.1-alpha from trunk, and an absolute insistence that all RMs observe
both the public STATUS as well as our internal security STATUS in preparing
and publicizing releases. Other details aren't worth endless debate threads.

When a 2.4 release is approved, I'm about to propose the same
feature/enhancement freeze for one subversion (so .38 following .37, should
the .36 candidate prove not ready yet) to address newly introduced (yet
undetected) defects, before we return to the is all pattern of chaotic
changes again.

Presenting this as 2.5.1-alpha and leveraging our users@ scrutiny still
makes more sense to me, and if the changes proved non-disruptive, shipping
these as 2.4.x afterwards.

Re: [VOTE] Release httpd-2.4.36

[Jim Jagielski]

+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  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: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

> 
> Does the TLSv1.3 support need to be production ready?
> 
> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger 
> existing behaviours, I would have assumed it’s relatively safe to release 
> with caveats in the docs. 
> Of course, once there’s more take-up of TLSv1.3, then the test suite needs to 
> be useful. Getting real-world feedback about something completely new that 
> doesn’t endanger existing behaviours outside of TLSv1.3 is probably 
> worthwhile.

The issue is that such a major feature enhancement touches a lot of code. That 
can cause regressions.

Sometimes, some people try to reduce and restrict development and new features 
using that as an argument. I, and numerous others, have consistently disagreed 
with that as a convincing argument against adding stuff to 2.4.x. In this 
particular situation, the "usual suspect(s)" were actually very gung-ho on 
release, despite this being the exact kind of situation they would normally 
balk against. I was noting the discrepancy and wondering the reasoning...

Re: NOTICE: Intent to T 2.4.36

[Mark Blackman]

> On 10 Oct 2018, at 20:28, Jim Jagielski  wrote:
> 
> 
> 
>> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr > > wrote:
>> 
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski > > wrote:
>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>> 
>> If that's not ready for prime time, then why a release??
>> 
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test 
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
>> we will continue to see odd test results.
> 
> The question is How Comfortable Are We That TLSv1.3 Support Is Production 
> Ready?
> 
> This release seems very, very rushed to me. It seems strange that for someone 
> who balks against releasing s/w that hasn't been sufficiently tested, or 
> could cause regressions, and that the sole reason for this particular release 
> is TLSv1.3 support which seems insufficiently tested, you are 
> uncharacteristic cool with all this.

Does the TLSv1.3 support need to be production ready?

TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger 
existing behaviours, I would have assumed it’s relatively safe to release with 
caveats in the docs. 
Of course, once there’s more take-up of TLSv1.3, then the test suite needs to 
be useful. Getting real-world feedback about something completely new that 
doesn’t endanger existing behaviours outside of TLSv1.3 is probably worthwhile.

- Mark

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

FWIW, I am NOT proposing that. Nor would I have the right to do so.

> On Oct 10, 2018, at 3:50 PM, Daniel Ruggeri  wrote:
> 
> On 2018-10-10 14:01, William A Rowe Jr wrote:
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:
>>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3
>>> support.
>>> If that's not ready for prime time, then why a release??
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl
>> 1.1.1
>> we will continue to see odd test results.
>> It was my hope we would push this out as 2.5.1-alpha, as now synced
>> with 2.4.x branch, and let the eager early adopters help us uncover
>> any
>> unforeseen issues. Think we have a handle on, and have addressed
>> the anticipated issues.
> 
> Right, my understanding is that this is more around the test suite and how it 
> does the testing rather than the project itself. If that's not the case, and 
> httpd itself isn't ready, I'm OK with aborting the release process.
> 
> -- 
> Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

On 2018-10-10 14:01, William A Rowe Jr wrote:

On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:


I thought the whole intent for a quick 2.4.36 was for TLSv1.3
support.

If that's not ready for prime time, then why a release??


AIUI, it isn't that httpd isn't ready for release, or even httpd-test
framework.
Until all the upstream CPAN modules behave reasonably with openssl
1.1.1
we will continue to see odd test results.

It was my hope we would push this out as 2.5.1-alpha, as now synced
with 2.4.x branch, and let the eager early adopters help us uncover
any
unforeseen issues. Think we have a handle on, and have addressed
the anticipated issues.


Right, my understanding is that this is more around the test suite and 
how it does the testing rather than the project itself. If that's not 
the case, and httpd itself isn't ready, I'm OK with aborting the release 
process.


--
Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

> On Oct 10, 2018, at 3:37 PM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 10, 2018, 14:28 Jim Jagielski  > wrote:
> 
> 
>> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr > > wrote:
>> 
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski > > wrote:
>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>> 
>> If that's not ready for prime time, then why a release??
>> 
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test 
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
>> we will continue to see odd test results.
> 
> The question is How Comfortable Are We That TLSv1.3 Support Is Production 
> Ready?
> 
> This release seems very, very rushed to me. It seems strange that for someone 
> who balks against releasing s/w that hasn't been sufficiently tested, or 
> could cause regressions, and that the sole reason for this particular release 
> is TLSv1.3 support which seems insufficiently tested, you are 
> uncharacteristic cool with all this.
> 
> You elided the other half of my answer, you might want to read the entire 
> comment.
> 
> If we can exercise the same discipline with 2.4.37 that we showed with 
> 2.4.35, then instead of producing a string of releases with a string of 
> regressions, we still come out ahead for all users.

You wrote:
   It was my hope we would push this out as 2.5.1-alpha, as now synced
   with 2.4.x branch, and let the eager early adopters help us uncover any
   unforeseen issues. Think we have a handle on, and have addressed
   the anticipated issues.

So "eager early adopters" are OK with modules *you* wish to push out, even if 
they aren't quite ready, but NOT OK with modules and features others want, even 
if they also agree that they 'have a handle on, and have addressed the 
anticipated issues'

In other words: would anyone else have suggested adding a major feature such as 
this, with somewhat questionable testing as well as it being the sole reason 
for said release, you would have complained and dismissed such explanations as 
'eager early adopters' as facetious. I am glad that this is no longer the case 
and you have Seen The Light! As long as we can show an attempt at testing, and 
convince ourselves we have a "handle on" anything that might pop up, and 
addressed any anticipated issues, we can continue adding new features as we 
have been and still come out ahead for all users. Again, this is what I and 
others have been pushing and promoting for years so I am again glad that you 
have finally agreed.

It's the inconsistency that is bothersome.

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018, 09:04 Stefan Eissing 
wrote:

>
> Since each pytest module starts httpd and stops it again, the config files
> can be very local to the tests being done. That makes them quite easy to
> understand and startup times very short.
>

Sadly, that's an enormous regression from the perl-framework. You'll note
that our suite can be started in server mode on a significantly limited
test host environment, and the tests applied from a more comprehensive test
client instance. This proved especially helpful on aix, hpux and other odd
ball architectures when they were part of my focus.

>

Re: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018, 14:28 Jim Jagielski  wrote:

>
>
> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr 
> wrote:
>
> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:
>
>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>>
>> If that's not ready for prime time, then why a release??
>>
>
> AIUI, it isn't that httpd isn't ready for release, or even httpd-test
> framework.
> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
> we will continue to see odd test results.
>
>
> The question is How Comfortable Are We That TLSv1.3 Support Is Production
> Ready?
>
> This release seems very, very rushed to me. It seems strange that for
> someone who balks against releasing s/w that hasn't been sufficiently
> tested, or could cause regressions, and that the sole reason for this
> particular release is TLSv1.3 support which seems insufficiently tested,
> you are uncharacteristic cool with all this.
>

You elided the other half of my answer, you might want to read the entire
comment.

If we can exercise the same discipline with 2.4.37 that we showed with
2.4.35, then instead of producing a string of releases with a string of
regressions, we still come out ahead for all users.

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

> On Oct 10, 2018, at 10:04 AM, Stefan Eissing  
> wrote:
> I have started to convert the existing h2 testsuite in 
> https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk from shell scripts 
> to pytest in the github repro. I have a pytest suite for mod_md also in its 
> github. 
> 
> My hope is to, one day, make those part of a httpd test suite, probably just 
> by combining the separate standalone ones. Then we could have 
> 'modules/ABC/test' as optional part of a module with a defined way to trigger 
> them.
> 

That would be great because it seems that almost no one is using it, or has 
been able to get that test suite to work. I know I haven't.

Re: NOTICE: Intent to T 2.4.36

[Jim Jagielski]

> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr  wrote:
> 
> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  > wrote:
> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
> 
> If that's not ready for prime time, then why a release??
> 
> AIUI, it isn't that httpd isn't ready for release, or even httpd-test 
> framework.
> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
> we will continue to see odd test results.

The question is How Comfortable Are We That TLSv1.3 Support Is Production Ready?

This release seems very, very rushed to me. It seems strange that for someone 
who balks against releasing s/w that hasn't been sufficiently tested, or could 
cause regressions, and that the sole reason for this particular release is 
TLSv1.3 support which seems insufficiently tested, you are uncharacteristic 
cool with all this.

[VOTE] Release httpd-2.4.36

[Daniel Ruggeri]

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: NOTICE: Intent to T 2.4.36

[William A Rowe Jr]

On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski  wrote:

> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>
> If that's not ready for prime time, then why a release??
>

AIUI, it isn't that httpd isn't ready for release, or even httpd-test
framework.
Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
we will continue to see odd test results.

It was my hope we would push this out as 2.5.1-alpha, as now synced
with 2.4.x branch, and let the eager early adopters help us uncover any
unforeseen issues. Think we have a handle on, and have addressed
the anticipated issues.

Re: NOTICE: Intent to T 2.4.36

[Daniel Ruggeri]

On 2018-10-10 07:30, Joe Orton wrote:

On Tue, Oct 09, 2018 at 03:29:49PM -0500, Daniel Ruggeri wrote:

Hi, all;
   I ran through my usual testing routine, this time with OpenSSL 
1.1.1, but
found several test failures. In the past, these issues have been 
isolated to
my environment so I just wanted to drop a line to see if anyone has 
run the
test suite against 2.4.x lately and can corroborate this result? If 
not, I

can debug my environment.


TLSv1.3 testing is still a mess with OpenSSL 1.1.1, sorry.  I have
updated the test suite just now to disable TLSv1.3 testing for most
people.  We need updates to Net::SSLeay (the latest upstream has the
patch) and IO::Socket::SSL, but the latter is not patched upstream, so 
I

can't make an accurate test for that yet.

At worst, forcibly testing with:

  ./t/TEST -sslproto 'all -TLSv1.2'

should now be possible.

(If using an existing check-out of the test suite don't forget to 
re-run

"make" before running ./t/TEST -conf to regenerate the config...)

Let me know if that's not made any difference for you.

I don't know why t/modules/http2.t is failing but I see that here too.


Thanks Joe and Bill.

Yep, when flipping back over to OpenSSL 1.1.0i, everything works A-OK. 
Even the H2 failure irons itself out. It's a bummer to hear TLS 1.3 
testing isn't up to snuff with this being the major feature of the 
release.


I also just wiped the environment, recompiled everything from scratch 
(same versions noted below) and reran the tests with the latest test 
framework and see that the recent changes to the framework leave only 
the failing h2 test (which doesn't happen w/ 1.1.0i). So... I think it 
was indeed localized to the test framework.


I'm also happy to see the H2 EOS fix in, too!

So... I think I'm content with the results and am ready to T!



Regards, Joe




Test Summary Report
---
t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
  Parse errors: Bad plan.  You planned 52 tests but ran 24.
t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  3-4
t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
  Failed tests:  2-3
t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
  Failed tests:  16-30
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
  Failed tests:  1-4
t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  3
t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  2, 5, 9
t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
  Failed tests:  1-83
t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  2
Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 
cusr

11.08 csys = 61.68 CPU)


Versions at play were:
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"


Anything look obviously crazy/wrong?

--
Daniel Ruggeri

On 2018-10-09 06:36, Daniel Ruggeri wrote:
> Hi, all;
>  Barring any major disagreement in the next several hours, I intend to
> T our next version later today or early tomorrow.
>
> Hooray for TLS 1.3!
> --
> Daniel Ruggeri


--
Daniel Ruggeri

Re: svn commit: r1843476 - /httpd/test/framework/trunk/t/ssl/ocsp.t

[William A Rowe Jr]

Huh?!?

$ openssl list-standard-commands
Invalid command 'list-standard-commands'; type "help" for a list.
$ openssl version
OpenSSL 1.1.0i-fips  14 Aug 2018



On Wed, Oct 10, 2018 at 12:18 PM  wrote:

> Author: jim
> Date: Wed Oct 10 17:18:27 2018
> New Revision: 1843476
>
> URL: http://svn.apache.org/viewvc?rev=1843476=rev
> Log:
> Use this cli command
>
> Modified:
> httpd/test/framework/trunk/t/ssl/ocsp.t
>
> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
> URL:
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843476=1843475=1843476=diff
>
> ==
> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:18:27 2018
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
>  # support in earlier versions without messing around with stderr
>  my $openssl = Apache::TestSSLCA::openssl();
>  if (!have_min_apache_version('2.4.26')
> -or `$openssl list -commands 2>/dev/null` !~ /ocsp/) {
> +or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
>  print "1..0 # skip: No OpenSSL or mod_ssl OCSP support";
>  exit 0;
>  }
>
>
>

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

Just in case of tl;dr:

The fix is proposed for backport, 1 vote is missing, would be nice to have in 
2.4.36

Thanks, Stefan

> Am 10.10.2018 um 10:47 schrieb Stefan Eissing :
> 
> I have a report of h2 missing an EOS flag on certain conditions related to 
> php served resources. Trying to reproduce. First such report came before 
> 2.4.35. I'd say, if I cannot progress on this today, then please go ahead and 
> tag. Will report later.
> 
> -Stefan
> 
>> Am 09.10.2018 um 22:29 schrieb Daniel Ruggeri :
>> 
>> Hi, all;
>>  I ran through my usual testing routine, this time with OpenSSL 1.1.1, but 
>> found several test failures. In the past, these issues have been isolated to 
>> my environment so I just wanted to drop a line to see if anyone has run the 
>> test suite against 2.4.x lately and can corroborate this result? If not, I 
>> can debug my environment.
>> 
>> Test Summary Report
>> ---
>> t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
>> Parse errors: Bad plan.  You planned 52 tests but ran 24.
>> t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
>> Failed tests:  3-4
>> t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
>> Failed tests:  2-3
>> t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
>> Failed tests:  16-30
>> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
>> Failed tests:  1-4
>> t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
>> Failed tests:  2-3
>> t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
>> Failed test:  3
>> t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
>> Failed tests:  2, 5, 9
>> t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
>> Failed tests:  1-83
>> t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
>> Failed test:  2
>> Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 cusr 
>> 11.08 csys = 61.68 CPU)
>> 
>> 
>> Versions at play were:
>> 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"
>> 
>> 
>> Anything look obviously crazy/wrong?
>> 
>> -- 
>> Daniel Ruggeri
>> 
>> On 2018-10-09 06:36, Daniel Ruggeri wrote:
>>> Hi, all;
>>> Barring any major disagreement in the next several hours, I intend to
>>> T our next version later today or early tomorrow.
>>> Hooray for TLS 1.3!
>>> --
>>> Daniel Ruggeri
> 

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

> Am 10.10.2018 um 15:06 schrieb Joe Orton :
> 
> I believe that t/modules/http2.t is dying in this:
> 
>my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
>*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {
> 
> piece of magic which I don't understand but possibly needs updating for 
> TLSv1.3? Session handling is different now... everything is broken.

I think there was no official way to add SNI to AnyEvent and I had to hack 
this. Unless anyone has another suggestion, I am in favour of removing the 
t/modules/http2.t again.

I have started to convert the existing h2 testsuite in 
https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk from shell scripts to 
pytest in the github repro. I have a pytest suite for mod_md also in its 
github. 

My hope is to, one day, make those part of a httpd test suite, probably just by 
combining the separate standalone ones. Then we could have 'modules/ABC/test' 
as optional part of a module with a defined way to trigger them.

Since each pytest module starts httpd and stops it again, the config files can 
be very local to the tests being done. That makes them quite easy to understand 
and startup times very short.

As for the certificates on a test host, I'd like to use 
https://github.com/FiloSottile/mkcert. That runs on MacOS, Linux and Windows. 
Not sure about the other OS we run on. More and more clients refuse to drop 
certificate verification or at least generate verbose warnings, so mkcert seems 
a good way to go.

-Stefan

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

Thanks, Joe. Tried to get it running on my Ubuntu 18.04 LTS image, but there I 
cannot even get the necessary Perl modules installed via CPAN.

I give up.

> Am 10.10.2018 um 15:06 schrieb Joe Orton :
> 
> On Wed, Oct 10, 2018 at 02:52:13PM +0200, Stefan Eissing wrote:
>> I cannot get the test framework to properly initialise any longer (MacOS 
>> 10.14):
>> 
>>> t/TEST -clean
>>> t/TEST
>> [warning] setting ulimit to allow core files
>> ulimit -c unlimited; /usr/bin/perl 
>> /Users/sei/projects/httpd/test/framework/trunk/t/TEST
>> [warning] generating SSL CA for asf
>> [   info] openssl req -new -x509 -keyout keys/ca.pem -out certs/ca.crt -days 
>> 365 -config conf/ca.cnf
>> Generating a 2048 bit RSA private key
>> ..+++
>> ..+++
>> writing new private key to 'keys/ca.pem'
>> -
>> problems making Certificate Request
>> 4620047980:error:0DFFF07A:asn1 encoding routines:CRYPTO_internal:first num 
>> too 
>> large:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.200.4/libressl-2.6/crypto/asn1/a_object.c:112:
>> 4620047980:error:0BFFF077:x509 certificate routines:CRYPTO_internal:invalid 
>> field 
>> name:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.200.4/libressl-2.6/crypto/x509/x509name.c:303:name=Email
>> [  error] configure() has failed:
>> system req -new -x509 -keyout keys/ca.pem -out certs/ca.crt -days 365 
>> -config conf/ca.cnf failed (exit status=1) at 
>> /Users/sei/projects/httpd/test/framework/trunk/Apache-Test/lib/Apache/TestSSLCA.pm
>>  line 216.
>> 
>> [warning] forcing Apache::TestConfig object save
>> [warning] run 't/TEST -clean' to clean up before continuing
>> 
>> Any tips?
> 
> Did you start from a fresh checkout?  I can't remember seeing that 
> particular error before but the whole thing is fragile as heck.
> 
> I believe that t/modules/http2.t is dying in this:
> 
>my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
>*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {
> 
> piece of magic which I don't understand but possibly needs updating for 
> TLSv1.3? Session handling is different now... everything is broken.
> 
> The last output I get is:
> 
> ok 24
> test case: TC0001, expecting 200: GET https://localhost:8557/
> test case: VHOST000, expecting 200: GET https://localhost:8557/
> setting host_name to localhost:8557
> Failed 28/52 subtests 
> 
> so it looks like the perl script died completely somewhere around that 
> point.  My fedora 29 chroot has:
> 
> # rpm -q perl-AnyEvent openssl perl-interpreter
> perl-AnyEvent-7.14-7.fc29.x86_64
> openssl-1.1.1-3.fc29.x86_64
> perl-interpreter-5.28.0-423.fc29.x86_64
> 
> fwiw.

Re: NOTICE: Intent to T 2.4.36

[Joe Orton]

On Wed, Oct 10, 2018 at 02:52:13PM +0200, Stefan Eissing wrote:
> I cannot get the test framework to properly initialise any longer (MacOS 
> 10.14):
> 
> > t/TEST -clean
> > t/TEST
> [warning] setting ulimit to allow core files
> ulimit -c unlimited; /usr/bin/perl 
> /Users/sei/projects/httpd/test/framework/trunk/t/TEST
> [warning] generating SSL CA for asf
> [   info] openssl req -new -x509 -keyout keys/ca.pem -out certs/ca.crt -days 
> 365 -config conf/ca.cnf
> Generating a 2048 bit RSA private key
> ..+++
> ..+++
> writing new private key to 'keys/ca.pem'
> -
> problems making Certificate Request
> 4620047980:error:0DFFF07A:asn1 encoding routines:CRYPTO_internal:first num 
> too 
> large:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.200.4/libressl-2.6/crypto/asn1/a_object.c:112:
> 4620047980:error:0BFFF077:x509 certificate routines:CRYPTO_internal:invalid 
> field 
> name:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.200.4/libressl-2.6/crypto/x509/x509name.c:303:name=Email
> [  error] configure() has failed:
> system req -new -x509 -keyout keys/ca.pem -out certs/ca.crt -days 365 -config 
> conf/ca.cnf failed (exit status=1) at 
> /Users/sei/projects/httpd/test/framework/trunk/Apache-Test/lib/Apache/TestSSLCA.pm
>  line 216.
> 
> [warning] forcing Apache::TestConfig object save
> [warning] run 't/TEST -clean' to clean up before continuing
> 
> Any tips?

Did you start from a fresh checkout?  I can't remember seeing that 
particular error before but the whole thing is fragile as heck.

I believe that t/modules/http2.t is dying in this:

my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {

piece of magic which I don't understand but possibly needs updating for 
TLSv1.3? Session handling is different now... everything is broken.

The last output I get is:

ok 24
test case: TC0001, expecting 200: GET https://localhost:8557/
test case: VHOST000, expecting 200: GET https://localhost:8557/
setting host_name to localhost:8557
Failed 28/52 subtests 

so it looks like the perl script died completely somewhere around that 
point.  My fedora 29 chroot has:

# rpm -q perl-AnyEvent openssl perl-interpreter
perl-AnyEvent-7.14-7.fc29.x86_64
openssl-1.1.1-3.fc29.x86_64
perl-interpreter-5.28.0-423.fc29.x86_64

fwiw.

Re: NOTICE: Intent to T 2.4.36

[Joe Orton]

On Tue, Oct 09, 2018 at 03:29:49PM -0500, Daniel Ruggeri wrote:
> Hi, all;
>I ran through my usual testing routine, this time with OpenSSL 1.1.1, but
> found several test failures. In the past, these issues have been isolated to
> my environment so I just wanted to drop a line to see if anyone has run the
> test suite against 2.4.x lately and can corroborate this result? If not, I
> can debug my environment.

TLSv1.3 testing is still a mess with OpenSSL 1.1.1, sorry.  I have 
updated the test suite just now to disable TLSv1.3 testing for most 
people.  We need updates to Net::SSLeay (the latest upstream has the 
patch) and IO::Socket::SSL, but the latter is not patched upstream, so I 
can't make an accurate test for that yet.

At worst, forcibly testing with:

  ./t/TEST -sslproto 'all -TLSv1.2'

should now be possible.

(If using an existing check-out of the test suite don't forget to re-run 
"make" before running ./t/TEST -conf to regenerate the config...)

Let me know if that's not made any difference for you.

I don't know why t/modules/http2.t is failing but I see that here too.

Regards, Joe


> 
> Test Summary Report
> ---
> t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
>   Parse errors: Bad plan.  You planned 52 tests but ran 24.
> t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
>   Failed tests:  3-4
> t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
>   Failed tests:  2-3
> t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
>   Failed tests:  16-30
> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
>   Failed tests:  1-4
> t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
>   Failed tests:  2-3
> t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
>   Failed test:  3
> t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
>   Failed tests:  2, 5, 9
> t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
>   Failed tests:  1-83
> t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
>   Failed test:  2
> Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 cusr
> 11.08 csys = 61.68 CPU)
> 
> 
> Versions at play were:
> 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"
> 
> 
> Anything look obviously crazy/wrong?
> 
> -- 
> Daniel Ruggeri
> 
> On 2018-10-09 06:36, Daniel Ruggeri wrote:
> > Hi, all;
> >  Barring any major disagreement in the next several hours, I intend to
> > T our next version later today or early tomorrow.
> > 
> > Hooray for TLS 1.3!
> > --
> > Daniel Ruggeri

Re: NOTICE: Intent to T 2.4.36

[Stefan Eissing]

I have a report of h2 missing an EOS flag on certain conditions related to php 
served resources. Trying to reproduce. First such report came before 2.4.35. 
I'd say, if I cannot progress on this today, then please go ahead and tag. Will 
report later.

-Stefan

> Am 09.10.2018 um 22:29 schrieb Daniel Ruggeri :
> 
> Hi, all;
>   I ran through my usual testing routine, this time with OpenSSL 1.1.1, but 
> found several test failures. In the past, these issues have been isolated to 
> my environment so I just wanted to drop a line to see if anyone has run the 
> test suite against 2.4.x lately and can corroborate this result? If not, I 
> can debug my environment.
> 
> Test Summary Report
> ---
> t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0)
>  Parse errors: Bad plan.  You planned 52 tests but ran 24.
> t/security/CVE-2009-3555.t(Wstat: 0 Tests: 4 Failed: 2)
>  Failed tests:  3-4
> t/ssl/basicauth.t (Wstat: 0 Tests: 4 Failed: 2)
>  Failed tests:  2-3
> t/ssl/env.t   (Wstat: 0 Tests: 30 Failed: 15)
>  Failed tests:  16-30
> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 4)
>  Failed tests:  1-4
> t/ssl/fakeauth.t  (Wstat: 0 Tests: 3 Failed: 2)
>  Failed tests:  2-3
> t/ssl/ocsp.t  (Wstat: 0 Tests: 3 Failed: 1)
>  Failed test:  3
> t/ssl/require.t   (Wstat: 0 Tests: 10 Failed: 3)
>  Failed tests:  2, 5, 9
> t/ssl/varlookup.t (Wstat: 0 Tests: 83 Failed: 83)
>  Failed tests:  1-83
> t/ssl/verify.t(Wstat: 0 Tests: 3 Failed: 1)
>  Failed test:  2
> Files=186, Tests=8857, 101 wallclock secs ( 1.86 usr  0.28 sys + 48.46 cusr 
> 11.08 csys = 61.68 CPU)
> 
> 
> Versions at play were:
> 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"
> 
> 
> Anything look obviously crazy/wrong?
> 
> -- 
> Daniel Ruggeri
> 
> On 2018-10-09 06:36, Daniel Ruggeri wrote:
>> Hi, all;
>> Barring any major disagreement in the next several hours, I intend to
>> T our next version later today or early tomorrow.
>> Hooray for TLS 1.3!
>> --
>> Daniel Ruggeri