Re: Stale BZ Bug Tracker reports

[William A Rowe Jr]

To keep this thread moving (additional feedback is welcomed and
appreciated)...

On Thu, Nov 1, 2018 at 5:03 AM Marion & Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:
>
> Le 31/10/2018 à 21:52, William A Rowe Jr a écrit :
> >
> > There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or
NEEDINFO with no Resolution.
> >
> > For these bugs I believe we should simply close them with a message
that this is a mass-update, that the version is beyond EOL, and a request
for reporters/observers to retest and reopen with the supported version
number if they are still reproducible using a modern 2.4.x version. But I
can't determine the best Status/Resolution code... suggestions?
>
> +1
> IMHO, the best status would be CLOSED/WONTFIX. Maybe a new Keyword such
as TooOldAndInactive to ease finding such mass-update?
> Or ask for a new status TOO_OLD (but I'm not sure it would really be that
useful)

I agree a keyword MassUpdate would be helpful to later identify all tickets
closed in any automated way.

WONTFIX doesn't seem to fit; 1) a subset of these have been FIXED,  2) a
subset are INVALID, 3) there is a WONTFIX subset (applying to 2.5.x as
well.)

I think a new status is right, perhaps RESOLVED/FUTURE is the best course
for the mass-change of these defects that are unlikely to be reviewed by
the project community in their present state. They are in fact NEEDINFO (we
need info that a) there is a bug and b) it still exists), but since we
don't have that as a closure state, RESOLVED/FUTURE seems like the best
catch-all. Of course this label is no longer endorsed by the bugzilla team,
but they don't seem to have substituted anything else;
https://bugs.eclipse.org/bugs/show_bug.cgi?id=178923

So I'd read this as the bug needs to be reproduced with a "later" version
of httpd, and is subject to reconsideration "later" on further review, but
may have already been resolved in a "later" release.

> > There are 69 bugs of status REOPENED, and 20 of status ASSIGNED (?).
These should likely be reviewed by hand and either ACCEPTED against
2.4-HEAD, tagged NEEDINFO with a request to re-review (after mass-cleanup
of NEEDINFO above), or closed as above with an invitation to retest and
reopen.
>
> +1, after by-hand review, as proposed.
>
> > There are 255 bugs of Status NEW from 2.4.1-2.4.17, releases which are
over three years old. For these, the best resolution is probably NEEDINFO.
>
> -1.
> Not sure NEEDINFO is fine for these ones. We should set NEEDINFO after by
hand review, if we NEEDINFO. Or close it if invalid, or leave it as is if
it looks right but no one has looked at it.
> The reporter has done his job. He has reported what he thinks is enough.
WE should provide an answer or ask for more details.

You are signing up to reproduce and validate that all of the bugs still
exist in the current tree?  I agree that reviewing these 255 bugs would be
a noble goal, but who is signing up to the task? Will we simply wait until
2.6.0 has been around for a year or two and then reap all the bugs as
described above? I propose we do ask for more details, specifically, that
their reported bug still exists, on the presumption it is a bug.

This merits further discussion, and I'm not moving ahead till we've come to
some concensus, but we would do well to decide what we are doing here with
the group of 3 to 8 year old flavors of 2.4.x.

> > And there are 38 2.4.x NEEDINFO bugs, most of which can likely be
closed for good as INVALID under a manual review.
>
> +1 if older than, let say, 1 year?
> The number is small, they could also be doubled check by hand. But is is
likely, that it would end as INVALID because the analysis has already been
done, and the reporter does not seem to be interested to answer.

This number is small, and I am proposing this is a manual effort to either
bump the version number perhaps with help from a NEEDINFO request, or
closing as INVALID where they are actually not bugs.

> > I'm thinking of generic comment which would read (2nd paragraph for
2.0-2.3.x only);
> >
> > """
> > Please help us to refine our list of open and current defects. This is
a mass update of older Bugzilla reports which reflect user error, already
resolved defects, and still-existing defects in httpd.
>
> [...]. This is a mass update of old and inactive reports [...]
>
> > As repeatedly announced, the Apache HTTP Server Project has
discontinued all development and patch review of the 2.2.x series of
releases. The final release 2.2.34 was published in July 2017, and no
further evaluation of bug reports or security risks will be considered or
published for 2.2.x releases.
> >
> > If your report represented a question or confusion about how to use an
httpd feature, an unexpected server behavior, problems building or
ins

Stale BZ Bug Tracker reports

[William A Rowe Jr]

There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or
NEEDINFO with no Resolution.

For these bugs I believe we should simply close them with a message that
this is a mass-update, that the version is beyond EOL, and a request for
reporters/observers to retest and reopen with the supported version number
if they are still reproducible using a modern 2.4.x version. But I can't
determine the best Status/Resolution code... suggestions?

There are 69 bugs of status REOPENED, and 20 of status ASSIGNED (?). These
should likely be reviewed by hand and either ACCEPTED against 2.4-HEAD,
tagged NEEDINFO with a request to re-review (after mass-cleanup of NEEDINFO
above), or closed as above with an invitation to retest and reopen.

There are 255 bugs of Status NEW from 2.4.1-2.4.17, releases which are over
three years old. For these, the best resolution is probably NEEDINFO. And
there are 38 2.4.x NEEDINFO bugs, most of which can likely be closed for
good as INVALID under a manual review.

I'm thinking of generic comment which would read (2nd paragraph for
2.0-2.3.x only);

"""
Please help us to refine our list of open and current defects. This is a
mass update of older Bugzilla reports which reflect user error, already
resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued
all development and patch review of the 2.2.x series of releases. The final
release 2.2.34 was published in July 2017, and no further evaluation of bug
reports or security risks will be considered or published for 2.2.x
releases.
If your report represented a question or confusion about how to use an
httpd feature, an unexpected server behavior, problems building or
installing httpd, or working with an external component (a third party
module, browser etc.) we ask you to start by bringing your question to the
User Support and Discussion mailing list, see [
https://httpd.apache.org/lists.html#http-users] for details. Include a link
to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd, we ask that you retest using
a modern httpd release (2.4.33 or later) released in the past year. If it
can be reproduced, please reopen this bug and change the Version field
above to the httpd version you have reconfirmed with.

Your help in identifying only current defects in the httpd server software
is greatly appreciated.
"""

Comments, suggestions and other feedback before we proceed to take a broad
scythe to the stale reports?

Re: dual port 80 443

[William A Rowe Jr]

This doesn't work correctly in 2.4.x... but needs to be fixed in trunk for
2.next.

The problem is that our connection rec structure defers to the vhost
structure
for the port assignment, a 1:1 mapping. We need to break this and trust the
vhost is 1:many, and the connection rec records which inbound port the
request was accepted on. And then tweak everywhere in httpd core modules
and encourage third party authors to adopt the new convention.



On Fri, Oct 26, 2018 at 1:49 AM Edwardo Garcia  wrote:

> Hi,
> We have only few domains to manage, usually either http or https, but we
> have lately had requests for both (we  know defeat purpose but customer
> knows what they want and they no take monetary or personal informations on
> website)
>
> I know this works with duplication of virtualhosts, but should it also
> work with
>  [2001:1:1:1::1]:443>
> ...
> 
> To avoid duplicating?
> nginx does not seem to have this limitation, so I'm surprised httpd2 does.
>
> If I omit ports, it will errors on http  if ssl engine on.
>
> or have I overlooked option?
>
> Willy
>
>

Re: Apache Win crashes with mod_md with no Applink sim

[William A Rowe Jr]

On Fri, Oct 19, 2018 at 6:15 AM Steffen  wrote:

> I changed the subject ( was Re: svn commit: r1748461 - in
> /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c)
>
> William A Rowe Jr wrote: ...mod_php or other weirdness 
>
> What do you mean by weirdness ? Google translate shows it can be a bad
> word.
>

No slight intended; I'm speaking of loading binaries in-process which use
BIO
resource handles from libcrypto (libeay32 or whatever it was called) where
the
binaries arrive from different VC compilers or are built using different
memory
models (/MD vs /MT).

So in the case that a user downloads perl, php, lua, etc built against
different
VC flavors by different open source projects, and loaded in-process
underneath
Apache.exe (httpd) binary, this stub is necessary. In the case that the
user is
loading these different environments and modules built with the same linkage
by the same compiler, this stub is not necessary (except as noted in some
broken flavors of openssl.)

I never talked about a mod-php, as pointed before applink is needed for
> phpXapache2_4.dll.  The Microsoft PHP team asked (and still) me to use the
> sim, they had some serious reports. Quote PHP team: Yeah, now it turned
> out, that the SPKI functionality in PHP requires this shim to be in. The
> functionality is available since PHP 5.6 and coupled with Apache could
> result an unexpected process exit without the solution mentioned in the
> OpenSSL FAQ compiled in.
>

phpXapache2_4.dll is the apache php module by another name.

"Some reports" may still correspond to the openssl 1.0.2g bug mentioned
in the thread. Or, what is likely going on is that SPKI binaries were
compiled
against OpenSSL using a different version of the compiler.


> An other example:
> mod_md errors when no applink sim, in the past AL has also reports of the
> issue.
> Just tested again with AH httpd-2.4.35 with  Openssl 110i, and no
> surprise, is does not even start, see below. Replacing the httpd.exe from
> AL with the sim  all fine. Looks like a module using ssl needs the sim.
>

This makes sense if the OpenSSL 1.1.0i is built with a different compiler
and memory model. If it is built with the same, this should be reported to
the openssl project as a bug. The BIO interfaces are used by mod_md,
so this is expected. This is likely the 1.0.2g bug.

In any case, the usage of apache allows for arbitrary modules to be loaded
and in the binaries scenario. It seems the stub should be added in
Apache.exe
whenever mod_ssl/mod_md/aprutil have been linked to libcrypto.

This all goes against your earlier comment to me not to add this patch to
the
Apache.exe binary for building on Windows. You are reversing your objection?

I've seen another objection which suggests that "Apache.exe isn't even
linked to OpenSSL." What's important here is that the stub does not
invoke or link to OpenSSL at all. It simply provides an array of entry
points
to the current Visual Studio C Runtime, which Apache.exe is linked to,
as a shared, exported symbol that can be found by any of the .dll code
loaded in process.

If so, based especially on mod_md and the possibility of users loading
a flavor of the libcrypto/libssl libraries which weren't created by the same
Visual Studio + memory model as when building Apache, it seems we
should proceed with patching the Apache/httpd top level binary.

Re: OCSP in 2.4 with OpenSSL 0.9.8(zh)

[William A Rowe Jr]

On Thu, Oct 18, 2018 at 8:01 AM William A Rowe Jr 
wrote:

> On Thu, Oct 18, 2018 at 7:27 AM Rainer Jung 
> wrote:
>
>> I get test suite failures for t/ssl/ocsp.t when the server is build
>> against OpenSSL 0.9.8zh. I can't judge on whether that is expected for
>> OpenSSL 0.9.8.
>
>
> A very good question, and I can't either. Can you confirm your openssl
> command line tool has the `openssl ocsp` mini-responder by posting the
> results of an `openssl ocsp -help` invocation?
>
> It might be that we never handled ocsp here.
>
> It might also be that your $openssl resolves to a system tool which is not
> in sync with the openssl tested in httpd. You may want to override that
> value.
>

To override, it seems you need to use an envvar;

./Apache-Test/lib/Apache/TestSSLCA.pm:

my $openssl = $ENV{APACHE_TEST_OPENSSL_CMD} || 'openssl';

We offer no t/TEST -openssl= option.

Re: svn commit: r1844231 - in /httpd/httpd/branches/2.4.x/docs/manual: ./ faq/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ style/ style/lang/ style/xsl/util/ vhosts/

[William A Rowe Jr]

Please never do this again on the eve of a release, it is not easily
reviewed
and is very inconsiderate to the RM. This doesn't meet the idea of minimal
scope, or the spirit of docs@h.a.o being exempt from backport review(!)

That said...

https://svn.apache.org/viewvc?limit_changes=0=revision=1844231

httpd/httpd/branches/2.4.x/docs/manual/style/lang/fr.xml
httpd/httpd/branches/2.4.x/docs/manual/style/lang-targets.xml
httpd/httpd/branches/2.4.x/docs/manual/style/manual.fr.xsl
httpd/httpd/branches/2.4.x/docs/manual/style/xsl/util/designations.xml

These were sources, and MUST NOT be changed on a regeneration commit!

Changed paths: 458

This corresponds to 454 non-/style/ changes, which have a 2:1 effective
count
to update the map file (.html) and .html.fr.utf8 result files.

However there are a couple other quirks,

httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml.meta
httpd/httpd/branches/2.4.x/docs/manual/programs/ab.xml.meta

Each of these updated the 'fr' translation from outdated to current. That
could
have been done as a distinct pass.

I count an effective 226 new files, so contrasting to

https://svn.apache.org/viewvc?limit_changes=0=revision=1844229

Author: lgentis
Date: Thu Oct 18 11:20:54 2018
New Revision: 1844229

URL: http://svn.apache.org/viewvc?rev=1844229=rev
Log:
fr doc : deleting ISO-8859-1 html files.

Changed paths: 226

It is reasonable to conclude that this patch was correct.

As I understand it, relying on the ".html" named var content map files,
there were no further changes required to docs/conf/extra/
httpd-manual.conf.in - correct? It all simply resolves itself based on the
content-language match, and the codepage/charset were incidental.

This looks correct for release, but wasn't how I wanted to spend the
morning. Hoping to save some others from the same exercise.


On Thu, Oct 18, 2018 at 6:38 AM  wrote:

> Author: lgentis
> Date: Thu Oct 18 11:38:42 2018
> New Revision: 1844231
>
> URL: http://svn.apache.org/viewvc?rev=1844231=rev
> Log:
> fr doc : adding UTF-8 html files.
>
>
> [This commit notification would consist of 79 parts,
> which exceeds the limit of 50 ones, so it was shortened to the summary.]
>

Re: OCSP in 2.4 with OpenSSL 0.9.8(zh)

[William A Rowe Jr]

On Thu, Oct 18, 2018 at 7:27 AM Rainer Jung  wrote:

> I get test suite failures for t/ssl/ocsp.t when the server is build
> against OpenSSL 0.9.8zh. I can't judge on whether that is expected for
> OpenSSL 0.9.8.


A very good question, and I can't either. Can you confirm your openssl
command line tool has the `openssl ocsp` mini-responder by posting the
results of an `openssl ocsp -help` invocation?

It might be that we never handled ocsp here.

It might also be that your $openssl resolves to a system tool which is not
in sync with the openssl tested in httpd. You may want to override that
value.

And may be httpd never supported the ocsp directives with 0.9.8, so our
tests for the micro responder and the version of httpd alone are not
sufficient.

Re: Keeping backported CHANGES in trunk CHANGES?

[William A Rowe Jr]

On Thu, Oct 18, 2018 at 5:21 AM Rainer Jung  wrote:

> In trunk we do now have a 2.5 CHANGES file, ie. the file contains
> entries for 2.5.0-alpha and the entries above those under the 2.5.1
> heading.
>
> I think we should add entries under 2.5.1 even if things get likely
> backported and such items should no longer be removed when being
> backported. Before 2.5.0-alpha, that was just a candidate CHANGES file
> for the things not in 2.4.x, but now it should also document the changes
> after 2.5.0-alpha. Similar to how I think it was done while switching
> from 2.2 to 2.3/2.4.


That would make sense, note 2.5.0-alpha did not receive a successful
release vote, so we are still on the ground floor, so to speak.

We really need some logic to keep the two CHANGES files in-sync. The
end result, in 2.6.0, would be to have everything applicable listed as its
public/GA change from 2.4.x revision on, with everything strictly in the
alpha/beta 2.5.x change cycles listed under their respective update.

Re: [Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

[William A Rowe Jr]

On Thu, Oct 18, 2018 at 4:56 AM Rainer Jung  wrote:

> - The other one goes back to the other big refactoring which allowed to
> use SSLProxy* directives in  containers, first released in 2.4.32
> this year. It fixes a missing config merge (very small patch). This is
> not related to the OpenSSL 1.1.1 changes but is a small patch fixing a
> regression introduced a few months ago. I think it could go into 2.4.37,
> but would understand a more restricted approach.
>

I agree that reverting any now discovered/resolved regression falls under
the idea of a maintenance release scope, even one more narrowed to
"don't break the release 2x in a row" narrower scope.

Re: [NOTICE] Intent to T 2.4.37 - about 12:00 GMT tomorrow

[William A Rowe Jr]

https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/ is what will
be exported, ,/buildconf invoked, and then tarred up, if that helps you
anticipate the tag a day early. It shouldn't give any different hassles
than trunk.


On Wed, Oct 17, 2018, 13:31 Dennis Clarke  wrote:

> On 10/17/2018 02:24 PM, Daniel Ruggeri wrote:
> > On 2018-10-17 13:13, Dennis Clarke wrote:
> >> On 10/17/2018 07:41 AM, Daniel Ruggeri wrote:
> >>> Hi, all;
> >>> With the fix for detected OpenSSL 1.1.1 issues now backported to
> >>> 2.4.x, I would like to tag the next version of our venerable server
> >>> soon.
> >>>
> >>> I have already successfully completed the test suite against my
> >>> "latest sources" docker environment and am watching for any smoke
> >>> detected in [1]. Feeling good about this one :-)
> >>>
> >>> How about roughly 24 hours from now?
> >>>
> >>
> >> Can we get a tarball at https://dist.apache.org/repos/dist/dev/httpd/ ?
> >>
> >> Dennis
> >
> > Hi, Dennis;
> > Yes, of course. That gets pushed shortly after the tag occurs. An
> > email will be sent to this list immediately after. I anticipate that it
> > will be there no later than 13:00 GMT tomorrow.
> >
> > If you're interested in the details, feel free to check out the release
> > documentation here:
> > http://httpd.apache.org/dev/release.html
> >
>
> Thanks .. I just wanted to get a build going. Getting trunk to work well
> with tls 1.3 was no big deal. A few hoops to jump through. However 2.4.x
> seems to have been a holy pile of hoops.
>
> Dennis
>

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

On Fri, Oct 12, 2018 at 4:54 PM William A Rowe Jr 
wrote:

> Great, I'll proceed with changing ab.c to remove the hack, since it is
> unneeded when ab.c is compiled by the same toolchain as libcrypto.dll,
> isn't available in non-openssl distributions, and was deprecated in 1.1.1
> again.
>

Note, I'll only proceed to remove the hack from trunk. I see no reason to
make any cosmetic or build changes to 2.4.x branch. Any fallout to the
trunk change will be uncovered in alpha/beta review. If we are unwilling to
support the feature in httpd.exe we should not do so for ab.c either. (IIRC
there was some subtle lingering BIO usage from mod_ssl for the
initialization phase.)

Anyone who wants to enable the applink stub logic for mod_php or other
weirdness is welcome to patch that either by 1) adding the applink.c to
abs.exe and/or httpd.exe linkage, or the main() source file can #include
that "".

Anyone interested can proceed to patch both and provision applink.c when
> working with OpenSSL 1.1.1, so I don't need to raise a ticket at that
> project.
>

Regression #7396 <https://github.com/openssl/openssl/issues/7396> was fixed
with 92ebf6c
<https://github.com/openssl/openssl/commit/92ebf6c4c21ff4b41ba1fd69af74b2039e138114>
for
OpenSSL 1.1.1a. The oversight of dropping applink.c appears to have been
unintended.

Thanks to you all for your review and re-evaluation of the past and current
situations with OpenSSL.

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

[William A Rowe Jr]

To button this issue up, it's clear to me that Jim had transposed the
meaning of result values from posix commands, and that was the origin of
irrationality in this discussion.

Beyond the misunderstanding, the actual behavior of openssl in 1.0.x and
prior was inane, and led to Jim's confusion, and my earlier hint to add
-help would not have improved the situation.

On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung  wrote:

> Am 14.10.2018 um 21:59 schrieb William A Rowe Jr:
> > On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski  > <mailto:j...@jagunet.com>> wrote:
> >
> > All we are checking is the error code. Nothing else.
> >
> > % openssl version
> > OpenSSL 1.0.2p  14 Aug 2018
>

The result of this command, $? had returns a value 0, success.


> > % openssl ocsp 2>/dev/null
> > % print $?
> > 1
>

This result code is failure. A non-zero posix result code is failure.

See `man 3 system`.  (See also perldoc system, search for LIST to learn
that the result code is shifted 8 bits, returning 256 for '1'.)

> % openssl foo 2>/dev/null
> > % print $?
> > 0
>

This result code is success, return code 0, no error. An unrecognized verb
was not an error!?!


> > With 1.1.1, both return 1, but so what, we know that it has oscp.
>

With 1.1.0 and 1.1.1 the failure result code 1 is correct, as shown below.


> I can confirm this behavior for normal OpenSSL 1.0.2p.
>

I also confirm, and my apologies for presuming this was some fork's
behavior. OpenSSL 1.0.x behavior was truly incomprehensible as shown
below...

And worse, my suggested fix to jim was also erroneous, in 1.0.2 and prior
the ocsp -help flag is similarly treated as an error. Using 1.0.2 branch
(frozen/final) from git;

$ openssl version
OpenSSL 1.0.2l-dev  xx XXX 
$ echo $?
0
$ openssl foo
openssl:Error: 'foo' is an invalid command.

Standard commands
asn1parse caciphers   cms
[...]
$ echo $?
0
$ openssl ocsp
OCSP utility
Usage ocsp [options]
where options are
-out fileoutput filename
[...]
$ echo $?
1
$ openssl ocsp -help
OCSP utility
Usage ocsp [options]
where options are
-out fileoutput filename
[...]
$ echo $?
1

Success, success, failure, failure. Which makes no fricking sense, and this
was the case jim sought to solve for.

Once we are at 1.1.0, this all starts to right itself;

$ openssl version
OpenSSL 1.1.0i-fips  14 Aug 2018
$ echo $?
0
$ openssl foo
Invalid command 'foo'; type "help" for a list.
$ echo $?
1
$ openssl ocsp 2>&1
ocsp: Use -help for summary.
$ echo $?
1
$ openssl ocsp -help 2>&1
Usage: ocsp [options]
Valid options are:
 -help   Display this summary
 -out outfileOutput filename
[...]
$ echo $?
0

Success, failure, failure, success, as would be expected.

It's plainly obvious that the result code from openssl main() cannot be
trusted for evaluating features between 1.0.x and 1.1.x, and is the reason
Jim's patch was defective.

So we are back to testing the output of `openssl list -commands 2>&1`,
evaluating stdout on 1.1.x, and stderr on 1.0.x. Unless Jim's veto stands?

> On Mon, Oct 15, 2018 at 10:07 AM Jim Jagielski  wrote:
>>
>> -1 (veto)
>>
>> Please revert. 'list' is NOT a command and this causes OCSP to be
skipped.

On Mon, Oct 15, 2018 at 10:20 AM Jim Jagielski  wrote:
>
> Forget this. My patch works and is correct and handles the specific
situation which is noted in the test case itself related to older versions.
It is an IMPROVEMENT over what we currently have.

Your patch treated success as failure and failure as success.

Your patch had enabled ocsp always in 1.1.x because `openssl ocsp` always
returns failure. It was disabling the test when absent from 1.0.x because
`openssl ocsp` returned failure, while it enabled the test with 1.0.x
because `openssl {unknown}` returned success when unrecognized.

Your patch introduced a regression because ocsp in 1.1.x must not be tested
when configured no-ocsp; this was harmful.

My suggestion of `openssl ocsp -help` would not have fixed this, because
then the test would have been disabled in 1.1.x when ocsp was available,
and enabled when ocsp was absent. However, using a valid command would have
helped identify the underlying logic error.

Joe's original code enabled ocsp correctly in 1.1.x because `openssl list
-commands` works, and the /ocsp/ string is found. Joe's original code never
enabled the test in 1.0.2, which was mostly harmless, but less effective.

My patch to Joe's original code works because `openssl list -commands`
fails so the command list is emitted to stderr, where we now detect /ocsp/.

> The sole reason why Bill doesn't like it is because *I* committed it.

By now, we should agree that this tantrum was uncalled for, in light of
these 

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

[William A Rowe Jr]

On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke  wrote:

>
> As a red herring that illustrates how oddball the situation could get :
>
> $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
> OpenSSL 0.9.7d 17 Mar 2004
> [...]
> Segmentation Fault(coredump)
>

I think we can safely ignore OpenSSL 0.9.7 as the final release was over 11
years ago.

Right now, only 1.1.1, 1.1.0 (12 month EOL clock started), and 1.0.2
(through 2019) are recognized by the OpenSSL project.

The 0.9.8 will only be encountered on rusting RHEL 5 (mainstream EOL a year
ago in spring) and similarly ancient installations across other
os/architectures. 1.0.0 only saw the light of day in broad adoption via
SLES 11 (mainstream EOL spring next year). There are a good number of 1.0.1
installations lingering around... everything shipped between and including
RHEL 6 and RHEL 7 including SLES 12 and Ubuntu 12.04 and 14.04 shipped with
that flavor.

Breaking 1.0.1 support would seem unwise, but we probably should start
ignoring 0.9.8 and 1.0.0 for all practical purposes.

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

[William A Rowe Jr]

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

> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
>
> @@ -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-standard-commands 2>/dev/null` !~ /ocsp/) {
> +or system("$openssl ocsp 2>/dev/null") == 0) {
>  print "1..0 # skip: No OpenSSL or mod_ssl OCSP support";
>  exit 0;
>  }
>

I think I know where the confusion is. system() returns 0 for success, and
the non-zero result code from invocation on failure.

You are testing whether `openssl ocsp` succeeds, skipping the test on
success and running the test on failure.

You meant to test whether `openssl ocsp` failed (non-zero), to skip the test

If you replace your test with system("$openssl ocsp -help 2>/dev/null") ==
0 you will observe that it goes haywire, because that command is valid when
ocsp is enabled.

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

[William A Rowe Jr]

I see 'ocsp' in both lists, and 2>&1 redirects stderr to stdout
unambiguously,
resulting in correct evaluation of the `openssl list 2>&1` ~! /ocsp/ match.

I will proceed with your veto to remove my " 2>&1" addition, restoring
the original test by jorton, if you would like, and leave this file to
others
willing to solve it for the entire developer community and to conduct
themselves appropriately, and we can take our hands off this file.

Or you may rescind your veto if this passes your evaluation.

His test did not necessarily pass the stderr results for regex evaluation,
leaving this compatible with OpenSSL 1.1.0+ only.

You can use
perl -e 'print "nope\n" if (`openssl list -help 2>&1` !~ /ocsp/);'
to evaluate my logic, and repeat while omitting the 2>&1 redirection
to evaluate jorton's original logic.


On Mon, Oct 15, 2018 at 10:07 AM Jim Jagielski  wrote:

> -1 (veto)
>
> Please revert. 'list' is NOT a command and this causes OCSP to be skipped.
>
> % openssl version
> OpenSSL 1.0.2p  14 Aug 2018
> % openssl list -commands
> openssl:Error: 'list' is an invalid command.
>
> Standard commands
> asn1parse caciphers   cms
> crl   crl2pkcs7 dgst  dh
> dhparam   dsa   dsaparam  ec
> ecparam   enc   engineerrstr
> gendh gendsagenpkey   genrsa
> nseq  ocsp  passwdpkcs12
> pkcs7 pkcs8 pkey  pkeyparam
> pkeyutl   prime rand  req
> rsa   rsautls_client  s_server
> s_timesess_id   smime speed
> spkac srp   tsverify
> version   x509
>
> Message Digest commands (see the `dgst' command for more details)
> md4   md5   mdc2  rmd160
> sha   sha1
>
> Cipher commands (see the `enc' command for more details)
> aes-128-cbc   aes-128-ecb   aes-192-cbc   aes-192-ecb
> aes-256-cbc   aes-256-ecb   base64bf
> bf-cbcbf-cfbbf-ecbbf-ofb
> camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  camellia-192-ecb
> camellia-256-cbc  camellia-256-ecb  cast  cast-cbc
> cast5-cbc cast5-cfb cast5-ecb cast5-ofb
> des   des-cbc   des-cfb   des-ecb
> des-ede   des-ede-cbc   des-ede-cfb   des-ede-ofb
> des-ede3  des-ede3-cbc  des-ede3-cfb  des-ede3-ofb
> des-ofb   des3  desx  idea
> idea-cbc  idea-cfb  idea-ecb  idea-ofb
> rc2   rc2-40-cbcrc2-64-cbcrc2-cbc
> rc2-cfb   rc2-ecb   rc2-ofb   rc4
> rc4-40seed  seed-cbc  seed-cfb
> seed-ecb  seed-ofb  zlib
>
>
> % openssl version
> OpenSSL 1.0.1e-fips 11 Feb 2013
> % openssl list -commands
> openssl:Error: 'list' is an invalid command.
>
> Standard commands
> asn1parse caciphers   cms
> crl   crl2pkcs7 dgst  dh
> dhparam   dsa   dsaparam  ec
> ecparam   enc   engineerrstr
> gendh gendsagenpkey   genrsa
> nseq  ocsp  passwdpkcs12
> pkcs7 pkcs8 pkey  pkeyparam
> pkeyutl   prime rand  req
> rsa   rsautls_client  s_server
> s_timesess_id   smime speed
> spkac tsverifyversion
> x509
>
> Message Digest commands (see the `dgst' command for more details)
> md2   md4   md5   rmd160
> sha   sha1
>
> Cipher commands (see the `enc' command for more details)
> aes-128-cbc   aes-128-ecb   aes-192-cbc   aes-192-ecb
> aes-256-cbc   aes-256-ecb   base64bf
> bf-cbcbf-cfbbf-ecbbf-ofb
> camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  camellia-192-ecb
> camellia-256-cbc  camellia-256-ecb  cast  cast-cbc
> cast5-cbc cast5-cfb cast5-ecb cast5-ofb
> des   des-cbc   des-cfb   des-ecb
> des-ede   des-ede-cbc   des-ede-cfb   des-ede-ofb
> des-ede3  des-ede3-cbc  des-ede3-cfb  des-ede3-ofb
> des-ofb   des3  desx  idea
> idea-cbc  idea-cfb  idea-ecb  idea-ofb
> rc2   rc2-40-cbcrc2-64-cbcrc2-cbc
> rc2-cfb   rc2-ecb   rc2-ofb   rc4
> rc4-40seed  seed-cbc  seed-cfb
> seed-ecb  

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

[William A Rowe Jr]

On Mon, Oct 15, 2018 at 10:10 AM Jim Jagielski  wrote:

> -1 (veto).
>

Correct. Your three commits against jorton's implementation are vetoed.
They were incorrect.


> 'list' is not a valid command.
>

You are wrong.

The list-standard-commands feature was dropped from OpenSSL 1.1.0 and
onwards.

https://www.openssl.org/docs/man1.1.0/apps/openssl.html

This doesn't cover OpenSSL 1.0.1 and 1.0.2, which exhibit the following
result;

$ LD_LIBRARY_PATH=./lib bin/openssl list -help 2>&1
openssl:Error: 'list' is an invalid command.

Standard commands
asn1parse caciphers   cms
crl   crl2pkcs7 dgst  dh
dhparam   dsa   dsaparam  ec
ecparam   enc   engineerrstr
gendh gendsagenpkey   genrsa
nseq  ocsp  passwdpkcs12
pkcs7 pkcs8 pkey  pkeyparam
pkeyutl   prime rand  req
rsa   rsautls_client  s_server
s_timesess_id   smime speed
spkac srp   tsverify
version   x509

Message Digest commands (see the `dgst' command for more details)
md4   md5   mdc2  rmd160
sha   sha1

Cipher commands (see the `enc' command for more details)
aes-128-cbc   aes-128-ecb   aes-192-cbc   aes-192-ecb
aes-256-cbc   aes-256-ecb   base64bf
bf-cbcbf-cfbbf-ecbbf-ofb
camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  camellia-192-ecb
camellia-256-cbc  camellia-256-ecb  cast  cast-cbc
cast5-cbc cast5-cfb cast5-ecb cast5-ofb
des   des-cbc   des-cfb   des-ecb
des-ede   des-ede-cbc   des-ede-cfb   des-ede-ofb
des-ede3  des-ede3-cbc  des-ede3-cfb  des-ede3-ofb
des-ofb   des3  desx  idea
idea-cbc  idea-cfb  idea-ecb  idea-ofb
rc2   rc2-40-cbcrc2-64-cbcrc2-cbc
rc2-cfb   rc2-ecb   rc2-ofb   rc4
rc4-40seed  seed-cbc  seed-cfb
seed-ecb  seed-ofb

While the result code is 1 (failure), using the `cmd` expression this
succeeds in providing the verb list.

It's helpful if we solve for all cases, and not one developer's specific
case.

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

[William A Rowe Jr]

On Mon, Oct 15, 2018 at 7:52 AM Jim Jagielski  wrote:

>
> And lest we forget, the orig version used:
>
> $openssl list -commands
>
> I have no idea what version of openssl supports 'list'. The result
> of which was that the ocsp testing was ALWAYS SKIPPED.
>

No, it wasn't skipped. We weren't looking at the result code, but examining
stdout, and jorton's original test was correct for everyone testing with
OpenSSL 1.1.0 and later.

It was also correct for 1.0.2 and prior if the perl implementation was
capturing stderr to stdout as a result of `openssl list`, because in these
versions, the entire command list is dumped to stderr for the unrecognized
verb 'list', until you redirected stderr to /dev/null. list -commands was
introduced in 1.1.0. Also 1.1.0 dropped the list-standard-commands.

A correct solution, now committed, uses the original implementation but now
lumps stderr into stdout. For all flavors of OpenSSL we have a verb list to
evaluate.

I still ask whether testing system("$openssl ocsp -help") for a positive
(0) result code makes sense, but that reintroduces a >/dev/null 2>&1 which
I'd pointed out earlier breaks win32 testing because NUL <> /dev/null on
that platform, so it seemed simpler just to revert to jorton's solve.

[Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

[William A Rowe Jr]

Like my beg for getting us to the 2.4.35 release tag, I'd like to propose
we keep patches to branches/2.4.x/ generally within the scope of
straightening out the remaining quirks related to the OpenSSL 1.1.1 API and
library behavior changes (and similar corrections for any alternate library
implementations such as LibreSSL or BoringSSL.)

This isn't a vote per se... just an ask whether we collectively want to
defer all potentially disruptive changes for a release following 2.4.next.
We can certainly resume with that next release on an expedited basis,
within a month or few (as opposed to waiting 6 months as has been typical.)

It appears that dropping in OpenSSL 1.1.1 into a previously working httpd
built against 1.1.0 is not the "plug and play" replacement that the OpenSSL
team originally envisioned, and deliberately building any previous release
of httpd against 1.1.1 is similarly broken.

Thoughts? Other concerns?

Re: [VOTE] Release httpd-2.4.36

[William A Rowe Jr]

On Mon, Oct 15, 2018 at 3:06 AM Stefan Eissing 
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" <
> tessa...@evermeet.cx> wrote:
> > On 2018-10-10 15:18, Daniel Ruggeri wrote:
> > Hi, all;
> >Please find below the proposed release tarball and signatures:
> > https://dist.apache.org/repos/dist/dev/httpd/
> >
> > I would like to call a VOTE over the next few days to release this
> > candidate tarball as 2.4.36:
> > [ ] +1: It's not just good, it's good enough!
> > [ ] +0: Let's have a talk.
> > [ ] -1: There's trouble in paradise. Here's what's wrong.
>

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: t/modules/buffer.t failing in 2.4.36, LWP bug [Was: [VOTE] Release httpd-2.4.36]

[William A Rowe Jr]

On Sun, Oct 14, 2018, 18:47 Rainer Jung  wrote:

>
> On the contrary, the http2 tests (other thread) fail for me also with
> curl or browser, but only when the server is build with OpenSSL 1.1.1
> (independent of TLS version used).
>

Goes without saying... But this browser and curl are both built against the
TLS 1.3-final implementation, and not a prerelease iteration? I think we
are all well aware of that trap by now but just confirming...

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

[William A Rowe Jr]

Dennis, just to confirm ...  is this build ocsp enabled, or entirely absent
and yet presenting the ocsp help in absence of the feature?

On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke  wrote:

> On 10/14/2018 05:14 PM, Rainer Jung wrote:
> > Am 14.10.2018 um 22:58 schrieb William A Rowe Jr:
> >> On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung  >> <mailto:rainer.j...@kippdata.de>> wrote:
> >>
> >>
> >> And Jim already set "With 1.1.1, both return 1, but so what, we know
> >> that it has oscp."
> >>
> >>
> >> That, of course, is nonsense.
> >>
> >> OpenSSL is malleable... with numerous no-{feature} choice, we really
> >> shouldn't
> >> presume presence of features by OpenSSL version. Otherwise, why wouldn't
> >> we simply use a regex against `openssl version`?
> >
> > Agreed, looking at the code it seems that starting with 1.1.0 (I only
> > checked 1.1.0i) ocsp can be disabled with no-ocsp.
> >
>
> As a red herring that illustrates how oddball the situation could get :
>
> $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
> OpenSSL 0.9.7d 17 Mar 2004
>
> $ /usr/sfw/bin/openssl ocsp > /dev/null
> OCSP utility
> Usage ocsp [options]
> where options are
> -out file  output filename
> -issuer file   issuer certificate
> -cert file certificate to check
> -serial n  serial number to check
> -signer file   certificate to sign OCSP request with
> -signkey file  private key to sign OCSP request with
> -sign_other file   additional certificates to include in signed request
> -no_certs  don't include any certificates in signed request
> -req_text  print text form of request
> -resp_text print text form of response
> -text  print text form of request and response
> -reqout file   write DER encoded OCSP request to "file"
> -respout file  write DER encoded OCSP reponse to "file"
> -reqin fileread DER encoded OCSP request from "file"
> -respin file   read DER encoded OCSP reponse from "file"
> -nonce add OCSP nonce to request
> -no_nonce  don't add OCSP nonce to request
> -url URL   OCSP responder URL
> -host host:n   send OCSP request to host on port n
> -path  path to use in OCSP request
> -CApath dirtrusted certificates directory
> -CAfile file   trusted certificates file
> -VAfile file   validator certificates file
> -validity_period n maximum validity discrepancy in seconds
> -status_age n  maximum status age in seconds
> -noverify  don't verify response at all
> -verify_other file additional certificates to search for signer
> -trust_other   don't verify additional certificates
> -no_intern don't search certificates contained in response for
> signer
> -no_signature_verify don't check signature on response
> -no_cert_verifydon't check signing certificate
> -no_chain  don't chain verify response
> -no_cert_checksdon't do additional checks on signing certificate
> -port numport to run responder on
> -index file  certificate status index file
> -CA file CA certificate
> -rsigner fileresponder certificate to sign responses with
> -rkey file   responder key to sign responses with
> -rother file other certificates to include in response
> -resp_no_certs don't include any certificates in response
> -nmin n  number of minutes before next update
> -ndays n number of days before next update
> -resp_key_id   identify reponse by signing certificate key ID
> -nrequest nnumber of requests to accept (default unlimited)
> Segmentation Fault(coredump)
> $
>
> So, the situation can get out of hand quickly.
>
> Dennis
>
> ps: I am on the sidelines reading *all* of this and wondering ...
>

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

[William A Rowe Jr]

On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung  wrote:

>
> And Jim already set "With 1.1.1, both return 1, but so what, we know
> that it has oscp."
>

That, of course, is nonsense.

OpenSSL is malleable... with numerous no-{feature} choice, we really
shouldn't
presume presence of features by OpenSSL version. Otherwise, why wouldn't
we simply use a regex against `openssl version`?

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

[William A Rowe Jr]

Copy paste missed a stderr line;

$ openssl ocsp >/dev/null
ocsp: Use -help for summary.
$ echo $?
1
$ openssl xyz >/dev/null
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl version
OpenSSL 1.1.0i-fips  14 Aug 2018

This is from
# dnf list openssl
Installed Packages
openssl.x86_64 1:1.1.0i-1.fc27
@updates
# cat /etc/redhat-release
Fedora release 27 (Twenty Seven)

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

[William A Rowe Jr]

On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski  wrote:

> All we are checking is the error code. Nothing else.
>
>% openssl version
>OpenSSL 1.0.2p  14 Aug 2018
>% openssl ocsp 2>/dev/null
>% print $?
>1
>% openssl foo 2>/dev/null
>% print $?
>0
>
> With 1.1.1, both return 1, but so what, we know that it has oscp.
>

$ openssl ocsp >/dev/null
ocsp: Use -help for summary.[wrowe@hub test-httpd]$ echo $?
$ echo $?
1
$ openssl xyz >/dev/null
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl version
OpenSSL 1.1.0i-fips  14 Aug 2018

This doesn't tell us whether ocsp is compiled in.

I have no idea which bastardization of the openssl command line tool you
are using which returns success for bad verbs.

Complaining about /dev/null : orig code had this. Why was that OK?
>

Never suggested it was OK.

 Asking about finding potential *solutions* instead of throwing more darts
at the wall. Why the emotive tone to a technical discussion?

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

On Sat, Oct 13, 2018 at 1:22 PM William A Rowe Jr 
wrote:

> On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith  wrote:
>
>> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
>> > Otherwise, I understand this to be a noop.
>>
>
>> No, it just got moved to the ms folder is all that happened at 1.1.0 and
>> is still there in 1.1.1.
>>
>
> No, I'm certain that's incorrect. It was always in ms/ in the source bundle
> and was previously installed into include/openssl/ on applicable platforms.
> The fact that it isn't in the resulting installed -devel tree suggests it
> is no
> longer recommended, or that the openssl maintainers got the refactoring
> of their build schema wrong.
>

Just to carve out this single aspect of the discussion, I've logged a
ticket
with openssl about the absence of include/openssl/applink.c;

https://github.com/openssl/openssl/issues/7396

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

On Sat, Oct 13, 2018 at 2:06 PM Ivan Zhakov  wrote:

> On Sat, 13 Oct 2018 at 20:00, Gregg Smith  wrote:
>
>> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
>> > Sorry, I don't understand.
>> >
>> > Gregg, can you shed some insight here? For both, applink.c is helpful if
>> > the OpenSSL .dll files are created with a different VC compiler than
>> > abs.exe was compiled with.
>>
>> Not true, OSSL 1.0.2 I know from experience if applink.c is not included
>> it will still err even if both ab.c & OSSL are compiled with the same VC
>> version (14 & 15). I never tested 1.1.0.
>>
>> That's true: since OpenSSL 1.0.2 applink.c is required even if OpenSSL и
> application uses same VC toolchain.
>

That's very interesting, not observed here. Second request... pointers
please? I'm strongly suspecting an /MD /MT mismatch. I only build the
'ntdll' style of OpenSSL, and never bother to mix linkage models or build
abs.c static against openssl etc. Or perhaps this speaks to specific, buggy
releases of 1.0.2?

[Something for the audience; applink.c redirects all of the "standard c
library" API's used by OpenSSL into the flavor in use by the version of the
MSVC runtime linked to the primary .exe file. And in it's absence, the
flavor OpenSSL was built against. Why we almost never care? These apply to
basic input/output, the BIO layer of OpenSSL, which mod_ssl hardly touches.
But apps using classic C stdio functionality like ab.c care a great deal.
Which leads us to Ivan's comment;]


> Alternative solution to including applink.c could stop using OpenSSL APIs
> that uses stdio and provide APR based BIO implementation. In this case
> OpenSSL will never use stdio functions.
>

Indeed! That's a complete solution. But a lot of effort if Boring/Libre/etc
"just work" and only OpenSSL falls down on doing the simplest BIO
functions. I'd have to fault OpenSSL, and not promote workarounds. Again I
need some citations about the "defect" which makes zero sense here.

It would also support building mod_ssl with OpenSSL compiled with option
> --no-stdio.
>

Indeed, I'm shocked if we can't build mod_ssl with --no-stdio today! Those
would be some odd quirks in mod_ssl/openssl (discounting ab.c)... but
that's certainly another thread. It seems like a worthwhile goal, nothing
should speak stdio within mod_ssl's structure.

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

[William A Rowe Jr]

On Sat, Oct 13, 2018 at 1:35 PM William A Rowe Jr 
wrote:

> On Wed, Oct 10, 2018 at 12:27 PM  wrote:
>
>> Author: jim
>> Date: Wed Oct 10 17:27:33 2018
>> New Revision: 1843478
>>
>> URL: http://svn.apache.org/viewvc?rev=1843478=rev
>> Log:
>> Better method... just check return status
>>
>> 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=1843478=1843477=1843478=diff
>>
>> ==
>> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
>> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 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-standard-commands 2>/dev/null` !~ /ocsp/) {
>> +or system("$openssl ocsp 2>/dev/null") == 0) {
>>
>
> On Windows, /dev/null is invalid (output target nul, eg NUL).
>
> On every platform this is an always-fail noop, since `openssl ocsp` always
> results in an error. Not enough arguments. You disabled this test on all
> environments, please revert.
>
> One test without extraneous stdout garbage might be to test ( `$openssl
> ocsp -help` !~ /Usage:/ ) ... in theory this would both succeed (success
> 0), eat stdout, and there should be no Usage: instructions if the ocsp verb
> doesn't exist.
>

e.g.

$ openssl xyz -help
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl ocsp -help
Usage: ocsp [options]
Valid options are:
 -help   Display this summary
 -out outfileOutput filename
[...]
$ echo $?
0

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

[William A Rowe Jr]

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

> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
>
> URL: http://svn.apache.org/viewvc?rev=1843478=rev
> Log:
> Better method... just check return status
>
> 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=1843478=1843477=1843478=diff
>
> ==
> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 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-standard-commands 2>/dev/null` !~ /ocsp/) {
> +or system("$openssl ocsp 2>/dev/null") == 0) {
>

On Windows, /dev/null is invalid (output target nul, eg NUL).

On every platform this is an always-fail noop, since `openssl ocsp` always
results in an error. Not enough arguments. You disabled this test on all
environments, please revert.

One test without extraneous stdout garbage might be to test ( `$openssl
ocsp -help` !~ /Usage:/ ) ... in theory this would both succeed (success
0), eat stdout, and there should be no Usage: instructions if the ocsp verb
doesn't exist.

Thoughts?

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith  wrote:

> On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
> > Sorry, I don't understand.
> >
> > Gregg, can you shed some insight here? For both, applink.c is helpful if
> > the OpenSSL .dll files are created with a different VC compiler than
> > abs.exe was compiled with.
>
> Not true, OSSL 1.0.2 I know from experience if applink.c is not included
> it will still err even if both ab.c & OSSL are compiled with the same VC
> version (14 & 15). I never tested 1.1.0.
>

I can assure you that was not true, having built against 0.9.7, .8, 1.0.0,
etc etc etc. What can break is that if you build openssl in a different
model
(the whole /MD, /MT etc) than abs.c, then yes, they could be disjointed.

Can you find me any pointers to the claim that I could investigate further?

> .exe, it cannot be found from a .dll or Apache .so loadable.module.
> > Otherwise, I understand this to be a noop.
>
> No, it just got moved to the ms folder is all that happened at 1.1.0 and
> is still there in 1.1.1.
>

No, I'm certain that's incorrect. It was always in ms/ in the source bundle
and was previously installed into include/openssl/ on applicable platforms.
The fact that it isn't in the resulting installed -devel tree suggests it
is no
longer recommended, or that the openssl maintainers got the refactoring
of their build schema wrong.


> I'm -1 on this till at least the majority of OSSL versions do not
> include applink.c.
>

I read this as logical converse, you are +1 to patch main.c to include it?

This suggests we need to re-raise the issue at the openssl project or
declare 1.1.1 incompatible without the workaround of finding the library
source bundle, or manually installing applink.c where it used to be.

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

Sorry, I don't understand.

Gregg, can you shed some insight here? For both, applink.c is helpful if
the OpenSSL .dll files are created with a different VC compiler than
abs.exe was compiled with. And it is only effective if compiled into the
.exe, it cannot be found from a .dll or Apache .so loadable.module.
Otherwise, I understand this to be a noop.

OpenSSL project deprecated, that is, no longer ships applink.c in
include/openssl/ install directory. LibreSSL and BoringSSL have no such
resource.

Since you indicate that patching is trivial, and building with two
different compilers isn't something an open source project should fret
about, the Apache.exe and abs.exe should behave the same way. Pick one.


On Sat, Oct 13, 2018, 04:04 Steffen  wrote:

> Do not understand your writing.
>
> abs.exe needs the applink shim, so leave it in.
>
>
> Op 12 okt. 2018 om 23:54 heeft William A Rowe Jr 
> het volgende geschreven:
>
> Great, I'll proceed with changing ab.c to remove the hack, since it is
> unneeded when ab.c is compiled by the same toolchain as libcrypto.dll,
> isn't available in non-openssl distributions, and was deprecated in 1.1.1
> again.
>
> Anyone interested can proceed to patch both and provision applink.c when
> working with OpenSSL 1.1.1, so I don't need to raise a ticket that project
>
>
> On Fri, Oct 12, 2018, 16:37 Steffen  wrote:
>
>> Already for years we have in server/main.c :
>>
>> #include "applink.c"
>>
>>
>> This solves errors like: no OPENSSL_Applink , see for example :
>> https://www.apachelounge.com/viewtopic.php?p=30986
>>
>> No problem to patch.
>>
>> Op 12 okt. 2018 om 22:03 heeft William A Rowe Jr 
>> het volgende geschreven:
>>
>> ... and still hanging.
>>
>> Rather than ApacheLounge and some others needing to patch each time,
>> did we conclude that we should wire in the applink.c stub into Apache.exe
>> as shipped by httpd project?
>>
>> (I've never mixed binaries of different MSVC environments, so myself,
>> I don't care, but it seems to raise issues for a subset of the community.)
>>
>>
>> On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr 
>> wrote:
>>
>>> So we kind of left this hanging...
>>>
>>> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  wrote:
>>>
>>>> On 6/15/2016 9:20 AM, William A Rowe Jr wrote:
>>>> > In building httpd.exe, some users don't build and install openssl. It
>>>> isn't
>>>> > going
>>>> > to be possible to simply #include  without some
>>>> > conditional
>>>> > test. OpenSSL itself is partly the culprit, for not having an
>>>> > APPLINK_REQUIRED
>>>> > style macro conditional. But we can work around this in the cmake
>>>> tests.
>>>> >
>>>>
>>>> This is why the patch creator put this inside a HAVE_OPENSSL block so
>>>> ab.exe did not get this added. abs (at least on the dsp et. al.) is not
>>>> built unless there is OpenSSL present.
>>>>
>>>> > I'll look at making this a standard bit of the httpd 2.4 build. We can
>>>> > likely
>>>> > add a user-toggled flag to the os/win32/os.h?
>>>>
>>>> Seems to me this is not needed .
>>>>
>>>
>>> So, is the win32 community in favor of using HAVE_OPENSSL to include
>>> applink.c in the scope of main.c (as revised in the current ab.c sources,
>>> to avoid this on libressl?)
>>>
>>> There is a presumption that the crt used by libhttpd the same as libapr,
>>> but I think this is a reasonable connection.
>>>
>>> The entire logic to main.c should be as simple as...
>>>
>>> #if defined(HAVE_OPENSSL) && defined(_MSC_VER) &&
>>> !defined(LIBRESSL_VERSION_NUMBER)
>>> /* The following logic ensures we correctly glue FILE* within one CRT
>>> used
>>>  * by the OpenSSL library build to another CRT used by the ab.exe build.
>>>  * This became especially problematic with Visual Studio 2015.
>>>  */
>>> #include 
>>> #endif
>>>
>>> By inserting the structure in httpd.exe, that structure can be found by
>>> the openssl library, which is not true of including this in a loadable
>>> library such as libhttpd.dll or libaprutil-1.dll.
>>>
>>

Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

Great, I'll proceed with changing ab.c to remove the hack, since it is
unneeded when ab.c is compiled by the same toolchain as libcrypto.dll,
isn't available in non-openssl distributions, and was deprecated in 1.1.1
again.

Anyone interested can proceed to patch both and provision applink.c when
working with OpenSSL 1.1.1, so I don't need to raise a ticket at that
project.


On Fri, Oct 12, 2018, 16:37 Steffen  wrote:

> Already for years we have in server/main.c :
>
> #include "applink.c"
>
>
> This solves errors like: no OPENSSL_Applink , see for example :
> https://www.apachelounge.com/viewtopic.php?p=30986
>
> No problem to patch.
>
> Op 12 okt. 2018 om 22:03 heeft William A Rowe Jr 
> het volgende geschreven:
>
> ... and still hanging.
>
> Rather than ApacheLounge and some others needing to patch each time,
> did we conclude that we should wire in the applink.c stub into Apache.exe
> as shipped by httpd project?
>
> (I've never mixed binaries of different MSVC environments, so myself,
> I don't care, but it seems to raise issues for a subset of the community.)
>
>
> On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr 
> wrote:
>
>> So we kind of left this hanging...
>>
>> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  wrote:
>>
>>> On 6/15/2016 9:20 AM, William A Rowe Jr wrote:
>>> > In building httpd.exe, some users don't build and install openssl. It
>>> isn't
>>> > going
>>> > to be possible to simply #include  without some
>>> > conditional
>>> > test. OpenSSL itself is partly the culprit, for not having an
>>> > APPLINK_REQUIRED
>>> > style macro conditional. But we can work around this in the cmake
>>> tests.
>>> >
>>>
>>> This is why the patch creator put this inside a HAVE_OPENSSL block so
>>> ab.exe did not get this added. abs (at least on the dsp et. al.) is not
>>> built unless there is OpenSSL present.
>>>
>>> > I'll look at making this a standard bit of the httpd 2.4 build. We can
>>> > likely
>>> > add a user-toggled flag to the os/win32/os.h?
>>>
>>> Seems to me this is not needed .
>>>
>>
>> So, is the win32 community in favor of using HAVE_OPENSSL to include
>> applink.c in the scope of main.c (as revised in the current ab.c sources,
>> to avoid this on libressl?)
>>
>> There is a presumption that the crt used by libhttpd the same as libapr,
>> but I think this is a reasonable connection.
>>
>> The entire logic to main.c should be as simple as...
>>
>> #if defined(HAVE_OPENSSL) && defined(_MSC_VER) &&
>> !defined(LIBRESSL_VERSION_NUMBER)
>> /* The following logic ensures we correctly glue FILE* within one CRT used
>>  * by the OpenSSL library build to another CRT used by the ab.exe build.
>>  * This became especially problematic with Visual Studio 2015.
>>  */
>> #include 
>> #endif
>>
>> By inserting the structure in httpd.exe, that structure can be found by
>> the openssl library, which is not true of including this in a loadable
>> library such as libhttpd.dll or libaprutil-1.dll.
>>
>

Re: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

... and still hanging.

Rather than ApacheLounge and some others needing to patch each time,
did we conclude that we should wire in the applink.c stub into Apache.exe
as shipped by httpd project?

(I've never mixed binaries of different MSVC environments, so myself,
I don't care, but it seems to raise issues for a subset of the community.)


On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr 
wrote:

> So we kind of left this hanging...
>
> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  wrote:
>
>> On 6/15/2016 9:20 AM, William A Rowe Jr wrote:
>> > In building httpd.exe, some users don't build and install openssl. It
>> isn't
>> > going
>> > to be possible to simply #include  without some
>> > conditional
>> > test. OpenSSL itself is partly the culprit, for not having an
>> > APPLINK_REQUIRED
>> > style macro conditional. But we can work around this in the cmake tests.
>> >
>>
>> This is why the patch creator put this inside a HAVE_OPENSSL block so
>> ab.exe did not get this added. abs (at least on the dsp et. al.) is not
>> built unless there is OpenSSL present.
>>
>> > I'll look at making this a standard bit of the httpd 2.4 build. We can
>> > likely
>> > add a user-toggled flag to the os/win32/os.h?
>>
>> Seems to me this is not needed .
>>
>
> So, is the win32 community in favor of using HAVE_OPENSSL to include
> applink.c in the scope of main.c (as revised in the current ab.c sources,
> to avoid this on libressl?)
>
> There is a presumption that the crt used by libhttpd the same as libapr,
> but I think this is a reasonable connection.
>
> The entire logic to main.c should be as simple as...
>
> #if defined(HAVE_OPENSSL) && defined(_MSC_VER) &&
> !defined(LIBRESSL_VERSION_NUMBER)
> /* The following logic ensures we correctly glue FILE* within one CRT used
>  * by the OpenSSL library build to another CRT used by the ab.exe build.
>  * This became especially problematic with Visual Studio 2015.
>  */
> #include 
> #endif
>
> By inserting the structure in httpd.exe, that structure can be found by
> the openssl library, which is not true of including this in a loadable
> library such as libhttpd.dll or libaprutil-1.dll.
>

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

[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: 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

[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: 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

[William A Rowe Jr]

You might want to review the thread following up svn commit: r1840585
back from Sept 12th w.r.t. some of these.

On Tue, Oct 9, 2018 at 3:29 PM 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.
>
> 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: Wherefor 2.4.36?

[William A Rowe Jr]

Since this tag is only days away, the committers would really appreciate
any feedback from early adopters. I'm not certain on the status of the auth
hook fix, but believe it's certainly ready to have the tires kicked, so we
can avoid any quirks resulting from the TLS 1.3 efforts.

Please feel free to try it from the 2.4.x branch and let us know your
observations. I believe it is stable enough for review now.


On Sat, Oct 6, 2018, 19:54 Michael-Fever  wrote:

>
> Aww, all I care about is getting 2.4.36 going so I can say I have TLS 1.3
> supported with my h2.  LOL, no but seriously, is 2.4.36 stable enough to be
> using?
>
>
>
> --
> Sent from:
> http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html
>

Re: svn commit: r1837056 - in /httpd/httpd/trunk: ./ include/ modules/filters/ modules/http/ modules/http2/ modules/proxy/ modules/test/ server/

[William A Rowe Jr]

On Thu, Oct 4, 2018 at 12:09 PM Evgeny Kotkov 
wrote:

>
> However, a more important question is whether there is an actual problem to
> solve.  I see that ap_http_header_filter() features a whitelist of headers
> that are sent for 304 responses (http_filters.c:1428), and all headers such
> as Content-Encoding are filtered anyway.
>

AIUI Transfer-* headers should be filtered. Content-* headers must match
the specific ETag as if the response was 200, from my reading.

Re: Apache httpd 2.4.35 announcement on Twitter

[William A Rowe Jr]

Edit to add, I also found two references on G+...

https://plus.google.com/s/httpd%202.4.35/top

On Mon, Oct 1, 2018 at 7:34 PM William A Rowe Jr 
wrote:

> I see some Twitter activity, including;
> https://twitter.com/ApacheLounge/status/1043436704646852608
>
> as well as a very minor FB footprint of some three mentions;
>
> https://www.facebook.com/groups/sistemcihrvatska/permalink/2105437672830472/
>
> Unfortunately, I found nothing on El Reg or MySpace.
>
> Can't recall where we documented twitter Announcements. Pointers please?
>
>
> On Mon, Oct 1, 2018 at 10:01 AM Jim Jagielski  wrote:
>
>> I didn't see any announcement about the 2.4.35 release on twitter... did
>> I just miss it?
>
>

Re: Apache httpd 2.4.35 announcement on Twitter

[William A Rowe Jr]

I see some Twitter activity, including;
https://twitter.com/ApacheLounge/status/1043436704646852608

as well as a very minor FB footprint of some three mentions;
https://www.facebook.com/groups/sistemcihrvatska/permalink/2105437672830472/

Unfortunately, I found nothing on El Reg or MySpace.

Can't recall where we documented twitter Announcements. Pointers please?


On Mon, Oct 1, 2018 at 10:01 AM Jim Jagielski  wrote:

> I didn't see any announcement about the 2.4.35 release on twitter... did I
> just miss it?

Re: Announce missing - in moderation?

[William A Rowe Jr]

On Sat, Sep 29, 2018, 09:25 Daniel Ruggeri  wrote:

> Hi, Bill;
>
>Sure. I've updated the scripts to set the reply-to address and also
> fired a message off to ann@a.o to wrap it up. I didn't change the date
> of the announcement, so hopefully that won't pose a problem.
>

Confirming...

https://lists.apache.org/list.html?annou...@apache.org

   Later I'll commit a change to just send separate emails instead of a
> multi-to message since that seems like the easiest approach.
>

+1!

Thanks for RMing!

Re: Announce missing - in moderation?

[William A Rowe Jr]

Sebb thank you for your analysis!

Two issues; one, the reply-to field of security announcements was set to
security@, and this is in direct contravention of Apache policy. Security@
is exclusively for reporting undisclosed vulnerabilities, and all other
traffic is ignored. This group of email addresses must never be shared
without context and usage guidance. Please, never do that again.

Two, this announce is still not published to ann@a.o. What is the next step
to cause this to happen? Daniel, could you use a conventional mail agent to
wrap this cycle up?



On Wed, Sep 26, 2018, 18:40 sebb  wrote:

> Also just realised the Message-Id is missing.
>
> Some servers (e.g. GMail) may add it; if they don't it can causes issues
> for mod_mbox and possibly other archivers.
> It also causes problems for mail threading.
> And if the mail is sent to multiple destinations, each generated
> Message-Id will be different.
>
> On 26 September 2018 at 22:04, Noel Butler  wrote:
>
>> On 27/09/2018 05:37, sebb AT ASF wrote:
>>
>>
>> I don't know if this is relevant, but the messages don't have a Date:
>> header.
>>
>>
>> A  this would be because Daniel used curl to send them rather than a
>> sane method :)
>>
>>
>>
>>
>> Also some of the received headers look odd:
>>
>> Received: from Announcement.txt (IP redacted)
>> by mailrelay1-lw-us.apache.org (ASF Mail Server at
>> mailrelay1-lw-us.apache.org) with ESMTPSA id redacted
>> for ; Sat, 22 Sep 2018 11:41:35 +
>> (UTC)
>>
>> and
>>
>> Received: from CVE-2018-11763-h2-dos-by-settings.txt (IP redacted)
>> by mailrelay2-lw-us.apache.org (ASF Mail Server at
>> mailrelay2-lw-us.apache.org) with ESMTPSA id redacted
>> for ; Sat, 22 Sep 2018 11:41:38 +
>> (UTC)
>>
>> --
>>
>> Kind Regards,
>>
>> Noel Butler
>> This Email, including any attachments, may contain legally privileged
>> information, therefore remains confidential and subject to copyright
>> protected under international law. You may not disseminate, discuss, or
>> reveal, any part, to anyone, without the authors express written authority
>> to do so. If you are not the intended recipient, please notify the sender
>> then delete all copies of this message including attachments, immediately.
>> Confidentiality, copyright, and legal privilege are not waived or lost by
>> reason of the mistaken delivery of this message. Only PDF
>>  and ODF
>>  documents accepted, please
>> do not send proprietary formatted documents
>>
>
>

Re: Announce missing - in moderation?

[William A Rowe Jr]

On Tue, Sep 25, 2018 at 11:56 PM Daniel Ruggeri 
wrote:

> FWIW, this was a straight forward multi-To field email message addressed
> to both lists. If there is a way I can improve the announce/release
> automation, I am happy to do so. Maybe a better way is to send multiple
> messages?
>

At some point, http://httpd.apache.org/dev/release.html was edited to drop
a very critical point; each should be sent is a distinct message. Most of
the
announce lists automatically drop multi-recipient garbage as spam. This
will go for the various bugtraq lists as well.

Re: Announce missing - in moderation?

[William A Rowe Jr]

Agreed it was published to ann@httpd.a.o, likely Jim's approval.

 It has not arrived at a...@apache.org.

Sebb, can you shed any light on this moderation issue?



On Tue, Sep 25, 2018, 12:29 Jim Jagielski  wrote:

> FWIW, I just saw a mod request for *an* announcement and approved it
>
> On Sep 25, 2018, at 12:19 PM, Private LIst Moderation <
> mod-priv...@gsuite.cloud.apache.org> wrote:
>
> Hi Daniel,
>
> I've looked in the moderation queue and did not find the announce@
> moderation email.
>
> Craig
>
> On Sep 25, 2018, at 7:00 AM, Daniel Ruggeri  wrote:
>
> Infra points out it's easier to just resend than to dig out the message
> they found on the server. I've sent again - receiving these confirmations:
>
> < 235 2.7.0 Authentication successful
>
> MAIL FROM: SIZE=2919
>
> < 250 2.1.0 Ok
>
> RCPT TO:
>
> < 250 2.1.5 Ok
>
> DATA
>
> < 354 End data with .
> } [data not shown]
> * We are completely uploaded and fine
> < 250 2.0.0 Ok: queued as EB77F2332
>
> < 235 2.7.0 Authentication successful
>
> MAIL FROM: SIZE=874
>
> < 250 2.1.0 Ok
>
> RCPT TO:
>
> < 250 2.1.5 Ok
>
> DATA
>
> < 354 End data with .
> } [data not shown]
> * We are completely uploaded and fine
> < 250 2.0.0 Ok: queued as 9B4B1E1B
>
> I've also added Craig here as he was unable to find the message sent to
> announce@a.o - with luck, these won't vanish, but at least this time I
> have the message IDs...
> --
> Daniel Ruggeri
>
> On 2018-09-24 16:59, Daniel Ruggeri wrote:
>
> Yes, I sent via curl (true story, you can send email with curl)
> directly to the relay service and authenticated with my ASF
> credentials. I had checked in with Infra here at ACNA and they saw
> *something* that looked like my message. I'll check in with them
> again.
> Thanks, folks
> --
> Daniel Ruggeri
> On September 24, 2018 3:07:00 PM EDT, William A Rowe Jr
>  wrote:
>
> I'm seeing no announce@httpd moderation request. (I am not an
> annou...@apache.org moderator.)
> Did you send from your @apache.org [1] avail-id through the ASF
> server? It would
> be rejected for non-apache and for mismatched SPF records.
> On Mon, Sep 24, 2018 at 9:16 AM Daniel Ruggeri 
> wrote:
>
> Hi, all;
> I sent the announce message for 2.4.35, but haven't received it
> myself. I didn't get errors sending that I am aware of. Perhaps it
> is in moderation? If not, I can check in with infra to see if
> mail-relay.a.o ate it.
> Thanks
> --
> Daniel Ruggeri
>
> Links:
> --
> [1] http://apache.org
>
>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>
>

Re: Announce missing - in moderation?

[William A Rowe Jr]

I'm seeing no announce@httpd moderation request. (I am not an
annou...@apache.org moderator.)

Did you send from your @apache.org avail-id through the ASF server? It would
be rejected for non-apache and for mismatched SPF records.



On Mon, Sep 24, 2018 at 9:16 AM Daniel Ruggeri  wrote:

> Hi, all;
>I sent the announce message for 2.4.35, but haven't received it myself.
> I didn't get errors sending that I am aware of. Perhaps it is in
> moderation? If not, I can check in with infra to see if mail-relay.a.o ate
> it.
>
> Thanks
> --
> Daniel Ruggeri
>

Re: svn commit: r1841620 - /httpd/site/trunk/content/dev/verification.mdtext

[William A Rowe Jr]

You might want to point out the -r flag to OpenSSL, which emits the same
output as bintools sha256.


On Fri, Sep 21, 2018, 12:30  wrote:

> Author: elukey
> Date: Fri Sep 21 17:30:07 2018
> New Revision: 1841620
>
> URL: http://svn.apache.org/viewvc?rev=1841620=rev
> Log:
> Remove MD5 traces from documentation and add a SHA256 tutorial.
>
> Modified:
> httpd/site/trunk/content/dev/verification.mdtext
>
> Modified: httpd/site/trunk/content/dev/verification.mdtext
> URL:
> http://svn.apache.org/viewvc/httpd/site/trunk/content/dev/verification.mdtext?rev=1841620=1841619=1841620=diff
>
> ==
> --- httpd/site/trunk/content/dev/verification.mdtext (original)
> +++ httpd/site/trunk/content/dev/verification.mdtext Fri Sep 21 17:30:07
> 2018
> @@ -19,10 +19,10 @@ Notice:Licensed to the Apache Softwa
>  # Verifying Apache HTTP Server Releases
>
>  All official releases of code distributed by the Apache HTTP Server
> Project
> -are signed by the release manager for the release. PGP signatures and MD5
> +are signed by the release manager for the release. PGP signatures and SHA
>  hashes are available along with the distribution.
>
> -You should download the PGP signatures and MD5 hashes directly from the
> +You should download the PGP signatures and SHA hashes directly from the
>  Apache Software Foundation rather than our mirrors. This is to help ensure
>  the integrity of the signature files. However, you are encouraged to
>  download the releases from our mirrors. (Our download page points you at
> @@ -168,3 +168,23 @@ verifying the signature of a release.
>  gpg: aka "Jim Jagielski "
>  gpg: aka "Jim Jagielski "
>
> +In order to check the integrity of the downloaded file, you need to
> download the source and the related SHA256
> +hash. For example, assuming a preference for tar.bz, to verify the
> 2.4.34 release you should end up with two files on disk:
> +
> +  * httpd-2.4.34.tar.bz2 (source)
> +  * httpd-2.4.34.tar.bz2.sha256 (SHA256 hash)
> +
> +On most Unix systems then it is only a matter of executing:
> +
> +% shasum -a 256 -c httpd-2.4.34.tar.bz2.sha256
> +httpd-2.4.34.tar.bz2: OK
> +
> +Behind the scenes, the command checks that the SHA hash contained in
> httpd-2.4.34.tar.bz2.sha256 matches the one
> +calculated for the file httpd-2.4.34.tar.bz2. The correct result should
> be a 'OK' displayed.
> +
> +Another way to calculate the SHA256 has for a file is to use openssl:
> +
> +% openssl sha -sha256 httpd-2.4.34.tar.bz2
> +SHA256(httpd-2.4.34.tar.bz2)=
> fa53c95631febb08a9de41fd2864cfff815cf62d9306723ab0d4b8d7aa1638f0
> +
> +And then verify that the content of httpd-2.4.34.tar.bz2.sha256 matches
> the above result.
> \ No newline at end of file
>
>
>

Re: svn commit: r29575 - /dev/httpd/ /release/httpd/

[William A Rowe Jr]

On Fri, Sep 21, 2018 at 12:09 PM Dennis Clarke 
wrote:

> On 09/21/2018 12:27 PM, William A Rowe Jr wrote:
> > You may want to use this opportunity to drop md5 and sha1 hashes, you
> > will be yelled at by ops when you attempt to publish new instances of
> > these obsoleted hashes.
> >
> > Even on very stale OS's without sha256 in their tool chain, they likely
> > have openssl 0.9.8 or later with sha256 support.
>
> I can tell you that I have seen unpatched barely maintained Solaris 10
> servers in the wild. Chugging along. Sadly. Those things have :
>
> # /usr/sfw/bin/openssl version
> OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: ... long list here )
>
> Sure enough .. no sha512 there nor even sha256. Or much in fact.


Many flavors of literally unsupported configurations still exist with no
sha256.
If these are used as outward facing servers, that's about as good for the
security ecosystem as unpatched Windows 98/ME instances that are still
out there.

But even in these cases, it is a simple matter to download to a system that
can validate the asc pgp sig, and transfer the file from that verified
source.
I see no issue here.

Re: svn commit: r29575 - /dev/httpd/ /release/httpd/

[William A Rowe Jr]

You may want to use this opportunity to drop md5 and sha1 hashes, you will
be yelled at by ops when you attempt to publish new instances of these
obsoleted hashes.

In the apr release case, the announce was modded through anyways, but a
subsequent thread on dev@apr determined that only sha256 is both useful and
portable.

Adding a sha512 undermines our direction to users to rely on the asc pgp
sig.

Even on very stale OS's without sha256 in their tool chain, they likely
have openssl 0.9.8 or later with sha256 support.



On Fri, Sep 21, 2018, 07:37  wrote:

> Author: druggeri
> Date: Fri Sep 21 12:37:13 2018
> New Revision: 29575
>
> Log:
> Push 2.4.35 up to the release directory
>
> Added:
> release/httpd/CHANGES_2.4.35
>   - copied unchanged from r29574, dev/httpd/CHANGES_2.4.35
> release/httpd/httpd-2.4.35.tar.bz2
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.bz2
> release/httpd/httpd-2.4.35.tar.bz2.asc
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.bz2.asc
> release/httpd/httpd-2.4.35.tar.bz2.md5
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.bz2.md5
> release/httpd/httpd-2.4.35.tar.bz2.sha1
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.bz2.sha1
> release/httpd/httpd-2.4.35.tar.bz2.sha256
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.bz2.sha256
> release/httpd/httpd-2.4.35.tar.gz
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.gz
> release/httpd/httpd-2.4.35.tar.gz.asc
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.gz.asc
> release/httpd/httpd-2.4.35.tar.gz.md5
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.gz.md5
> release/httpd/httpd-2.4.35.tar.gz.sha1
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.gz.sha1
> release/httpd/httpd-2.4.35.tar.gz.sha256
>   - copied unchanged from r29574, dev/httpd/httpd-2.4.35.tar.gz.sha256
> Removed:
> dev/httpd/CHANGES_2.4
> dev/httpd/CHANGES_2.4.35
> dev/httpd/httpd-2.4.35-deps.tar.bz2
> dev/httpd/httpd-2.4.35-deps.tar.bz2.asc
> dev/httpd/httpd-2.4.35-deps.tar.bz2.md5
> dev/httpd/httpd-2.4.35-deps.tar.bz2.sha1
> dev/httpd/httpd-2.4.35-deps.tar.bz2.sha256
> dev/httpd/httpd-2.4.35-deps.tar.gz
> dev/httpd/httpd-2.4.35-deps.tar.gz.asc
> dev/httpd/httpd-2.4.35-deps.tar.gz.md5
> dev/httpd/httpd-2.4.35-deps.tar.gz.sha1
> dev/httpd/httpd-2.4.35-deps.tar.gz.sha256
> dev/httpd/httpd-2.4.35.tar.bz2
> dev/httpd/httpd-2.4.35.tar.bz2.asc
> dev/httpd/httpd-2.4.35.tar.bz2.md5
> dev/httpd/httpd-2.4.35.tar.bz2.sha1
> dev/httpd/httpd-2.4.35.tar.bz2.sha256
> dev/httpd/httpd-2.4.35.tar.gz
> dev/httpd/httpd-2.4.35.tar.gz.asc
> dev/httpd/httpd-2.4.35.tar.gz.md5
> dev/httpd/httpd-2.4.35.tar.gz.sha1
> dev/httpd/httpd-2.4.35.tar.gz.sha256
> Modified:
> release/httpd/Announcement2.4.html
> release/httpd/Announcement2.4.txt
> release/httpd/CHANGES_2.4
>

Re: [VOTE] Release httpd-2.4.35

[William A Rowe Jr]

On Mon, Sep 17, 2018 at 7:57 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.35:
> [ ] +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.
>

+1, liking what I've observed on Win32/CMake, Ubuntu-on-windows, and Fedora.
Have not had a chance to complete all of my review owing to some really
wonky
new Windows strict case path behavior, but the vote time ends, is good
enough!

Re: minor nit in mod_ssl

[William A Rowe Jr]

On Thu, Sep 20, 2018 at 4:41 AM Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@vodafone.com> wrote:

> Can we have set it to info? Debug is very verbose for SSL just to find out
> why a HTTP request was replied to with a 403.
>

Whatever is appropriate on startup/graceful restart is fine, but 400's must
be
deciphered out by examining the debug log. The vast number of any class of
400 requests are caused by robot or malicious traffic, so please, nothing
stronger than a debug emit for these incidental, undesired TCP connections.

Re: NOTICE: Intent to T 2.4.35 in the next few hours

[William A Rowe Jr]

On Wed, Sep 19, 2018 at 6:56 AM Joe Orton  wrote:

> On Wed, Sep 19, 2018 at 01:19:29PM +0200, Apache Lounge wrote:
> > Are there  examples what (maybe) does not work with OpenSSL 1.1.1 ?
>
> Have you run the test suite? The flipped setting of SSL_MODE_AUTO_RETRY
> is expected to break TLSv1.2 as well, that problem is consistent with
> the hangs Daniel reported here.
>

Note this applies specifically to the timing and scope of httpd auth under
TLS.


> > openssl.org says that the new 1.1.1 is binary and API/ABI compatible
> with
> > OpenSSL 1.1.0.
>
> For some apps that might be true, I think it's a bit of a stretch, but
> it's not really worth arguing about.
>

And note that 1.1.1a may address some deficiencies in 1.1.1 release
w.r.t. compatibility. Although this specific one was asked-and-answered,
with enough pushback from various projects, such defaults (at least for the
behavior of TLS 1.2) may be reconsidered.

+1 on the proposed statement.

Re: minor nit in mod_ssl

[William A Rowe Jr]

On Wed, Sep 19, 2018 at 6:39 AM Stefan Eissing 
wrote:

>
> > Am 18.09.2018 um 15:44 schrieb Houser, Rick :
> >
> > In the same vein, I’ve been running this patch on our builds to get
> around a warning for certificates not matching the hostname.  Certificates
> are not expected to match the hostname with many load balancing/uptime
> detection schemes, and this one logs a LOT when it trips on every vhost.
> Perhaps this patch should share the same fate as decided for the TLS
> missing SNI issue?
>
> Not sure I understand your setup here. Is this the ServerName from the
> global server? Otherwise, in a VirtualHost why would you not set the
> ServerName to the hostname you are serving?


Envision a TCP load balancer routing TLS-crypted traffic across a number
of internal hosts, with each of the named virtual hosts presenting the
correct
certificate, and known to httpd by their ServerAlias on the outer-facing
interface.
Not terminated at the edge balancer.

There is the issue of keeping TLS session key encoding in sync across
the backends, obviously.

Re: NOTICE: Intent to T 2.4.35 in the next few hours

[William A Rowe Jr]

On Tue, Sep 18, 2018 at 1:56 PM Ruediger Pluem  wrote:

>
> > You'll likely see issues testing against OpenSSL 1.1.1 until the
> TLSv1.3
> > merge is integrated for 2.4.x, yeah, I wouldn't worry about that.
> >
> >
> > But I think this is worth highlighting in our Announcement, that we would
> > strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we
>
> Don't we see this issues with OpenSSL 1.1.0 as well?
>

Not that I'm aware of, these weren't changed in 1.1.0. Have been using
it for over a year without such issues. This is all the side effect of the
1.1.0 -> 1.1.1 default auth callback behavior change, IIUC.


> > could tease the forthcoming 2.4 release as building against 1.1.1/TLS
> 1.3.)
> >
> > Thoughts?
>
> Makes sense.
>

Re: NOTICE: Intent to T 2.4.35 in the next few hours

[William A Rowe Jr]

On Tue, Sep 18, 2018 at 2:43 AM Joe Orton  wrote:

> On Mon, Sep 17, 2018 at 06:16:34PM -0500, Daniel Ruggeri wrote:
> >Sorry - I know it wasn't a very good report. I was just seeing if
> > anyone has experienced a similar holdup. In fact, I let it run while
> > tending to other things and came back to see it had completed (but
> > failed), so perhaps it's not hung, but rather very slow.
> >
> > I'm using Debian 9 (stretch) in a container running on a 3.16.51-3
> > kernel. OpenSSL 1.1.1 is inside as well as several other dependencies...
> > these are the "latests" that my build scripts grabbed:
>
> You'll likely see issues testing against OpenSSL 1.1.1 until the TLSv1.3
> merge is integrated for 2.4.x, yeah, I wouldn't worry about that.


But I think this is worth highlighting in our Announcement, that we would
strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we
could tease the forthcoming 2.4 release as building against 1.1.1/TLS 1.3.)

Thoughts?

>
>

Re: svn commit: r1841176 - in /httpd/httpd/branches/2.4.x: docs/manual/ docs/manual/faq/ docs/manual/howto/ docs/manual/misc/ docs/manual/mod/ docs/manual/platform/ docs/manual/programs/ docs/manual/r

[William A Rowe Jr]

That was odd.

Consistent with the new literal characters in place of 's which was
discussed and accepted on list. Imagine nobody had performed the
`build.sh all` step in a little while.

Rev change was correct, so that's a positive. Will be testing shortly,
but optimistic. Thanks for RM'ing!

On Mon, Sep 17, 2018 at 7:53 PM  wrote:

> Author: druggeri
> Date: Tue Sep 18 00:53:10 2018
> New Revision: 1841176
>
> URL: http://svn.apache.org/viewvc?rev=1841176=rev
> Log:
> Get ready to tag httpd 2.4.35
>
>
> [This commit notification would consist of 96 parts,
> which exceeds the limit of 50 ones, so it was shortened to the summary.]
>

Re: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

[William A Rowe Jr]

So we kind of left this hanging...

On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith  wrote:

> On 6/15/2016 9:20 AM, William A Rowe Jr wrote:
> > In building httpd.exe, some users don't build and install openssl. It
> isn't
> > going
> > to be possible to simply #include  without some
> > conditional
> > test. OpenSSL itself is partly the culprit, for not having an
> > APPLINK_REQUIRED
> > style macro conditional. But we can work around this in the cmake tests.
> >
>
> This is why the patch creator put this inside a HAVE_OPENSSL block so
> ab.exe did not get this added. abs (at least on the dsp et. al.) is not
> built unless there is OpenSSL present.
>
> > I'll look at making this a standard bit of the httpd 2.4 build. We can
> > likely
> > add a user-toggled flag to the os/win32/os.h?
>
> Seems to me this is not needed .
>

So, is the win32 community in favor of using HAVE_OPENSSL to include
applink.c in the scope of main.c (as revised in the current ab.c sources,
to avoid this on libressl?)

There is a presumption that the crt used by libhttpd the same as libapr,
but I think this is a reasonable connection.

The entire logic to main.c should be as simple as...

#if defined(HAVE_OPENSSL) && defined(_MSC_VER) &&
!defined(LIBRESSL_VERSION_NUMBER)
/* The following logic ensures we correctly glue FILE* within one CRT used
 * by the OpenSSL library build to another CRT used by the ab.exe build.
 * This became especially problematic with Visual Studio 2015.
 */
#include 
#endif

By inserting the structure in httpd.exe, that structure can be found by the
openssl library, which is not true of including this in a loadable library
such as libhttpd.dll or libaprutil-1.dll.

Re: minor nit in mod_ssl

[William A Rowe Jr]

On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing 
wrote:
>
> mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when
strict_sni_vhost_check is enabled and a request comes in without SNI.
>
> Question: is a downgrade from ERR to INFO/DEBUG backportable or do we
consider this a break of compatibility?



On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr 
wrote:
>
> It is entirely appropriate to turn down the volume. That's what
module-by-module loglevels are there for.


This is the loglevel of typical garbage request streams;

[Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid
140199172134656] protocol.c(965): (20014)Internal error (specific
information not available): [client 127.0.0.1:34974] Failed to read request
header line (null)
[Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid
140199172134656] protocol.c(1318): [client 127.0.0.1:34974] AH00567:
request failed: error reading the headers
[Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid
140199180527360] protocol.c(860): [client 127.0.0.1:35330] AH02418: HTTP
Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was
injected?)

It seems that TLS missing SNI fits this same debug-level pattern of
diagnostics.

Re: NOTICE: Intent to T 2.4.35 in the next few hours

[William A Rowe Jr]

On Mon, Sep 17, 2018 at 12:08 PM William A Rowe Jr 
wrote:

> I'm similarly examining the win32 cmake build in anticipation.
>
> Thus far, the only issue is the mis-inclusion of applink.c; this is broken
> with openssl 1.1.1. Looking now for a resolution.
>

There is an issue, but it seems squarely with openssl 1.1.1. Copying
applink.c from the source tree ms/ path to the target path openssl/include/
did resolve the issue. With the backport Jim committed to fix proxy lbmethod
logic, everything seems fine on Win32 CMake builds.

Interestingly, this is from a unix line-ending checkout of sources, using
cmake, on a case-sensitive ntfs tree. After a couple fixes to openssl 1.1.1
branch, it is all working.

Re: NOTICE: Intent to T 2.4.35 in the next few hours

[William A Rowe Jr]

I'm similarly examining the win32 cmake build in anticipation.

Thus far, the only issue is the mis-inclusion of applink.c; this is broken
with openssl 1.1.1. Looking now for a resolution.

On Mon, Sep 17, 2018 at 10:02 AM Daniel Ruggeri 
wrote:

> Hi, all;
>
> STATUS is looking clean and my test suite is building/testing. Assuming
> those tests work out and life is happy, I will T 2.4.35 from 2.4.x
> branch in a few hours.
>
> I will also follow up in another couple weeks to T 2.4.36 if we can
> work in some of the newer features by then.
>
> --
> Daniel Ruggeri
>

Re: svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/t

[William A Rowe Jr]

On Mon, Sep 17, 2018 at 10:52 AM Jim Jagielski  wrote:

> Would like to also propose for apr-1.7...
>
> *Subject: **svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp
> atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c
> include/apr_atomic.h include/arch/unix/apr_arch_atomic.h test/testatomic.c*
>
>
+1.

Re: minor nit in mod_ssl

[William A Rowe Jr]

It is entirely appropriate to turn down the volume. That's what
module-by-module loglevels are there for.


On Mon, Sep 17, 2018, 02:56 Stefan Eissing 
wrote:

> Just a quick question, if we can reach consensus here:
>
> mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when
> strict_sni_vhost_check is enabled and a request comes in without SNI.
>
> Question: is a downgrade from ERR to INFO/DEBUG backportable or do we
> consider this a break of compatibility?
>
>
> Rationale: This is annoying me in my logs where I scan for errors daily.
> While I can filter this out, I'd rather have the server behave better by
> default. The requests at my server are done by scanners, who monitor
> responses on port 443. Nothing I can do about and they will not go away.
>
> Cheers,
>
> Stefan
>
>

URL escape-folding security issues history

[William A Rowe Jr]

As recently disclosed in;

https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2016-4975

Sergey Bobrov brought this disclosure of a moderate vulnerability in
mod_userdir to the httpd project security@ team. Given various examples of
invalid and valid request URL's, even the valid input could inject a %0D or
%0A URL sequence as a raw byte into the response headers stream. The actual
%0D or %0A are valid request URL bytes, but their decoded forms must not be
exchanged over HTTP.

This behavior pattern is not isolated to mod_userdir, and a fix to the
userdir module alone would be insufficient to address the class of issues.
When the project addressed bad request input in 2.4.25, there was a
corresponding change (with further cleanup in 2.4.26) to review the
resulting response output headers, and reject un-encoded ctrl characters as
500 responses (module/app/script error, uncorrectable by the user-agent).
That change provided one last backstop against module processing of decoded
input resulting in control characters injected in output headers with
malicious intent.

Note that response filter/rejection did not address a specific CVE and was
not a security bugfix, but it was a mitigation that worked into the
correction of many actual request handling security defects addressed by;

https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2016-8743

This change, in 2.4.25 and 2.4.26 (with similar fixes in 2.2.final), were
collected here from a great number of commits assembled publicly, without
comment as to their impact on security during the review process;

https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x-merge-http-strict/

This broad refactoring for strictness was also supported with the
vulnerability reports and observations presented to security@httpd by Régis
Leroy, and by Peter Allor and his colleagues at IBM.

It is worth also noting that the bulk of this refactoring had already long
existed in trunk by the efforts of committer Stefan Fritsch (sf) to
introduce RFC compliance checks, which under usual principals could not
have been backported. (Many sites adopting this fix first encountered
significant breakage and fallout in their custom, in-house tooling which
was never RFC compliant and relied on the server's permissiveness of LF
line endings. In a normal scenario, such behavior changes are deferred to
2.next.)

This is not the end of the list of issues. Although it failed to gain
traction as a distinct CVE, June 14th of '16, Sergey Bobrov brought yet
another vulnerability to the security@httpd team in the handling of the
RedirectMatch transformations, yielding the same results through a
different defect in a distinct module. The confusion arose as some security
team participants viewed these one-in-the-same in the realm of bad output.

Jacob Champion and I further reviewed a great number of mappings that occur
throughout the httpd code base, and that audit convinced the security team
that mitigating the results, and distributing this workaround broadly and
widely, was more important than correcting the individual defects.

So over a year after distribution of the mitigation, there are two groups
of action items to address next;

1. There are several patches which will be suggested to the many
redirection modules, to ensure control chars are re-encoded, and those
request responses will no longer return 500 errors, but will return
location: headers with properly escaped ctrl characters. There are further
audit results which can be reconsidered. We can do this now at a measured
and public pace.

2. The underlying API, decoding %-escapes early, lends itself to the
impossibility of handling every request correctly. The only way to fix this
is to break several assumptions by module authors, and change the actual
definitions of several URL-related structure members. The encoded/decoded
state needs to be better defined, and better APIs to manipulate the URL
need to be introduced. We cannot do this in 2.4.x, but it needs to be
incorporated in whatever 2.next (or 3.0) follows the current maintenance
release.

Thank you for taking the time to read this background, we will be
forwarding various ideas from the security@ private list here to spark
discussion around revamping the URL manipulation API, and pushing forward
the true corrections of the underlying URL escaping bugs over the coming
weeks.

Re: 2.4.35 in Sept?

[William A Rowe Jr]

I'm unaware of anything blocking a tag today, if someone wants to proceed.
What is gained by waiting a few days to slip in another rushed patch to
break yet another release?

I see nothing in STATUS necessary to fix 2.4 regressions, but many proposed
behavioral changes which suggest the likelyhood of new regressions.

A minimal 2.4.35, and an optimistic 2.4.36 enhancement release within weeks
of one another serves all interests, a stable 2.4 and early adoption 2.4.
Users can back down to 2.4. 35 instead of way back to 2.4.29 or earlier, in
the event of new issues in such a 2.4.36 release which includes TLS 1.3
support.



On Thu, Sep 13, 2018, 14:09 Gregg Smith  wrote:

> On 9/12/2018 1:47 PM, Jim Jagielski wrote:
> >
> > What improvements do you have to suggest to improve upon this? Do you
> recommend a longer vote time? Do you recommend beta and/or
> release-candidates? Do you recommend that the 1st born of all voters be
> held in a camp until the release has "proven" itself to be up to your
> satisfaction ensuring that said voters have "skin in the game"?
> >
> IMO a couple extra days wouldn't hurt unless its fixing a 0day.
>

Re: 2.4.35 in Sept?

[William A Rowe Jr]

On Tue, Sep 11, 2018 at 8:01 AM Jim Jagielski  wrote:

> If there is still interest, there are a handful of useful backports in
> STATUS that could use review, testing and voting :-)
>

Unless the goal is to replace one set of regressions with a new set
of regressions, it's past due to tag 2.4.35 before "useful" returns as
the de facto criteria again on 2.4.x.

Because the TLS 1.3 patchset is significantly bigger, I'd appreciate
an httpd release prior to merging that effort. So we have 2.4.35 entirely
usable, and soon thereafter, 2.4.36 with TLS 1.3, and whatever "useful"
additions people want to pile on (as observed of the 2.4/trunk diff).

Since we still have no schema to solve the project maintenance side of
shipping source code, getting 2.4.35 with principally regression-fixes out
the door before new regressions are added seems wise. I'm happy to
offer to RM this coming Monday if nobody beats me to it, if we believe
all of the known regressions have been closed.

Is anyone aware of any lingering regression fixes to apply for 2.4.35
in the immediate-term?

September for 2.4.36 w/TLS 1.3 still seems plausible. If we really want
to prove up that patch set, 2.5.1-alpha sooner rather than later might
make good sense, and would likely attract more attention than a typical
alpha owing to draft TLS 1.3 support alone.

Re: 2.4.x and 2.6.x ... next steps

[William A Rowe Jr]

On Wed, Sep 12, 2018, 09:19 Graham Leggett  wrote:

> On 12 Sep 2018, at 15:39, William A Rowe Jr  wrote:
>
> > Now, why would we *need* a 2.5.x branch?
>
> The primary need is to remove stuff that we deem not-ready-for-2.6-yet.
> Modules without any docs for example would need to be either documented or
> removed-from-2.5-that-will-become-2.6, keeping trunk as it is.


If it is not ready, it should not pollute trunk. Think of this as an
exercise to prune things unlikely to ever be hashed out completely. Why put
off the inevitable and force this set of issues on the 2.7.x maintainers
down the road?

We have a sandbox; things that must still be proven up need to be moved
there and pruned sometime in the next 10 years, if then.

Re: 2.4.x and 2.6.x ... next steps

[William A Rowe Jr]

Going to largely ignore most other input on this thread, beyond the
underlying proposals to branch 2.5.x and move to RTC...

On Wed, Sep 12, 2018, 03:20 Stefan Eissing 
wrote:

> In my estimation, cleaning up trunk (or a copy of it) via RTC will take
> forever, at least.
>
> And while that continues, any bugfix can only be done in trunk. We then
> need 2(!) RTC proposals and votes per fix if it affects 2.4.x. (Which,
> until 2.6 is out and gets adopted, will be the case almost all of the time.)
>
> We do not even find enough people to look at the proposals for 2.4.x. It's
> easier to find people outside the project to test fixes in their production
> systems.
>
> Short: I  do not believe this can work.
>

I completely agree.

If we pause to consider how we got to http2 already, it was because of
Stefan's massive efforts *in CTR mode*. Would this have been a reasonable
project to launch in RTC? IMO, no.

If we trust our committers, CTR will let us make far more progress in far
less time. Note that all major proposals must be taken to the dev list
anyways.

Note that RTC fails to intercept as many bugs as it catches, as easily
observed during the 2.4.x generation, but at a very large cost in terms of
development feedback loop timing.

If we do not trust our committers we have a much different issue that RTC
does not address.

2.5.x are entirely alpha/beta releases, nobody will flinch at a regression
or bug.

Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)

[William A Rowe Jr]

On Wed, Sep 12, 2018 at 7:49 AM Jim Jagielski  wrote:

> As I said before, the main assumption in my suggestion is that there are
> things in trunk that "really should" be in some releasable version


Everything in trunk is now digested into three groups of commits, for
inspection. These don't include whitespace changes, so the resulting files
may be mis-indented and otherwise skewed, but we are looking for changes,
not insignificant formatting;

Just the docs (sources, and generated)
http://svn.apache.org/viewvc?view=revision=1840682
http://svn.apache.org/viewvc?view=revision=1840684

Just win32 generated build gunk (presuming vcproj and CMake are both
winners, there is a discussion to be had on .mak files before this gap is
addressed)
http://svn.apache.org/viewvc?view=revision=1840687

Everything else (all the interesting stuff)
http://svn.apache.org/viewvc?view=revision=1840688

I expect committers will be mostly interested in the last link above.

Re: 2.4.x and 2.6.x ... next steps

[William A Rowe Jr]

On Wed, Sep 12, 2018, 07:41 Jim Jagielski  wrote:

> Ahh. I think I see the problem! For some reason Bill sees this as somehow
> Jim's (my) fork. It's not. It's a  svn branch from HEAD of trunk, which
> contains
> all the changes. That branch is the projects's branch not some personal
> fork, whatever that means.
>

So although others mentioned 2.4.x branch, this is not the origin of YOUR
proposal. Wow, that simplifies this discussion a lot (and hopefully, our
new committers who never even corresponded with some long absent colleagues
now see my concern with the dismissiveness against using trunk.) Sorry that
I misattributed that part of the discussion to your proposal.

Here is the problem I have with forking today. I expect you know I have no
problem with tagging 2.5.1-alpha any day of the week and putting 2.5
candidates up for release vote.

During the 'development' of 2.odd we have no need to fork, because all
API/ABI changes are permitted between 2.5.1 and 2.5.2. Our trunk needs to
be usable all the time, not just during this release prep. But, forking
introduces a mess of svn maintenance to no justified purpose.

And most of all, we need to trust our fellow committers. It is clear that
review before or after does not eliminate all errors. But 2.5 will not be
GA (2.6 will be.)

The straight line, avoiding a ton of excess backports, and keeping it
simple on the RM, is to either 1. Tag from the final, accepted 2.5.x svn
commit rev into 2.6.x branch, or 2. from trunk to 2.6.x branch if the RM
believes the changes are limited risk, and can be vetted during the release
vote.

Forking 2.5.x says, outright, I don't trust my fellow committers with
commit bits to the alpha/beta development branch. That is also a bad signal
to send

Now, why would we *need* a 2.5.x branch? The only thing I can picture is
someone proposes post-2.6 work. And for the time being, such work can and
should live in a sandbox, imo.

Again, sorry I missed the transition from discussing trunk to discussing
2.4.x branch. I completely support your initial suggestion of the basis,
modulo tagging these pre-2.6.0 candidates directly on trunk.

Re: 2.4.x and 2.6.x ... next steps

[William A Rowe Jr]

On Wed, Sep 12, 2018, 04:16 Daniel Gruno  wrote:

> On 09/12/2018 10:58 AM, Graham Leggett wrote:
> > On 12 Sep 2018, at 03:15, William A Rowe Jr  > <mailto:wr...@rowe-clan.net>> wrote:
> >
> >> On Tue, Sep 11, 2018, 17:42 Graham Leggett  >> <mailto:minf...@sharp.fm>> wrote:
> >>
> >> On 11 Sep 2018, at 20:35, Jim Jagielski  >> <mailto:j...@jagunet.com>> wrote:
> >>
> >> > This is what I propose:
> >> >
> >> >  o Later on this week I svn cp trunk over to branches/2.5.x
> >>
> >>
> >> -1 ... Veto on the basis of project bylaws. Propose a revision for
> voting.
> >
> > I've totally lost you. Jim describes creating a branch, how is this
> > related to voting?
>
> I am not Bill, but it is likely a reference to the fact that you can
> veto code changes, not community/workflow changes. I see Jim's proposal
> as the latter, so I'm not sure why the attempted veto. The codebase
> itself isn't being changed from what I can gather, only the workflow is.
>

Yes. To be clear, the proposal to make 2.5 Jim's fork, discarding all
previously committed changes to 2.5 (and I suppose, renumbering trunk as
2.7) is a change to the project development process at httpd.

As-it-stands, such a personal fork is vetoable. And flies in sharp contrast
to community over code, discarding the existing collaboration of 2.5.1-dev
trunk in favor of one participants agenda.

Note, sandboxes are encouraged, don't require any vote to start one, and
might lead to some compromise between points a and b.

I suggest above, propose a *process* revision to our /dev/ docs for a vote,
before proceeding to violate community norms on versioning. Sorry for the
confusion about what I was proposing to 'revise'.

As a project committee vote to change our operational process, that is a
simple majority vote, as Daniel observes, which would carve out space for a
zombie (never to be released) trunk,

Re: 2.4.x and 2.6.x ... next steps

[William A Rowe Jr]

On Tue, Sep 11, 2018, 13:35 Jim Jagielski  wrote:

>
> And finally, we have some things in trunk that will likely
> need to be majorly fixed or else scrapped.
>

Please catalog these things.

The reason that even-odds minor versions exist is to clean up trunk for a
GA release. Otherwise we would have stayed with the 2.0.x release model.

RTC -> CTR between trunk n.odd releases and branched n.even GA releases was
a carefully choregraphed compromise between PMC members who wanted a
dynamic project and PMC members who wanted stability.

Hijacking the project to follow only one of those models is to
disenfranchise the other side of the community, which is a pretty abrupt
slap at ASF values.

You are right that what is on trunk needs the consideration of alpha and
beta releases to meet with our collective approval, and is not at this time
ready for GA.

Since every change has passed through trunk and every committer has
reviewed their patches against their own build of trunk, it's laughable to
suggest that trunk is 'unstable'.

For someone who strongly agrees merit never expires to suggest discarding
the work of all committers whose works were 'to be included' in 2.5 flies
in the face of all founding principals I'm aware of.

Please reconsider your proposal in light of this simple objection out of
respect for your fellow committers.

Re: 2.4.x and 2.6.x ... next steps

[William A Rowe Jr]

On Tue, Sep 11, 2018, 17:42 Graham Leggett  wrote:

> On 11 Sep 2018, at 20:35, Jim Jagielski  wrote:
>
> > This is what I propose:
> >
> >  o Later on this week I svn cp trunk over to branches/2.5.x
>

-1 ... Veto on the basis of project bylaws. Propose a revision for voting.

>  o That branch becomes the initial source for 2.6.x
>

As practiced in 2.1 and 2.3, trunk, forked to 2.6, is the basis for release
branches.

>  o trunk remains CTR, whereas branches/2.5.x becomes RTC
>

The alpha/beta branches 2.1, 2.3 were never RTC. Veto based on project
guidelines.

>ala 2.4.x (ie: using STATUS and specific, targeted
> >backport requests).
> >  o Backports to 2.4.x only come from 2.5.x

>  o We then release a 2nd alpha from branches/2.5.x
> >  o We get 2.5.x into a releasable stage, whereas we
> >svn mv branches/2.5.x to branches/2.6.x
>
> +1.
>

-1. svn cp trunk 2.6.x.

To clarify the above, this describes what we did last time when we went
> from 2.2 to 2.4.


You are entirely misinformed.

When we went from 2.2 (and 2.0) we remained on trunk.

2.3 (and 2.1) was unstable, API's changed, MMN major was bumped every time
it was a breaking change.

The code on trunk is always CTR.

When we went from 2.3 (and 2.1) we forked trunk.

The code following the first GA release is RTC.

Nothing about the above is out of the ordinary based on what we’ve done in
> the past.
>

No, we have never begun a new major.minor branch as RTC.

We have never dropped code without requiring an actual veto, or the
committee withdrawing their code.

This is an attempt to turn httpd into an RTC project.

This is an attempt to discard the work of all committers who were told
their code wouldn't be included until the next version major.minor.
Complete disenfranchisement via a pocket veto of all changes.

If this is desirable, hold a discussion and then vote on project
bylaws/guidelines revisions to make that happen.

If it desireable, hold a vote to discard trunk altogether, svn rm it, and
replace it with 2.4.x branch.

The very idea that this is how httpd (or sibling projects such as apr or
Perl) have ever conducted ourselves is absurd.

If you want an example of how this goes wrong and how it has been addressed
elsewhere, the OpenSSL project git history is a good place to start.

But let's not start introducing fictions that httpd project has followed
the track above. During 2.4.0 phase, we did in fact drop out the apreq API
by backing up to before that addition, based on the belief at that time
that it was not mature enough. Otherwise the RTC trunk 2.3.x became CTR
2.4.x branch.

Re: TLSv1.3 supprt for 2.4.x?

[William A Rowe Jr]

On Thu, Sep 6, 2018 at 3:13 AM Stefan Eissing 
wrote:

>
> > I can't imagine the project releasing this changeset without first
> releasing
> > a stable 2.4.35, followed shortly thereafter with a less stable TLS 1.3
> > release. It appears to introduce a set of required(?) config changes,
> > something we've never purposefully done in a major.minor update.
>
> I think we will find common ground in that we do not want to interrupt
> existing
> httpd deployments with such a feature. On the other hand, we have a
> responsibility
> also as one of the leading HTTP servers on this planet, to enable our
> users to
> protect themselves by applying the latest tech in security.
>
> This, we have to balance.
>
> Precisely for this feature, we need to evaluate:
> - do we introduce config breaking changes?
>   I added the optional parameter to SSLCipherSuite in a way that does not
> (or should not) affect existing configurations. If I erred, it would be
> good to find out.
>

+1 - no breaking changes. Adding the parameter optional (default TLS 1.2
and earlier) should accomplish this. Trusting OpenSSL initially to provide
only more-secure TLS 1.3 ciphers suggests that folks won't need to drop
ciphers from that list for some time, yet.


> - does this change affect servers linked with OpenSSL 1.0.x or older?
>   The intention of the change is to not do that. The guarding of changes
> by #ifdef make it work with OpenSSL 1.0.2 for me. I invited Bernard
> explicitly to test his libressl setups to get broader coverage. Maybe
> Rainer and Rüdiger will find the time to tests their various setups.
>

+1 - If we still compile successfully against 0.9.8/1.0.0/1.0.1 it would be
a kindness to our users on older OS distributions, granted only 1.0.2 and
onwards are still "supported" by OpenSSL, but OS vendors may be maintaining
their forks longer.


> - servers linking with a latest *SSL library (or distros shipping it that
> way) will see TLSv1.3 enabled, unless the configurations remove it
> explicitly. I think, based on feedback from others, this is what we want to
> happen.
>

+1 - Given the (presumably) sane set of defaults.


> All this can and should be discussed by bringing forth technical arguments
> or counter examples, IMO. For the release, there will be voting, just as
> with other backport proposals, will it not?
>

Agreed, as to review for release. To the subject top-thread, feedback to
the merge branch would be early, easy, appreciated, and save iterations, so
is not a waste of effort for those willing to review the design decisions.
For who are uncomfortable running ./buildconf against a checkout, they do
not lose the opportunity to review.

Re: svn commit: r1840265 - in /httpd/httpd/trunk: include/ap_mmn.h include/util_filter.h modules/http/http_request.c server/core_filters.c server/util_filter.c

[William A Rowe Jr]

On Fri, Sep 7, 2018 at 4:52 AM Yann Ylavic  wrote:

>
> There probably are other "includes/" candidates, like:
>   ap_expr_init (ap_expr.h)
>   ap_open_logs (http_log.h)
>   ap_logs_child_init (http_log.h)
>   ap_add_output_filters_by_type (http_core.h)
>   ap_core_reorder_directories (http_core.h)
>   ap_process_async_request (http_request.h)
>   ap_create_scoreboard (scoreboard.h)
>   ap_http_filter (mod_core.h)
>   ap_http_chunk_filter (mod_core.h)
>   ap_http_outerror_filter (mod_core.h)
>   ap_response_code_string (mod_core.h)
>   util_ldap_cache_init (util_ldap.h)
>   util_ald_cache_display (util_ldap.h)
>   ...
>
> Shouldn't we do something fot them too?
>

Keep in mind third party MPM's... but yes many of these are good candidates
for internals, +1 after review.

Re: svn commit: r1840265 - in /httpd/httpd/trunk: include/ap_mmn.h include/util_filter.h modules/http/http_request.c server/core_filters.c server/util_filter.c

[William A Rowe Jr]

I'd suggest you did a better job in the commit log explaning this than in
the doxygen where it really is needed.

Private declares don't belong in util_filter.h IMO.

On Thu, Sep 6, 2018, 17:48  wrote:

> Author: ylavic
> Date: Thu Sep  6 22:48:28 2018
> New Revision: 1840265
>
> URL: http://svn.apache.org/viewvc?rev=1840265=rev
> Log:
> Follow up to r1840149: core input filter pending data.
>
> Since r1840149 ap_core_input_filter() can't use use f->[priv->]bb
> directly, so
> ap_filter_input_pending() stopped accounting for its pending data.
>
> But ap_core_input_filter() can't (and doesn't need to) setaside its socket
> bucket, so ap_filter_setaside_brigade() is not an option. This commit adds
> ap_filter_adopt_brigade() which simply moves the given buckets (brigade)
> into
> f->priv->bb, and since this is not something to be done blindly (the
> buckets
> need to have c->pool/bucket_alloc lifetime, which is the case in the core
> filter) the function is not AP_DECLAREd/exported thus can be used in core
> only.
>
> With ap_filter_adopt_brigade() and ap_filter_reinstate_brigade(), the core
> input is now ap_filter_input_pending() friendly.
>
> Also, ap_filter_recycle() is no more part of the API (AP_DECLARE removed
> too),
> there really is no point to call it outside core code. MAJOR bumped once
> again
> because of this.
>
> Modified:
> httpd/httpd/trunk/include/ap_mmn.h
> httpd/httpd/trunk/include/util_filter.h
> httpd/httpd/trunk/modules/http/http_request.c
> httpd/httpd/trunk/server/core_filters.c
> httpd/httpd/trunk/server/util_filter.c
>
> Modified: httpd/httpd/trunk/include/ap_mmn.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1840265=1840264=1840265=diff
>
> ==
> --- httpd/httpd/trunk/include/ap_mmn.h (original)
> +++ httpd/httpd/trunk/include/ap_mmn.h Thu Sep  6 22:48:28 2018
> @@ -606,12 +606,13 @@
>   * ap_acquire_brigade()/ap_release_brigade(), and
>   * in ap_filter_t replace pending/bb/deferred_pool
>   * fields by struct ap_filter_private *priv
> + * 20180906.1 (2.5.1-dev)  Don't export ap_filter_recycle() anymore
>   */
>
>  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
>
>  #ifndef MODULE_MAGIC_NUMBER_MAJOR
> -#define MODULE_MAGIC_NUMBER_MAJOR 20180905
> +#define MODULE_MAGIC_NUMBER_MAJOR 20180906
>  #endif
>  #define MODULE_MAGIC_NUMBER_MINOR 1 /* 0...n */
>
>
> Modified: httpd/httpd/trunk/include/util_filter.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/util_filter.h?rev=1840265=1840264=1840265=diff
>
> ==
> --- httpd/httpd/trunk/include/util_filter.h (original)
> +++ httpd/httpd/trunk/include/util_filter.h Thu Sep  6 22:48:28 2018
> @@ -596,6 +596,16 @@ AP_DECLARE(int) ap_filter_prepare_brigad
>  AP_DECLARE(apr_status_t) ap_filter_setaside_brigade(ap_filter_t *f,
>  apr_bucket_brigade
> *bb);
>
> +/*
> + * Adopt a bucket brigade as is (no setaside nor copy).
> + * @param f The current filter
> + * @param bb The bucket brigade adopted.  This brigade is always empty
> + *  on return
> + * @remark httpd internal, not exported, needed by
> + *   ap_core_input_filter
> + */
> +void ap_filter_adopt_brigade(ap_filter_t *f, apr_bucket_brigade *bb);
> +
>  /**
>   * Reinstate a brigade setaside earlier, and calculate the amount of data
> we
>   * should write based on the presence of flush buckets, size limits on in
> @@ -656,14 +666,17 @@ AP_DECLARE_NONSTD(int) ap_filter_output_
>   */
>  AP_DECLARE_NONSTD(int) ap_filter_input_pending(conn_rec *c);
>
> -/**
> +/*
>   * Recycle removed request filters so that they can be reused for filters
>   * added later on the same connection. This typically should happen after
>   * each request handling.
>   *
>   * @param c The connection.
> + * @remark httpd internal, not exported, needed by
> + * ap_process_request_after_handler
> + *
>   */
> -AP_DECLARE(void) ap_filter_recycle(conn_rec *c);
> +void ap_filter_recycle(conn_rec *c);
>
>  /**
>   * Flush function for apr_brigade_* calls.  This calls ap_pass_brigade
>
> Modified: httpd/httpd/trunk/modules/http/http_request.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_request.c?rev=1840265=1840264=1840265=diff
>
> ==
> --- httpd/httpd/trunk/modules/http/http_request.c (original)
> +++ httpd/httpd/trunk/modules/http/http_request.c Thu Sep  6 22:48:28 2018
> @@ -402,10 +402,7 @@ AP_DECLARE(void) ap_process_request_afte
>  (void)ap_check_pipeline(c, bb, DEFAULT_LIMIT_BLANK_LINES);
>
>  ap_release_brigade(c, bb);
> -
> -if (!c->aborted) {
> -ap_filter_recycle(c);
> -}
> +

Re: TLSv1.3 supprt for 2.4.x?

[William A Rowe Jr]

On Wed, Sep 5, 2018 at 10:52 AM, Dennis Clarke 
wrote:

> On 09/05/2018 07:36 AM, Stefan Eissing wrote:
>
>> A member of the OpenSSL project gave me a "go ahead" and we now have
>> branch:
>>
>> https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x
>>
>> as a copy of 2.4.x with 1827912,1827924,1827992,182822
>> 2,1828720,1828723,1833588,1833589,1839920,1839946 merged in. If was not
>> a clean merge as some feature from trunk are not present in 2.4.x, so peer
>> review/test is definitely desired.
>>
>> I put a backport proposal into 2.4.x/STATUS
>>
>> Cheers, Stefan
>>
>
>
> Awesome but there are plenty of folks that will want a simple tarball
> with the usual autoconf/configure magic done for them. Could be a waste
> of effort given that OpenSSL 1.1.1 release is 6 days away.


Not a waste of effort.

The project can't realistically deliver such a large changeset without wider
testing, the number of issues raised on multiple forums demonstrate that.
(Thankfully > 50% are users who were unaware of draft vs. final TLS
handshake signatures, and such inattentive users aren't productively
contributing to interoperability review.) Users who are prepared to
*constructively* engage on any proposed changeset should have few
problems with a couple extra steps.

I can't imagine the project releasing this changeset without first releasing
a stable 2.4.35, followed shortly thereafter with a less stable TLS 1.3
release. It appears to introduce a set of required(?) config changes,
something we've never purposefully done in a major.minor update.

Fwd: [Bug 62590] performance drop after moving from apache 2.2 to apache 2.4

[William A Rowe Jr]

As we unwind various regressions and breakage, one non-lethal but somewhat
horrid report stands out. Eric correctly tied it to the patch applied for
https://bz.apache.org/bugzilla/show_bug.cgi?id=62590 in the 2.4.24
timeframe.

Server Software:Apache/2.2.34
SSL/TLS Protocol:   TLSv1/SSLv3,AES256-GCM-SHA384,1024,256

vs

Server Software:Apache/2.4.34SSL/TLS Protocol:
TLSv1/SSLv3,AES256-GCM-SHA384,1024,256

Measures out with

Time taken for tests: 192.131 seconds Total transferred: 731130414 bytes
HTML transferred: 8800 bytes Requests per second: 10409.59 [#/sec]
(mean) Time per request: 5.764 [ms] (mean) Time per request: 0.096 [ms]
(mean, across all concurrent requests) Transfer rate: 3716.20 [Kbytes/sec]
received

vs

Time taken for tests:   571.058 seconds
Total transferred:  689130083 bytes
HTML transferred:   9000 bytes
Requests per second:3502.27 [#/sec] (mean)
Time per request:   17.132 [ms] (mean)
Time per request:   0.286 [ms] (mean, across all concurrent requests)
Transfer rate:  1178.48 [Kbytes/sec] received





Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   0.4  0  87
Processing: 06   1.2  6  71
Waiting:06   1.2  5  70
Total:  06   1.3  6  98

Percentage of the requests served within a certain time (ms)
  50%  6
  66%  6
  75%  6
  80%  6
  90%  7
  95%  8
  98%  9
  99% 10
 100% 98 (longest request)



I did then the same for Apache/2.4.34 (with apr-1.6.3 and
apr-util-1.6.1), with the following changes in the httpd.conf
(including ssl-support):
StartServers 1
ServerLimit  1
ThreadLimit  2500
ThreadsPerChild  2500
ThreadStackSize  1048576
MinSpareThreads  1
MaxSpareThreads  500
MaxRequestWorkers  2500
MaxConnectionsPerChild  0


and here the output of ApacheBench:

ab -k -n 200 -c 60 'https://adnvl005:44300/'
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking adnvl005 (be patient)
Completed 20 requests
Completed 40 requests
Completed 60 requests
Completed 80 requests
Completed 100 requests
Completed 120 requests
Completed 140 requests
Completed 160 requests
Completed 180 requests
Completed 200 requests
Finished 200 requests


Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   2.1  0 208
Processing: 0   17  20.3 10 285
Waiting:0   17  20.3 10 285
Total:  0   17  20.4 10 285

Percentage of the requests served within a certain time (ms)
  50% 10
  66% 16
  75% 23
  80% 28
  90% 44
  95% 59
  98% 79
  99% 94
 100%285 (longest request)




-- Forwarded message --
From: 
Date: Mon, Aug 27, 2018 at 9:11 AM
Subject: [Bug 62590] performance drop after moving from apache 2.2 to
apache 2.4
To: b...@httpd.apache.org


https://bz.apache.org/bugzilla/show_bug.cgi?id=62590

--- Comment #1 from paolo  ---
After some debug-session I found out that  the problem are the
ERR_clear_error
calls in ssl_filter_write and ssl_io_input_read. If I remove those calls the
performance is the same like with httpd/2.2.

Are those calls really needed in the ssl_io_input_read/ssl_filter_write
function?
Isn't it enough to have it only in the ssl_io_filter_handshake function.

Or what about to call this function only if an error occurred:

else /* (rc < 0) */ {
int ssl_err = SSL_get_error(inctx->filter_ctx->pssl, rc);
conn_rec *c = (conn_rec*)SSL_get_app_data(
inctx->filter_ctx->pssl);

 +   ERR_clear_error();

if (ssl_err == SSL_ERROR_WANT_READ) {


Many thanks for any answer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

Re: svn commit: r1838941 - /httpd/httpd/trunk/modules/proxy/mod_proxy.h

[William A Rowe Jr]

MMN major, please?

On Fri, Aug 24, 2018 at 2:46 PM,  wrote:

> Author: jim
> Date: Fri Aug 24 19:46:57 2018
> New Revision: 1838941
>
> URL: http://svn.apache.org/viewvc?rev=1838941=rev
> Log:
> better struct layout ...
>
> Modified:
> httpd/httpd/trunk/modules/proxy/mod_proxy.h
>
> Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.h
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/
> proxy/mod_proxy.h?rev=1838941=1838940=1838941=diff
> 
> ==
> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Fri Aug 24 19:46:57 2018
> @@ -403,6 +403,9 @@ typedef struct {
>  char  uds_path[PROXY_WORKER_MAX_NAME_SIZE];   /* path to
> worker's unix domain socket if applicable */
>  char  hcuri[PROXY_WORKER_MAX_ROUTE_SIZE]; /* health check
> uri */
>  char  hcexpr[PROXY_WORKER_MAX_SCHEME_SIZE];   /* name of
> condition expr for health check */
> +char  secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication
> secret (e.g. AJP13) */
> +char  upgrade[PROXY_WORKER_MAX_SCHEME_SIZE];/* upgrade protocol
> used by mod_proxy_wstunnel */
> +char  hostname_ex[PROXY_RFC1035_HOSTNAME_SIZE];  /* RFC1035
> compliant version of the remote backend address */
>  int lbset;  /* load balancer cluster set */
>  int retries;/* number of retries on this worker */
>  int lbstatus;   /* Current lbstatus */
> @@ -438,14 +441,11 @@ typedef struct {
>  apr_size_t  io_buffer_size;
>  apr_size_t  elected;/* Number of times the worker was elected
> */
>  apr_size_t  busy;   /* busyness factor */
> +apr_size_t  response_field_size; /* Size of proxy response buffer
> in bytes. */
>  apr_port_t  port;
>  apr_off_t   transferred;/* Number of bytes transferred to remote
> */
>  apr_off_t   read;   /* Number of bytes read from remote */
>  void*context;   /* general purpose storage */
> -char  secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication
> secret (e.g. AJP13) */
> -char  upgrade[PROXY_WORKER_MAX_SCHEME_SIZE];/* upgrade protocol
> used by mod_proxy_wstunnel */
> -char  hostname_ex[PROXY_RFC1035_HOSTNAME_SIZE];  /* RFC1035
> compliant version of the remote backend address */
> -apr_size_t   response_field_size; /* Size of proxy response buffer in
> bytes. */
>  unsigned int keepalive:1;
>  unsigned int disablereuse:1;
>  unsigned int is_address_reusable:1;
> @@ -460,7 +460,7 @@ typedef struct {
>  unsigned int disablereuse_set:1;
>  unsigned int was_malloced:1;
>  unsigned int is_name_matchable:1;
> -unsigned int response_field_size_set:1;
> +unsigned int response_field_size_set:1;
>  } proxy_worker_shared;
>
>  #define ALIGNED_PROXY_WORKER_SHARED_SIZE (APR_ALIGN_DEFAULT(sizeof(
> proxy_worker_shared)))
>
>
>

Re: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ modules/proxy/ modules/proxy/balancers/

[William A Rowe Jr]

On Fri, Jul 20, 2018 at 2:27 PM,  wrote:

> Author: rpluem
> Date: Fri Jul 20 19:27:31 2018
> New Revision: 1836381
>
> URL: http://svn.apache.org/viewvc?rev=1836381=rev
> Log:
> * mod_proxy: Remove load order and link dependency between mod_lbmethod_*
>   modules and mod_proxy by providing mod_proxy's
> ap_proxy_balancer_get_best_worker
>   as an optional function.
>

Thanks Rüdiger!

Not sure if I missed this, but did you want to advance this regression
fix on the 2.4.x branch? That seems to be one showstopper to getting
us to a maintenance/stabilizing release.

Re: Specific regressions to promptly address for 2.4.35?

[William A Rowe Jr]

I understand many of us had holidays etc, and the dev list and bug tracker
haven't been followed as closely.

To help you and others find this answer ourselves, a new keyword
'Regression' is now added to the httpd bugzilla.

Although it is not required, adding BZ tickets for dev and users list
reports, or our own observed and fixed defects helps users later answer
their own questions, reducing the number of duplicate reports on list. Well
worth that initial effort.



On Thu, Aug 9, 2018, 06:35 Jim Jagielski  wrote:

>
>
> > On Aug 9, 2018, at 12:11 AM, William A Rowe Jr 
> wrote:
> >
> >
> > You didn't seriously expect me to rise to that bait? No, I wasn't
> planning to bring you a rock
>
> It's not a rock... if you expect people to review patches, certainly those
> patches should be available someplace, right? I'm not seeing anything in
> STATUS that references these.
>
> The only one I can easily find is the OCSP one, but even that looks like
> the suggested patch is waiting for confirmation that it fixes the bug...

Re: t/apache/getfile.t

[William A Rowe Jr]

On Thu, Aug 9, 2018 at 1:06 PM, Eric Covener  wrote:

> On Thu, Aug 9, 2018 at 11:02 AM Jim Jagielski  wrote:
> >
> > Anyone having issues w/ the above test hanging after test 182?
> >
> > On the 2.4.x branch it runs thru to completion, but on trunk (macOS),
> > stalls after 182:
>
> For me on trunk at least (2.4 sandbox is unhealthy) it seems to hang
> in different tests from run to run.
>

Clarification please... do you mean your 2.4 build/test environment, or
our 2.4.x branch?

Re: Specific regressions to promptly address for 2.4.35?

[William A Rowe Jr]

On Wed, Aug 8, 2018, 23:11 William A Rowe Jr  wrote:

> On Tue, Aug 7, 2018, 10:55 Jim Jagielski  wrote:
>
>>
>>
>> On Aug 7, 2018, at 11:21 AM, William A Rowe Jr 
>> wrote:
>>
>>
>> Specific regressions as requested by Jim, posted on users@ and dev@
>> which are showstoppers to upgrading for some;
>>
>> - Non-HTTP responses from mod_ratelimit with delayed content (cgi, proxy)
>>   * Breaking regression for module users (from sporadic to consistent)
>>   * Fixed by elukey and ylavic
>>
>> - SSLOCSP directives breakage
>>   * Broke some configs due to inheritance - fixed by Jeff & Frank
>>
>> - proxy_balancer apr_escape.h dependence on APR 1.5
>>   * Fixed by Joe to allow APR 1.4 legacy linkage
>>
>> - lbmethod linkage
>>   * Fatal on Win32, load ordering issue on some linux configs
>>   * Patch does not appear yet on 2.4.x branch?
>>
>>
>> commit URLs please
>>
>
> You didn't seriously expect me to rise to that bait? No, I wasn't planning
> to bring you a rock, especially if you planted one or more fix backports
> yourself. We have access to the same lists, trackers and svn history.
>
> This is a query I'm especially fond of, although not all are categorized
> to land here...
>
>
> https://bz.apache.org/bugzilla/buglist.cgi=version_id=172637=equals=Importance=Apache%20httpd-2_format=advanced=2.4.34
>

Sorry, bad link. Try...

https://bz.apache.org/bugzilla/buglist.cgi?f1=version_id=172637=equals=Importance=Apache%20httpd-2_format=advanced=2.4.34

Re: Specific regressions to promptly address for 2.4.35?

[William A Rowe Jr]

On Tue, Aug 7, 2018, 10:55 Jim Jagielski  wrote:

>
>
> On Aug 7, 2018, at 11:21 AM, William A Rowe Jr 
> wrote:
>
>
> Specific regressions as requested by Jim, posted on users@ and dev@
> which are showstoppers to upgrading for some;
>
> - Non-HTTP responses from mod_ratelimit with delayed content (cgi, proxy)
>   * Breaking regression for module users (from sporadic to consistent)
>   * Fixed by elukey and ylavic
>
> - SSLOCSP directives breakage
>   * Broke some configs due to inheritance - fixed by Jeff & Frank
>
> - proxy_balancer apr_escape.h dependence on APR 1.5
>   * Fixed by Joe to allow APR 1.4 legacy linkage
>
> - lbmethod linkage
>   * Fatal on Win32, load ordering issue on some linux configs
>   * Patch does not appear yet on 2.4.x branch?
>
>
> commit URLs please
>

You didn't seriously expect me to rise to that bait? No, I wasn't planning
to bring you a rock, especially if you planted one or more fix backports
yourself. We have access to the same lists, trackers and svn history.

This is a query I'm especially fond of, although not all are categorized to
land here...

https://bz.apache.org/bugzilla/buglist.cgi=version_id=172637=equals=Importance=Apache%20httpd-2_format=advanced=2.4.34

It would be very helpful if everyone observing regressions ensured they
land in such a query.

Specific regressions to promptly address for 2.4.35?

[William A Rowe Jr]

On Mon, Aug 6, 2018 at 6:38 PM, Noel Butler  wrote:

> On 07/08/2018 03:37, William A Rowe Jr wrote:
>
> It appears 2.4.34 is unusable, as other distributors also paused to start
> hauling in regression fixes as they
>
> eh? unusable?  I have rooms full of them with no errors or problems
>
Unusable is an exaggeration; my point is this was a good beta, but not GA.
As with most breakage, the variety of deployments and configurations of
httpd make it impossible for us to ensure it will meet all users needs
during
the release voting.

Specific regressions as requested by Jim, posted on users@ and dev@
which are showstoppers to upgrading for some;

- Non-HTTP responses from mod_ratelimit with delayed content (cgi, proxy)
  * Breaking regression for module users (from sporadic to consistent)
  * Fixed by elukey and ylavic

- SSLOCSP directives breakage
  * Broke some configs due to inheritance - fixed by Jeff & Frank

- proxy_balancer apr_escape.h dependence on APR 1.5
  * Fixed by Joe to allow APR 1.4 legacy linkage

- lbmethod linkage
  * Fatal on Win32, load ordering issue on some linux configs
  * Patch does not appear yet on 2.4.x branch?

Open call; any other regressions people are concerned with that should
be addressed before 2.4.35 tag?

Re: Wherefor 2.4.36?

[William A Rowe Jr]

On Mon, Aug 6, 2018 at 12:37 PM, William A Rowe Jr 
wrote:

> Is anyone else disappointed in the number of regressions in 2.4.35?
>
> Is anyone else interested in releasing 2.4.36 promptly with no new
> features or enhancements which may cause 2.4.36 to be similarly unusable?
> Which backports or reversions of new code are still needed to get to that
> point?
>
>
s/2.4.36/2.4.35/; s/2.4.35/2.4.34/;

Sorry, I jumped over 2.4.34 so quickly after the chunking regression that
my numbering is already out of whack.

Wherefor 2.4.36?

[William A Rowe Jr]

Is anyone else disappointed in the number of regressions in 2.4.35?

Is anyone else interested in releasing 2.4.36 promptly with no new features
or enhancements which may cause 2.4.36 to be similarly unusable? Which
backports or reversions of new code are still needed to get to that point?

It appears 2.4.35 is unusable, as other distributors also paused to start
hauling in regression fixes as they become clear, to make some sort of
usable 2.4.35.1 private label source and binary packages, each one
different than another. There is no corresponding source release from the
ASF; that's a problem. And if it continues, that's a board level problem.

If distributors continue to ship a usable 2.4.x to end users, while the ASF
does not, we fail in our mission of delivering open *source* to our
community at no charge, and our claim that the current release of 2.4.x is
the best available version.

Suggestions such as below are what I'm suggesting be frozen out of the
release branch in the short term, until we have one GA-quality point
release for users to consume.



On Wed, Aug 1, 2018 at 7:54 AM,  wrote:

> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> STATUS?rev=1837233=1837232=1837233=diff
> 
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Wed Aug  1 12:54:54 2018
> @@ -186,6 +186,17 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>2.4.x patch: http://home.apache.org/~jim/patches/client64.patch
>+1: jim,
>
> +   *) Add in mod_socache_redis from trunk
> +  trunk: http://svn.apache.org/r1768070
> + http://svn.apache.org/r1768120
> + http://svn.apache.org/r1768225
> + http://svn.apache.org/r1769712
> + http://svn.apache.org/r1769737
> + http://svn.apache.org/r1774610
> + http://svn.apache.org/r1828624
> +  2.4.x patch: http://home.apache.org/~jim/
> patches/socache_redis.patch
> +  +1: jim,
> +
>  PATCHES/ISSUES THAT ARE BEING WORKED
>[ New entries should be added at the START of the list ]
>
>
>
>

Re: Bug in mod_ratelimit?

[William A Rowe Jr]

I'd concur that this suggested change is lighter weight and less fragile.


On Fri, Jul 27, 2018, 12:56 Cory McIntire  wrote:

> Hi Luca,
>
> Sorry for the delay in response.. we did look into it further..
>
> On of our devs had been looking into it and came up with the following:
>
> {quote}
> While it will probably resolve the issues we saw, I’d be hesitant to move
> forward with that patch as it modifies how all output filters work with
> HEAD requests,
> this is too large a change, especially when the bug(s) being addressesed
> are in a single module.
>
> I’d recommend making mod_ratelimit do the same “optimization” hack that
> other modules for HEAD requests instead, and keep the surface area for this
> bug fix isolated to mod_ratelimit only.
>
> Something like what mod_brotli does:
>
>  if (r->header_only && r->bytes_sent) {
>  ap_remove_output_filter(f);
>  return ap_pass_brigade(f->next, bb);
>  }
>  {quote}
>
> If there are any further adjustments to this patch we’d be happy to take a
> look, just let us know.
>
> Thanks,
> Cory McIntire
> Release Manager - EasyApache
> cPanel, Inc.
>
>
> > On Jul 27, 2018, at 10:46 AM, Luca Toscano 
> wrote:
> >
> > Hi Cory,
> >
> > 2018-07-20 13:47 GMT+02:00 Yann Ylavic :
> >> Hi Cory,
> >>
> >> On Thu, Jul 19, 2018 at 11:23 PM, Cory McIntire 
> wrote:
> >>>
> >>> We’re going to revert to the 2.4.33 version of mod_ratelimit for now.
> >>>
> >>> HEAD requests with large amount of headers were still problematic in
> our testing with both versions of the patch applied.
> >>
> >> Thanks for letting us know.
> >>
> >> I think the right fix is the attached patch (tested with GET/HEAD with
> >> large header and/or body, seems to work).
> >> If by any chance you can give it a try...
> >
> > In the meantime, other people are testing Yann's last patch in
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=62568 (it is attached
> > in there). If you could chime in whenever you have time and let us
> > know your thoughts it would be really great.
> >
> > Thanks in advance!
> >
> > Luca
>
>
>
>

Re: Current trunk win build error

[William A Rowe Jr]

+1, looks great.

On Tue, Jul 24, 2018 at 1:34 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@vodafone.com> wrote:

> Unfortunately this did not work and caused.
>
>
>
> In file included from mod_proxy.h:30:0,
>
>  from proxy_util.c:18:
>
> proxy_util.c: In function 'proxy_util_register_hooks':
>
> /home/pluem/apache/httpd-trunk/srclib/apr/include/apr_optional.h:42:36:
> error: unknown type name 'apr_OFN_proxy_balancer_get_best_worker_t'
>
> #define APR_OPTIONAL_FN_TYPE(name) apr_OFN_##name##_t
>
> ^
>
> /home/pluem/apache/httpd-trunk/srclib/apr/include/apr_optional.h:71:3:
> note: in expansion of macro 'APR_OPTIONAL_FN_TYPE'
>
>APR_OPTIONAL_FN_TYPE(name) *apu__opt = name; \
>
>^
>
> proxy_util.c:4094:5: note: in expansion of macro 'APR_REGISTER_OPTIONAL_FN'
>
>  APR_REGISTER_OPTIONAL_FN(proxy_balancer_get_best_worker);
>
>  ^
>
> proxy_util.c:4094:30: warning: initialization from incompatible pointer
> type [enabled by default]
>
>  APR_REGISTER_OPTIONAL_FN(proxy_balancer_get_best_worker);
>
>   ^
>
> /home/pluem/apache/httpd-trunk/srclib/apr/include/apr_optional.h:71:42:
> note: in definition of macro 'APR_REGISTER_OPTIONAL_FN'
>
>APR_OPTIONAL_FN_TYPE(name) *apu__opt = name; \
>
>   ^
>
> make[4]: *** [proxy_util.slo] Error 1
>
> make[3]: *** [shared-build-recursive] Error 1
>
> make[2]: *** [shared-build-recursive] Error 1
>
> make[1]: *** [shared-build-recursive] Error 1
>
> make: *** [all-recursive] Error 1
>
>
>
> The attached one which is shorter then my original one, but longer than
> yours and does work.
>
>
>
>
>
>
>
> Regards
>
>
>
> Rüdiger
>
>
>
> *Von:* William A Rowe Jr 
> *Gesendet:* Montag, 23. Juli 2018 16:54
>
> *An:* httpd 
> *Betreff:* Re: Current trunk win build error
>
>
>
> I think it's simply the attached (couldn't apply the inline text patch).
>
>
>
> No need to change the hook name.
>
>
>
> On Mon, Jul 23, 2018 at 9:16 AM, Plüm, Rüdiger, Vodafone Group <
> ruediger.pl...@vodafone.com> wrote:
>
> So something like the below?
>
>
>
> Regards
>
>
>
> Rüdiger
>
>
>
> Index: modules/proxy/balancers/mod_lbmethod_bybusyness.c
>
> ===
>
> --- modules/proxy/balancers/mod_lbmethod_bybusyness.c   (revision
> 1836460)
>
> +++ modules/proxy/balancers/mod_lbmethod_bybusyness.c(working copy)
>
> @@ -22,8 +22,8 @@
>
>  module AP_MODULE_DECLARE_DATA lbmethod_bybusyness_module;
>
> -static APR_OPTIONAL_FN_TYPE(ap_proxy_balancer_get_best_worker)
>
> -*ap_proxy_balancer_get_best_worker_fn = NULL;
>
> +static APR_OPTIONAL_FN_TYPE(proxy_balancer_get_best_worker)
>
> +*proxy_balancer_get_best_worker_fn = NULL;
>
>  static int is_best_bybusyness(proxy_worker *current, proxy_worker
> *prev_best, void *baton)
>
> {
>
> @@ -47,7 +47,7 @@
>
> {
>
>  int total_factor = 0;
>
>  proxy_worker *worker =
>
> -ap_proxy_balancer_get_best_worker_fn(balancer, r,
> is_best_bybusyness,
>
> +proxy_balancer_get_best_worker_fn(balancer, r,
> is_best_bybusyness,
>
>_factor);
>
>  if (worker) {
>
> @@ -96,9 +96,9 @@
>
>  return OK;
>
>  }
>
> -ap_proxy_balancer_get_best_worker_fn =
>
> - APR_RETRIEVE_OPTIONAL_FN(ap_proxy_balancer_get_best_
> worker);
>
> -if (!ap_proxy_balancer_get_best_worker_fn) {
>
> +proxy_balancer_get_best_worker_fn =
>
> + APR_RETRIEVE_OPTIONAL_FN(proxy_balancer_get_best_
> worker);
>
> +if (!proxy_balancer_get_best_worker_fn) {
>
>  ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(10151)
>
>   "mod_proxy must be loaded for
> mod_lbmethod_bybusyness");
>
>  return !OK;
>
> Index: modules/proxy/balancers/mod_lbmethod_byrequests.c
>
> ===
>
> --- modules/proxy/balancers/mod_lbmethod_byrequests.c(revision
> 1836460)
>
> +++ modules/proxy/balancers/mod_lbmethod_byrequests.c (working copy)
>
> @@ -22,8 +22,8 @@
>
>  module AP_MODULE_DECLARE_DATA lbmethod_byrequests_module;
>
> -static APR_OPTIONAL_FN_TYPE(ap_proxy_balancer_get_best_worker)
>
> -*ap_proxy_balancer_get_best_wo

Re: Current trunk win build error

[William A Rowe Jr]

 *proxy_balancer_get_best_worker_fn = NULL;
>
>  static int is_best_bytraffic(proxy_worker *current, proxy_worker
> *prev_best, void *baton)
>
> {
>
> @@ -62,7 +62,7 @@
>
> {
>
>  apr_off_t min_traffic = 0;
>
> -return ap_proxy_balancer_get_best_worker_fn(balancer, r,
> is_best_bytraffic,
>
> +return proxy_balancer_get_best_worker_fn(balancer, r,
> is_best_bytraffic,
>
>   _traffic);
>
> }
>
> @@ -107,9 +107,9 @@
>
>  return OK;
>
>  }
>
> -ap_proxy_balancer_get_best_worker_fn =
>
> - APR_RETRIEVE_OPTIONAL_FN(ap_proxy_balancer_get_best_
> worker);
>
> -if (!ap_proxy_balancer_get_best_worker_fn) {
>
> +proxy_balancer_get_best_worker_fn =
>
> + APR_RETRIEVE_OPTIONAL_FN(proxy_balancer_get_best_
> worker);
>
> +if (!proxy_balancer_get_best_worker_fn) {
>
>  ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(10150)
>
>   "mod_proxy must be loaded for
> mod_lbmethod_bytraffic");
>
>  return !OK;
>
> Index: modules/proxy/mod_proxy.h
>
> ===
>
> --- modules/proxy/mod_proxy.h (revision 1836460)
>
> +++ modules/proxy/mod_proxy.h   (working copy)
>
> @@ -883,7 +883,7 @@
>
> /*
>
>   * Needed by the lb modules.
>
>   */
>
> -APR_DECLARE_OPTIONAL_FN(proxy_worker *, ap_proxy_balancer_get_best_
> worker,
>
> +APR_DECLARE_OPTIONAL_FN(proxy_worker *, proxy_balancer_get_best_worker,
>
>  (proxy_balancer *balancer,
>
>   request_rec *r,
>
>   proxy_is_best_callback_fn_t
> *is_best,
>
> Index: modules/proxy/proxy_util.c
>
> ===
>
> --- modules/proxy/proxy_util.c (revision 1836460)
>
> +++ modules/proxy/proxy_util.c  (working copy)
>
> @@ -1415,6 +1415,13 @@
>
>  return best_worker;
>
> }
>
> +static proxy_worker* proxy_balancer_get_best_worker(proxy_balancer
> *balancer,
>
> +
>  request_rec *r,
>
> +
> proxy_is_best_callback_fn_t *is_best,
>
> +void
> *baton)
>
> +{
>
> +return ap_proxy_balancer_get_best_worker(balancer, r, is_best,
> baton);
>
> +}
>
> /*
>
>   * CONNECTION related...
>
>   */
>
> @@ -4079,5 +4086,5 @@
>
> {
>
>  APR_REGISTER_OPTIONAL_FN(ap_proxy_retry_worker);
>
>  APR_REGISTER_OPTIONAL_FN(ap_proxy_clear_connection);
>
> -APR_REGISTER_OPTIONAL_FN(ap_proxy_balancer_get_best_worker);
>
> +APR_REGISTER_OPTIONAL_FN(proxy_balancer_get_best_worker);
>
> }
>
>
>
> *Von:* William A Rowe Jr 
> *Gesendet:* Montag, 23. Juli 2018 16:04
> *An:* httpd 
> *Betreff:* Re: Current trunk win build error
>
>
>
> Perhaps use proxy_balancer_get_best_worker, and don't export
>
> that? That can be the delegate for ap_proxy_balancer_get_best_worker.
>
>
>
> We either keep callbacks local, or export them _NONSTD. All the
>
> *_DECLARE (without _NONSTD) are not usable as apr/httpd
>
> callbacks.
>
>
>
>
>
> On Mon, Jul 23, 2018 at 7:22 AM, Plüm, Rüdiger, Vodafone Group <
> ruediger.pl...@vodafone.com> wrote:
>
>
> > -Ursprüngliche Nachricht-
> > Von: Apache Lounge 
> > Gesendet: Montag, 23. Juli 2018 13:35
> > An: dev@httpd.apache.org
> > Betreff: Current trunk win build error
>
> >
> >
> >
> >
> >
> > Error C2440 'initializing': cannot convert from 'proxy_worker
> > *(__stdcall *)(proxy_balancer *,request_rec
> > *,proxy_is_best_callback_fn_t (__cdecl *),void *)' to
> > 'apr_OFN_ap_proxy_balancer_get_best_worker_t (__cdecl *)'
> >
> > mod_proxy c:\vc15\win32\httpd-trunk\modules\proxy\proxy_util.c 4082
> >
>
> Windows experts to the rescue please :-)
> Seems to be an issue between PROXY_DECLARE and the optional function stuff.
> Does the following patch fix it (just guessing)?
>
> Index: mod_proxy.h
> ===
> --- mod_proxy.h (revision 1836460)
> +++ mod_proxy.h (working copy)
> @@ -883,7 +883,7 @@
>  /*
>   * Needed by the lb modules.
>   */
> -APR_DECLARE_OPTIONAL_FN(proxy_worker *, ap_proxy_balancer_get_best_
> worker,
> +APR_DECLARE_OPTIONAL_FN(PROXY_DECLARE(proxy_worker *),
> ap_proxy_balancer_get_best_worker,
>  

Re: Current trunk win build error

[William A Rowe Jr]

Perhaps use proxy_balancer_get_best_worker, and don't export
that? That can be the delegate for ap_proxy_balancer_get_best_worker.

We either keep callbacks local, or export them _NONSTD. All the
*_DECLARE (without _NONSTD) are not usable as apr/httpd
callbacks.


On Mon, Jul 23, 2018 at 7:22 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@vodafone.com> wrote:

>
> > -Ursprüngliche Nachricht-
> > Von: Apache Lounge 
> > Gesendet: Montag, 23. Juli 2018 13:35
> > An: dev@httpd.apache.org
> > Betreff: Current trunk win build error
> >
> >
> >
> >
> >
> > Error C2440 'initializing': cannot convert from 'proxy_worker
> > *(__stdcall *)(proxy_balancer *,request_rec
> > *,proxy_is_best_callback_fn_t (__cdecl *),void *)' to
> > 'apr_OFN_ap_proxy_balancer_get_best_worker_t (__cdecl *)'
> >
> > mod_proxy c:\vc15\win32\httpd-trunk\modules\proxy\proxy_util.c 4082
> >
>
> Windows experts to the rescue please :-)
> Seems to be an issue between PROXY_DECLARE and the optional function stuff.
> Does the following patch fix it (just guessing)?
>
> Index: mod_proxy.h
> ===
> --- mod_proxy.h (revision 1836460)
> +++ mod_proxy.h (working copy)
> @@ -883,7 +883,7 @@
>  /*
>   * Needed by the lb modules.
>   */
> -APR_DECLARE_OPTIONAL_FN(proxy_worker *, ap_proxy_balancer_get_best_
> worker,
> +APR_DECLARE_OPTIONAL_FN(PROXY_DECLARE(proxy_worker *),
> ap_proxy_balancer_get_best_worker,
>  (proxy_balancer *balancer,
>   request_rec *r,
>   proxy_is_best_callback_fn_t
> *is_best,
>
>
>
> Regards
>
> Rüdiger
>

Re: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ modules/proxy/ modules/proxy/balancers/

[William A Rowe Jr]

On Fri, Jul 20, 2018, 15:22 Ruediger Pluem  wrote:

>
> BTW: We have the same load order issue issue with the following proxy
> modules:
>
> mod_proxy_connect
> mod_proxy_ftp
> mod_proxy_http
> mod_proxy_fcgi
> mod_proxy_scgi
> mod_proxy_fdpass
> mod_proxy_ajp
> mod_proxy_balancer
> mod_proxy_express
>

Correct. However this isn't a regression, and mod_proxy is an apparent
prerequisite to any of these, which further and thankfully sorts first. The
lbmethod providers differed in all three respects.

It might be interesting to solve in a future enhancement release, but the
number of dependencies likely makes this unrealistic.

Re: svn commit: r1832609 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/howto/ docs/manual/mod/ modules/proxy/ modules/proxy/balancers/

[William A Rowe Jr]

Looks like a good direction. From PR62557, the observed modules to be
adjusted, to consume the new opt fn are;

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -423,6 +424,9 @@ SET(mod_http2_extra_sources
   modules/http2/h2_task.cmodules/http2/h2_util.c
   modules/http2/h2_workers.c
 )
+SET(mod_lbmethod_bybusyness_extra_libs   mod_proxy)
+SET(mod_lbmethod_byrequests_extra_libs   mod_proxy)
+SET(mod_lbmethod_bytraffic_extra_libsmod_proxy)
 SET(mod_ldap_extra_defines   LDAP_DECLARE_EXPORT)
 SET(mod_ldap_extra_libs  wldap32)
 SET(mod_ldap_extra_sources


And this corresponds with


mod_lbmethod_bybusyness.c:
ap_proxy_balancer_get_best_worker(balancer, r, is_best_bybusyness,
mod_lbmethod_byrequests.c:proxy_worker *worker =
ap_proxy_balancer_get_best_worker(balancer, r, is_best_byrequests,
_factor);
mod_lbmethod_bytraffic.c:return
ap_proxy_balancer_get_best_worker(balancer, r, is_best_bytraffic,


This patch in 62557 can be ignored once the new optional entry point is
used instead, and these three modules may be loaded again prior to
mod_proxy in httpd.conf.



On Fri, Jul 20, 2018 at 5:13 AM, Ruediger Pluem  wrote:

>
>
> On 07/19/2018 08:24 PM, William A Rowe Jr wrote:
> > On Thu, May 31, 2018 at 8:24 AM, mailto:j...@apache.org>>
> wrote:
> >
> > Author: jim
> > Date: Thu May 31 13:24:04 2018
> > New Revision: 1832609
> >
> > URL: http://svn.apache.org/viewvc?rev=1832609=rev <
> http://svn.apache.org/viewvc?rev=1832609=rev>
> > Log:
> > Merge r1828890, r1832500 from trunk:
> >
> > [...]
> >
> > URL:
> > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> modules/proxy/balancers/mod_lbmethod_byrequests.c?rev=
> 1832609=1832608=1832609=diff
> > <http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> modules/proxy/balancers/mod_lbmethod_byrequests.c?rev=
> 1832609=1832608=1832609=diff>
> > 
> ==
> > --- 
> > httpd/httpd/branches/2.4.x/modules/proxy/balancers/mod_lbmethod_byrequests.c
> (original)
> > +++ 
> > httpd/httpd/branches/2.4.x/modules/proxy/balancers/mod_lbmethod_byrequests.c
> Thu May 31 13:24:04 2018
> >
> > [...]
> >
> > @@ -70,82 +77,17 @@ static int (*ap_proxy_retry_worker_fn)(c
> >   *   b a d c d a c d b d ...
> >   *
> >   */
> > -
> >  static proxy_worker *find_best_byrequests(proxy_balancer *balancer,
> >  request_rec *r)
> >  {
> > -int i;
> >  int total_factor = 0;
> >
> > [...]
> >
> > +proxy_worker *worker = ap_proxy_balancer_get_best_worker(balancer,
> r, is_best_byrequests, _factor);
> >
> >
> > This introduced a new hard runtime config ordering problem on
> mod_lbmethod_byrequest.so, which must now be loaded AFTER
> > mod_proxy.so.
> >
> > This was not previously true, as illustrated by mod_lbmethod_heartbeat,
> using the ap_proxy_retry_worker using an
> > optional function.
> >
> > lbmethod sorts before proxy, fwiw.
> >
>
> Something like the attached? The mod_lbmethod_byrequests.c part needs to
> be done for lb modules though.
>
> Regards
>
> Rüdiger
>
>
>
>

Re: Regression with CMake Windows builds, 2.4.29 is the last one passing

[William A Rowe Jr]

FWIW, the correct fix seems to be to fix the regression in
http://svn.apache.org/viewvc?rev=1832609=rev rather than the windows
build.

On Thu, Jul 19, 2018, 13:18 William A Rowe Jr  wrote:

> Hi Michal, thanks for your report.
>
> On Thu, Jul 19, 2018 at 10:36 AM, Michal Karm 
> wrote:
>
>> Hi guys,
>>
>> I would like to ask whether there are any plans on
>> accepting [1] patch to 2.4.x as it keeps failing the CMake Windows build.
>>
>> Furthermore, there is a regression [2] in 2.4.34 CMake Windows build that
>> did not
>> exist in 2.4.29.
>>
>> If anyone has a hit or an idea handy to get me unstuck I try to come up
>> with a
>> patch.
>>
>> Thank you for your time
>> K.
>>
>> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62190
>
>
> Suggestion adopted, as should have happened in the original backport. The
> changes are now merged complete from trunk.
>
>
>> [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=62557
>
>
> Proposed a solution for you. If this builds clean for you, I'll commit to
> trunk and 2.4.
>

Re: Regression with CMake Windows builds, 2.4.29 is the last one passing

[William A Rowe Jr]

Hi Michal, thanks for your report.

On Thu, Jul 19, 2018 at 10:36 AM, Michal Karm 
wrote:

> Hi guys,
>
> I would like to ask whether there are any plans on
> accepting [1] patch to 2.4.x as it keeps failing the CMake Windows build.
>
> Furthermore, there is a regression [2] in 2.4.34 CMake Windows build that
> did not
> exist in 2.4.29.
>
> If anyone has a hit or an idea handy to get me unstuck I try to come up
> with a
> patch.
>
> Thank you for your time
> K.
>
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62190


Suggestion adopted, as should have happened in the original backport. The
changes are now merged complete from trunk.


> [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=62557


Proposed a solution for you. If this builds clean for you, I'll commit to
trunk and 2.4.

Re: Apache2 mod_http2 segfault

[William A Rowe Jr]

This came up on another channel, but seems to be general interest;

On Thu, Jul 19, 2018 at 12:18 PM, William A Rowe Jr 
wrote:

>
> I'm at a loss to point to the canonical list of experimental components.
>

Is this it? Are there another authoritative list for 2.4.35-dev?

$ grep "Experimental" *.xml
core.xml:Experimental [ContentDigest directive]
mod_allowmethods.xml:Experimental [
mod_dialup.xml:Experimental
mod_echo.xml:Experimental
mod_example_hooks.xml:Experimental
mod_file_cache.xml:Experimental
mod_heartbeat.xml:Experimental
mod_heartmonitor.xml:Experimental
mod_lbmethod_heartbeat.xml:Experimental
mod_log_debug.xml:Experimental
mod_lua.xml:Experimental
mod_privileges.xml:Experimental
mod_sed.xml:Experimental
mod_session_crypto.xml:Experimental

Note that mod_allowmethods.xml tagged both the entire module and individual
directives, perhaps this is a pattern we want to follow to avoid confusion?
http://httpd.apache.org/docs/2.4/mod/mod_allowmethods.html

One last question; is it confusing if the authoritative docs page no longer
indicates that an installed older version was experimental? Since
http://httpd.apache.org/docs/2.4/ is an evolving document, can these pages
still be informative to users about their 2.4.16 install?

Re: openssl 1.1.1-pre8 hangs in t/ssl/varlookup.t

[William A Rowe Jr]

It might be worth comparing our trunk and 2.4.33 since we have had a lot of
discussion and some work around renegotiation behavior. Confirmation that
this is not new would be great.

On Tue, Jul 10, 2018, 14:26 Eric Covener  wrote:

> I tried testing the latest candidate w/ openssl 1.1.1-pre8 and noticed
> hangs in SSL_peek.  This is of course no issue with the 2.4.34
> candidate.
>
> Caveat: I also happen to be on AIX where the perl+openssl is very old.
>
> http://people.apache.org/~covener/renegotiate.log
>
> /* XXX: Should replace setting state with SSL_renegotiate(ssl);
>  * However, this causes failures in perl-framework currently,
>  * perhaps pre-test if we have already negotiated?
>  */
> /* Need to trigger renegotiation handshake by reading.
>  * Peeking 0 bytes actually works.
>  * See: http://marc.info/?t=14549335922=1=2
>  */
> SSL_peek(ssl, peekbuf, 0);
>
> 1.1.0 HEAD works fine, 1.1.1-pre8 blocks for appdata until reqtimeout
> gives up, it seems like the 0 byte numbytes is no longer working
>
> --
> Eric Covener
> cove...@gmail.com
>

Re: Time for 2.4.34?

[William A Rowe Jr]

I can get their efforts committed late this evening, if nobody beats me to
it. Expect to need a bit of crlf tweaking.

On Thu, Jul 5, 2018, 12:36 Marion et Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:

> +1, but latest zh-cn and zh-tw translation of error pages should be
> included IMHO.
>
> I've pushed for including what was already in trunk, but Codeingboy and
> popcorner have made improvements since the backport. (see docs@ ML)
>
> Not sure to have time tonight to push it on trunk and propose for backport.
> And, after tonight, I won't be able before monday evening.
>
> CJ
>
>
> Le 05/07/2018 à 17:43, Jim Jagielski a écrit :
> > Seems to me that we are just about due for a 2.4.34 release...
> > Anyone opposed? I volunteer to RM.
> >
>
>

Re: svn commit: r1834671 - in /httpd/httpd/branches/2.4.x: CHANGES docs/manual/mod/mod_md.xml modules/md/md_crypt.c modules/md/md_json.c modules/md/md_version.h modules/md/mod_md.c modules/md/mod_md_c

[William A Rowe Jr]

On Mon, Jul 2, 2018 at 8:25 AM, Stefan Eissing  wrote:

> I thought experimental == CTR, but if this is separate then I‘ll go
> through the votes. Just let me know what you prefer.


I basically thought the same thing, but it is clearly spelled out in STATUS.
We aught to adjust this to reflect the eventual consensus;

  * Current exceptions for RTC for this branch:
. mod_proxy_http2
. mod_lua
. documentation
. non-Unix build
. non-Unix, single-platform code