Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

[Joe Orton]

On Thu, Apr 18, 2024 at 09:40:21AM +0100, Graham Leggett via dev wrote:
> Hi all,
> 
> The attached patch is a current work in progress patch for httpd-trunk to use 
> the new apr_ldap API that just landing in APR.
> 
> The highlights:
> 
> - Complete replacement of the previous API.
> - Will work against apr-2 (just landed) and apr-util-1.7 (after backport).
> - Linking to the underlying LDAP API has been removed and is no longer needed.

This design decision seems surprising to me, what does this add? Adding 
another abstraction layer to allow runtime selection of the LDAP library 
seems like a step backwards (a lot of complexity with no benefit). 
Unlike with e.g. a database backend selection users don't care about 
picking/configuring among many LDAP libraries.

Regards, Joe

mod_cgi/cgid unification for 2.4.x

[Joe Orton]

I proposed the monster mod_cgi/cgid unification backport for 2.4.x, but 
wanted to give a bit more context here rather than in STATUS. PR is 
here: https://github.com/apache/httpd/pull/209

1) stderr handling is a significant regression in mod_cgid compared to 
mod_cgi so it is worth fixing this IMO (PR 54221)

2) we have shipped this patch in Fedora for a few years, so I am 
quite confident that the file descriptor passing feature works well *on 
Linux*. I have no idea how well it works on non-Linux platforms, hence 
keeping it opt-in (./configure --enable-cgid-fdpassing).

3) there should be no behaviour changes to mod_cgi or mod_cgid if the 
fdpassing feature is not enabled, except where bug fixes to either were 
missing and are provided by the unification of common code.

4) because the bulk of the patch is de-duplication, this is a net 
reduction in lines of code shipped despite the new fd-passing code. 
diffstat:

 .github/workflows/linux.yml |8 -
 changes-entries/pr54221.txt |3 
 modules/generators/cgi_common.h |  639 
+
 modules/generators/config5.m4   |   11 +
 modules/generators/mod_cgi.c|  586 

 modules/generators/mod_cgid.c   |  642 
+-
 6 files changed, 913 insertions(+), 976 deletions(-)

Since the github PR link is a series of patches, attached the complete 
patch here as well in case that's preferred for review.

Regards, Joe
diff --git a/.github/workflows/linux.yml b/.github/workflows/linux.yml
index ddacd4af19..6d4379d165 100644
--- a/.github/workflows/linux.yml
+++ b/.github/workflows/linux.yml
@@ -48,11 +48,11 @@ jobs:
   - name: Shared MPMs, all-modules
 config: --enable-mods-shared=reallyall --enable-mpms-shared=all
   # 
-
-  - name: Event MPM, all-modules, mod_cgid only
-config: --enable-mods-shared=reallyall --with-mpm=event 
--disable-cgi
+  - name: Event MPM, all-modules, mod_cgid fdpassing
+config: --enable-mods-shared=reallyall --with-mpm=event 
--disable-cgi --enable-cgid-fdpassing
   # 
-
-  - name: Event MPM, all-modules, no CMSG_DATA
-config: --enable-mods-shared=reallyall --with-mpm=event 
ac_cv_have_decl_CMSG_DATA=no
+  - name: Event MPM, all-modules, mod_cgid w/o fdpassing
+config: --enable-mods-shared=reallyall --with-mpm=event 
--disable-cgi
   # 
-
   - name: Default, all-modules + install
 config: --enable-mods-shared=reallyall
diff --git a/changes-entries/pr54221.txt b/changes-entries/pr54221.txt
new file mode 100644
index 00..62b75ea4dd
--- /dev/null
+++ b/changes-entries/pr54221.txt
@@ -0,0 +1,3 @@
+  *) mod_cgid: Optional support for file descriptor passing, fixing
+ error log handling (configure --enable-cgid-fdpassing) on Unix
+ platforms. PR 54221.  [Joe Orton]
diff --git a/modules/generators/cgi_common.h b/modules/generators/cgi_common.h
new file mode 100644
index 00..66f9418f21
--- /dev/null
+++ b/modules/generators/cgi_common.h
@@ -0,0 +1,639 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "apr.h"
+#include "apr_strings.h"
+#include "apr_buckets.h"
+#include "apr_lib.h"
+#include "apr_poll.h"
+
+#define APR_WANT_STRFUNC
+#define APR_WANT_MEMFUNC
+#include "apr_want.h"
+
+#include "httpd.h"
+#include "util_filter.h"
+#include "util_script.h"
+
+static APR_OPTIONAL_FN_TYPE(ap_ssi_get_tag_and_value) *cgi_pfn_gtv;
+static APR_OPTIONAL_FN_TYPE(ap_ssi_parse_string) *cgi_pfn_ps;
+
+/* These functions provided by mod_cgi.c/mod_cgid.c still. */
+static int l

Re: mod_systemd: refactor to get rid of libsystemd dependency?

[Joe Orton]

On Tue, Apr 02, 2024 at 12:25:40PM +0200, Rainer Jung wrote:
> Hi there,
> 
> in the light of the recent xz attack I was wondering, whether we should also
> reduce our library dependencies by no longer using sd_notify() in
> mod_systemd (thus loading libsystemd and all of its dependencies), but
> instead taking the approach to hard code sd_notify functionality.
> 
> I guess the Linux distributors who patched sshd to use libsystemd for
> notification are on their way to do the same for their sshd patches, so we
> might soon get an idea how to do that properly.
> 
> This is not meant to become part of out next release (this week), but
> hopefully we can manage to code it for the next one.
> 
> WDYT: does this make sense?

The trunk mod_systemd has got slightly wider library use than just 
sd_notify - so it is not quite that simple. If there was an alternative 
minimal library implementing the sd_* API parts required, that would 
definitely make sense. I'm not sure that reimplementing them all from 
scratch makes sense (especially multiplied by N projects doing this).

It looks like systemd folks have also changed the library implementation 
to dlopen() the various dependant libraries on demand now rather than 
directly linking to them, which removes the specific attack vector used 
here IIUC.

Regards, Joe

Re: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59

[Joe Orton]

On Wed, Apr 03, 2024 at 08:26:09AM -0400, Eric Covener wrote:
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a SHORTENED VOTE to release
> this candidate tarball httpd-2.4.59-rc1 as 2.4.59:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.

+1 from me. Passes test suite on RHEL8+9+CentOS Stream 10. Big thanks for 
RMing.

Also a CI pass: https://github.com/apache/httpd/actions/runs/8538499329

Regards, Joe

Re: Failing test t/apache/pr64339.t

[Joe Orton]

On Tue, Apr 02, 2024 at 08:46:46PM -0400, Eric Covener wrote:
> This could be due to none of these happening:
> - mod_mime didn't send a charset from backend
> - no BOM
> - no xml2EncDefault (8859-1 effectively by default) on frontend
> 
> To make the conf match the test code, this works for me to address
> mod_mime on the backend:

Yup. Sorry for wasting your time on this. Thanks for the commit, I had 
the same change uncommitted locally still and missed it.

Re: svn commit: r1915947 - /httpd/httpd/branches/2.4.x/STATUS

[Joe Orton]

On Tue, Mar 05, 2024 at 11:25:12AM +0100, jean-frederic clere wrote:
> On 2/29/24 10:54, Joe Orton wrote:
> > On Thu, Feb 22, 2024 at 01:35:06PM -, jfcl...@apache.org wrote:
> > > Author: jfclere
> > > Date: Thu Feb 22 13:35:06 2024
> > > New Revision: 1915947
> > > 
> > > URL: http://svn.apache.org/viewvc?rev=1915947=rev
> > > Log:
> > > Propose. CMake builds fail withi: "fatal error C1083: Cannot open include 
> > > file: 'ap_config_auto.h'"
> > 
> > FYI the r1877693 fix is included in my other backport proposal for
> > htpasswd.
> 
> I have removed my proposal, tested, checked and votes yours. Thanks!

Thanks - now merged.

Regards, Joe

Re: svn commit: r1916068 - in /httpd/httpd/trunk: .github/workflows/linux.yml test/travis_before_linux.sh

[Joe Orton]

On Fri, Mar 01, 2024 at 01:52:15PM +0100, Yann Ylavic wrote:
> On Fri, Mar 1, 2024 at 1:42 PM Yann Ylavic  wrote:
> >
> > On Fri, Mar 1, 2024 at 1:24 PM Joe Orton  wrote:
> > >
> > > Do you still want that
> > > TestSSLCA.pm change merged?
> >
> > I think it can be useful for those who test httpd with openssl1 still
> > (not maintained anymore, but we have to keep compatibility in 2.4 at
> > least).
> 
> But the issue with this patch is that it doesn't check which openssl
> version httpd is actually using, so it always generates pkcs#1 keys
> even if not needed.
> If we had a way to check the system's openssl AND httpd's openssl are
> < 3 it would be better, but I don't see how to do this.

I suppose we could export the detected version from configure via apxs 
-q and pick it up in Apache::Test, but I think it would be likely to 
make the whole house of cards even more fragile. So I'm not sure it's 
worth investing effort in that tbh. Better to assume/require that the 
bin/openssl version matches the version mod_ssl uses.

Regards, Joe

Re: svn commit: r1916068 - in /httpd/httpd/trunk: .github/workflows/linux.yml test/travis_before_linux.sh

[Joe Orton]

On Fri, Mar 01, 2024 at 12:59:10PM +0100, Yann Ylavic wrote:
> On Fri, Mar 1, 2024 at 11:15 AM  wrote:
> >
> > Author: jorton
> > Date: Fri Mar  1 10:15:13 2024
> > New Revision: 1916068
> >
> > URL: http://svn.apache.org/viewvc?rev=1916068=rev
> > Log:
> > CI: add OpenSSL 3.2, test OpenSSL 3.x using Apache::Test
> > trunk to pick up r1916067.
> 
> I had to modify Apache-Test too when running the perl test framework
> with openssl >= 3.0 and proposed a patch here [1] (not enough karma to
> commit on perl.a.o).
> It was an issue with mod_proxy's client certs IIRC, which r1916067 is
> possibly fixing too, but just in case you are still fighting with this
> ;)

Ah, interesting, thanks. I should read dev@perl more often!

I haven't seen that particularly failure, and trunk seems to now be 
working (touch wood) with 3.1 and 3.2. The Ubuntu runners are all on 
OpenSSL 3.0 anyway, and r1916058 ensures that TestSSLCA.pm is using the 
bin/openssl from the installed version of OpenSSL rather than a 
possibly-mismatched system /usr/bin/openssl. Do you still want that 
TestSSLCA.pm change merged?

Also - I guess the note about *not* accepting PKCS#8 format keys in 
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxymachinecertificatefile
 
is now wrong then?

Regards, Joe

Re: svn commit: r1915947 - /httpd/httpd/branches/2.4.x/STATUS

[Joe Orton]

On Thu, Feb 22, 2024 at 01:35:06PM -, jfcl...@apache.org wrote:
> Author: jfclere
> Date: Thu Feb 22 13:35:06 2024
> New Revision: 1915947
> 
> URL: http://svn.apache.org/viewvc?rev=1915947=rev
> Log:
> Propose. CMake builds fail withi: "fatal error C1083: Cannot open include 
> file: 'ap_config_auto.h'"

FYI the r1877693 fix is included in my other backport proposal for 
htpasswd.

> Modified:
> httpd/httpd/branches/2.4.x/STATUS
> 
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1915947=1915946=1915947=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Thu Feb 22 13:35:06 2024
> @@ -243,6 +243,12 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>Github PR: https://github.com/apache/httpd/pull/413
>+1: ylavic, jorton, jfclere
>  
> +   *) htpasswd: Windows : do not include ap_config_auto.h 
> +  trunk patch: https://svn.apache.org/r1877693 
> +  2.4.x patch: svn merge -c 1877693 ^/httpd/httpd/trunk .
> +  +1: jfclere,
> +  
> +
>  PATCHES/ISSUES THAT ARE BEING WORKED
>[ New entries should be added at the START of the list ]
>  
> 
> 

Re: svn commit: r1915740 - in /httpd/httpd/branches/2.4.x: ./ changes-entries/pr61574.txt modules/ssl/ssl_engine_init.c

[Joe Orton]

On Fri, Feb 16, 2024 at 09:52:04PM +0100, Christophe JAILLET wrote:
> Le 12/02/2024 à 09:37, jor...@apache.org a écrit :
> > Author: jorton
> > Date: Mon Feb 12 08:37:35 2024
> > New Revision: 1915740
> > 
> > URL: http://svn.apache.org/viewvc?rev=1915740=rev
> > Log:
...
> r1825124 was a follow-up of this patch.
> Should it be backported as well?

Good catch, thank you. Proposed now.

Regards, Joe

Re: libapreq subproject roll call

[Joe Orton]

On Fri, Feb 16, 2024 at 08:10:57AM -0500, Eric Covener wrote:
> I count myself as a release vote of last resort only, but i don't
> think we should be committing to future fixes/releases if nearly
> everyone is in this category.

Thanks for raising it here, Eric. Same for me.

Regards, Joe

Re: release apreq 2.18 and mothball the project

[Joe Orton]

Joe, you've been warned before to moderate your language. This ends now.

It is completely unacceptable to insult other members of the community 
like this one time, let alone repeatedly. It is unproductive, 
unprofessional, and in violation of the ASF code of conduct. I've taken 
the decision as PMC chair to remove you from dev@ and you are now banned 
from posting in the future.

- Project Chair of HTTP Server, Joe Orton

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

The mediocre talent pool in this community doesn’t mind the code
duplication of having many different form data parsers inside a common code
base because, really, collaboration and common cause is not your thing.

So live it up with the user base while they ponder your architectural
rationales like this guy does:

https://stackoverflow.com/questions/60281807/get-post-request-body-and-decode-using-mod-lua-apache-http-2-4



Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 8:47 PM Joe Schaefer  wrote:

> Stupid shit like this is everyone's problem:
>
> https://www.tenable.com/plugins/nessus/161454
>
> Hating me for solving it cleanly is par for the course for the current
> httpd committer community.
>
> On Thu, Feb 15, 2024 at 8:41 PM Joe Schaefer  wrote:
>
>> Back in the day, httpd was a celebrated integration point for dozens of
>> apache projects. Literally the flagship of the organization.
>>
>> It's also why people were judicious about what to include in core, versus
>> codebases remaining elsewhere in the org as third party modules.
>>
>> Of course at this point, there's no good reason to hook a dynamic
>> language into core in a non-thread-safe way.  Yet mod_lua exists.
>> If there's no good reason to hook a thread-safe httpd-specific HTML form
>> parser technology into the mix, what is mod_dav doing in here?
>>
>> The obvious answer is because peevishness rules the day at Apache.  Very
>> Important People's pet projects have staying power, not because users
>> demand it, but because the personalities behind them would give you serious
>> shit for discarding the module on a whim.
>>
>> All I ask for is to be able to bow out and never return to this group
>> again.
>>
>>
>>
>> On Thu, Feb 15, 2024 at 8:20 PM Joe Schaefer  wrote:
>>
>>> The proof is in the pudding, as it were.
>>>
>>> There's prima facia evidence in this very thread that he lied about ever
>>> running the test suite for apreq, because Joe wouldn't have had to patch it
>>> for him 8 months later had he ever bothered in the first place.
>>>
>>> But when everyone around you is no better than that, there's
>>> participation trophies for all of you!
>>>
>>> On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:
>>>
>>>> > And because you are such a prima donna Yann
>>>>
>>>> Yann is an amazing programmer and super easy to work with. Maybe it's
>>>> hard to tell from the backseat.
>>>>
>>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Stupid shit like this is everyone's problem:

https://www.tenable.com/plugins/nessus/161454

Hating me for solving it cleanly is par for the course for the current
httpd committer community.

On Thu, Feb 15, 2024 at 8:41 PM Joe Schaefer  wrote:

> Back in the day, httpd was a celebrated integration point for dozens of
> apache projects. Literally the flagship of the organization.
>
> It's also why people were judicious about what to include in core, versus
> codebases remaining elsewhere in the org as third party modules.
>
> Of course at this point, there's no good reason to hook a dynamic language
> into core in a non-thread-safe way.  Yet mod_lua exists.
> If there's no good reason to hook a thread-safe httpd-specific HTML form
> parser technology into the mix, what is mod_dav doing in here?
>
> The obvious answer is because peevishness rules the day at Apache.  Very
> Important People's pet projects have staying power, not because users
> demand it, but because the personalities behind them would give you serious
> shit for discarding the module on a whim.
>
> All I ask for is to be able to bow out and never return to this group
> again.
>
>
>
> On Thu, Feb 15, 2024 at 8:20 PM Joe Schaefer  wrote:
>
>> The proof is in the pudding, as it were.
>>
>> There's prima facia evidence in this very thread that he lied about ever
>> running the test suite for apreq, because Joe wouldn't have had to patch it
>> for him 8 months later had he ever bothered in the first place.
>>
>> But when everyone around you is no better than that, there's
>> participation trophies for all of you!
>>
>> On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:
>>
>>> > And because you are such a prima donna Yann
>>>
>>> Yann is an amazing programmer and super easy to work with. Maybe it's
>>> hard to tell from the backseat.
>>>
>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Back in the day, httpd was a celebrated integration point for dozens of
apache projects. Literally the flagship of the organization.

It's also why people were judicious about what to include in core, versus
codebases remaining elsewhere in the org as third party modules.

Of course at this point, there's no good reason to hook a dynamic language
into core in a non-thread-safe way.  Yet mod_lua exists.
If there's no good reason to hook a thread-safe httpd-specific HTML form
parser technology into the mix, what is mod_dav doing in here?

The obvious answer is because peevishness rules the day at Apache.  Very
Important People's pet projects have staying power, not because users
demand it, but because the personalities behind them would give you serious
shit for discarding the module on a whim.

All I ask for is to be able to bow out and never return to this group again.



On Thu, Feb 15, 2024 at 8:20 PM Joe Schaefer  wrote:

> The proof is in the pudding, as it were.
>
> There's prima facia evidence in this very thread that he lied about ever
> running the test suite for apreq, because Joe wouldn't have had to patch it
> for him 8 months later had he ever bothered in the first place.
>
> But when everyone around you is no better than that, there's participation
> trophies for all of you!
>
> On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:
>
>> > And because you are such a prima donna Yann
>>
>> Yann is an amazing programmer and super easy to work with. Maybe it's
>> hard to tell from the backseat.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

The proof is in the pudding, as it were.

There's prima facia evidence in this very thread that he lied about ever
running the test suite for apreq, because Joe wouldn't have had to patch it
for him 8 months later had he ever bothered in the first place.

But when everyone around you is no better than that, there's participation
trophies for all of you!

On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:

> > And because you are such a prima donna Yann
>
> Yann is an amazing programmer and super easy to work with. Maybe it's hard
> to tell from the backseat.
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

 The nightmare scenario is when you try to support HTTP/3 when you can’t
even support an HTML form parser.

Have an appropriate amount of fun. Popcorn is popping.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 7:36 PM Joe Schaefer  wrote:

> The reason the QA around httpd is so lousy lately is because none of you
> actually dogfood the software professionally, because no Fortune 500
> employer would be caught dead running httpd over nginx in the cloud.
>
> That historically lackadaisical approach to CI has no business persisting
> now that you are on GitHub.
>
> And yet it persists.
>
> It also is why you guinea pig your user base instead of respecting them,
> because you aren’t a part of that community any more.
>
> And it shows with each new dud delivered to the apreq user base over the
> past decade.
>
> So let’s end this fiasco ASAP.
>
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 7:08 PM Joe Schaefer  wrote:
>
>> Keep your tone policing off list wise guy. If you have something of
>> substance to offer to your colleagues other than defensive posturing, let’s
>> have it.
>>
>> Like all these vacuous bug reports missing from the issue tracker about
>> apreq, that you rumor mongers like to scare people with.
>>
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>>
>>
>> On Thu, Feb 15, 2024 at 7:03 PM Frank Gingras  wrote:
>>
>>>
>>>
>>> On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:
>>>
>>>> Nobody gives a flying f what you released from trunk. I personally will
>>>> be dead and buried before you release httpd 3.0.  So like you I don’t give
>>>> a damned what you do with it.
>>>>
>>>> I just want the warfare against existing libapreq2 users to cease and
>>>> desist.
>>>>
>>>> If there are known vulnerabilities in the existing codebase, you have a
>>>> professional obligation to report them to the security team, who have
>>>> assured me they will send them my way for proper handling by a competent
>>>> engineer.
>>>>
>>>> None have been forthcoming, so that’s reason to release 2.18 as-is and
>>>> mothball the subproject so we need not deal with each other again over it.
>>>>
>>>> Thanks
>>>>
>>>> Joe Schaefer, Ph.D.
>>>> <https://sunstarsys.com/orion/features>
>>>> Orion - The Enterprise Jamstack Wiki
>>>> <https://sunstarsys.com/orion/features>
>>>> 
>>>> 954.253.3732 
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:
>>>>
>>>>> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer 
>>>>> wrote:
>>>>>
>>>>>> Twenty years in core, with one bug to fix.
>>>>>> And you couldn’t even manage without three different botched releases.
>>>>>>
>>>>>
>>>>> I think you are mixing up apreq and httpd releases here.
>>>>> AIUI the apreq stuff in the core of httpd-trunk has only ever been in
>>>>> one alpha release, and predates the regression.
>>>>>
>>>>> I'll keep any advice about an apreq release to myself, good luck and
>>>>> please be mindful of the CoC
>>>>> https://www.apache.org/foundation/policies/conduct
>>>>>
>>>>>
>>> Respectfully, the tone of that response was unwarranted. There are
>>> better ways to express your opinion that don't require attacks, and
>>> cynicism.
>>>
>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

The reason the QA around httpd is so lousy lately is because none of you
actually dogfood the software professionally, because no Fortune 500
employer would be caught dead running httpd over nginx in the cloud.

That historically lackadaisical approach to CI has no business persisting
now that you are on GitHub.

And yet it persists.

It also is why you guinea pig your user base instead of respecting them,
because you aren’t a part of that community any more.

And it shows with each new dud delivered to the apreq user base over the
past decade.

So let’s end this fiasco ASAP.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 7:08 PM Joe Schaefer  wrote:

> Keep your tone policing off list wise guy. If you have something of
> substance to offer to your colleagues other than defensive posturing, let’s
> have it.
>
> Like all these vacuous bug reports missing from the issue tracker about
> apreq, that you rumor mongers like to scare people with.
>
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 7:03 PM Frank Gingras  wrote:
>
>>
>>
>> On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:
>>
>>> Nobody gives a flying f what you released from trunk. I personally will
>>> be dead and buried before you release httpd 3.0.  So like you I don’t give
>>> a damned what you do with it.
>>>
>>> I just want the warfare against existing libapreq2 users to cease and
>>> desist.
>>>
>>> If there are known vulnerabilities in the existing codebase, you have a
>>> professional obligation to report them to the security team, who have
>>> assured me they will send them my way for proper handling by a competent
>>> engineer.
>>>
>>> None have been forthcoming, so that’s reason to release 2.18 as-is and
>>> mothball the subproject so we need not deal with each other again over it.
>>>
>>> Thanks
>>>
>>> Joe Schaefer, Ph.D.
>>> <https://sunstarsys.com/orion/features>
>>> Orion - The Enterprise Jamstack Wiki
>>> <https://sunstarsys.com/orion/features>
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>>
>>> On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:
>>>
>>>> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>> Twenty years in core, with one bug to fix.
>>>>> And you couldn’t even manage without three different botched releases.
>>>>>
>>>>
>>>> I think you are mixing up apreq and httpd releases here.
>>>> AIUI the apreq stuff in the core of httpd-trunk has only ever been in
>>>> one alpha release, and predates the regression.
>>>>
>>>> I'll keep any advice about an apreq release to myself, good luck and
>>>> please be mindful of the CoC
>>>> https://www.apache.org/foundation/policies/conduct
>>>>
>>>>
>> Respectfully, the tone of that response was unwarranted. There are better
>> ways to express your opinion that don't require attacks, and cynicism.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Keep your tone policing off list wise guy. If you have something of
substance to offer to your colleagues other than defensive posturing, let’s
have it.

Like all these vacuous bug reports missing from the issue tracker about
apreq, that you rumor mongers like to scare people with.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 7:03 PM Frank Gingras  wrote:

>
>
> On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:
>
>> Nobody gives a flying f what you released from trunk. I personally will
>> be dead and buried before you release httpd 3.0.  So like you I don’t give
>> a damned what you do with it.
>>
>> I just want the warfare against existing libapreq2 users to cease and
>> desist.
>>
>> If there are known vulnerabilities in the existing codebase, you have a
>> professional obligation to report them to the security team, who have
>> assured me they will send them my way for proper handling by a competent
>> engineer.
>>
>> None have been forthcoming, so that’s reason to release 2.18 as-is and
>> mothball the subproject so we need not deal with each other again over it.
>>
>> Thanks
>>
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>>
>>
>> On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:
>>
>>> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer 
>>> wrote:
>>>
>>>> Twenty years in core, with one bug to fix.
>>>> And you couldn’t even manage without three different botched releases.
>>>>
>>>
>>> I think you are mixing up apreq and httpd releases here.
>>> AIUI the apreq stuff in the core of httpd-trunk has only ever been in
>>> one alpha release, and predates the regression.
>>>
>>> I'll keep any advice about an apreq release to myself, good luck and
>>> please be mindful of the CoC
>>> https://www.apache.org/foundation/policies/conduct
>>>
>>>
> Respectfully, the tone of that response was unwarranted. There are better
> ways to express your opinion that don't require attacks, and cynicism.
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Nobody gives a flying f what you released from trunk. I personally will be
dead and buried before you release httpd 3.0.  So like you I don’t give a
damned what you do with it.

I just want the warfare against existing libapreq2 users to cease and
desist.

If there are known vulnerabilities in the existing codebase, you have a
professional obligation to report them to the security team, who have
assured me they will send them my way for proper handling by a competent
engineer.

None have been forthcoming, so that’s reason to release 2.18 as-is and
mothball the subproject so we need not deal with each other again over it.

Thanks

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:

> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer  wrote:
>
>> Twenty years in core, with one bug to fix.
>> And you couldn’t even manage without three different botched releases.
>>
>
> I think you are mixing up apreq and httpd releases here.
> AIUI the apreq stuff in the core of httpd-trunk has only ever been in one
> alpha release, and predates the regression.
>
> I'll keep any advice about an apreq release to myself, good luck and
> please be mindful of the CoC
> https://www.apache.org/foundation/policies/conduct
>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Let's be honest for once Yann. You came up with this hairbrained patch over
2 years ago right here:

https://svn.apache.org/viewvc?view=revision=1895107

Yet the first time anyone actually ran the unit tests for apreq was during
the 2.17 release process **8 months later**.  And because you are such a
prima donna Yann, Joe Orton (who I always respect) would rather remove the
test that flagged your patch, just so he could get the damned thing out the
door without dealing with you further.

Instead, he had to deal with me.   Tradeoffs are everywhere in life.


On Thu, Feb 15, 2024 at 2:41 PM Joe Schaefer  wrote:

> You mean the 2.17 release, where Joe Orton actually patched the test suite
> out of your coercion?
>
> Great engineering.
>
> http://svn.apache.org/viewvc?view=revision=1903489
>
>
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 2:13 PM Yann Ylavic  wrote:
>
>> On Thu, Feb 15, 2024 at 5:12 AM Joe Schaefer wrote:
>> >
>> > I gave you beta males an entire year
>>
>> His Alpha Most Serene Highness is too kind to us..
>>
>> > to find an excuse for completely boning the modperl user community for
>> no good reason,
>>
>> _You_ did that (boning the modperl user community), by spitting your
>> venom on everyone here (and in all the forums) and nothing else.
>> You, as a member of the httpd team, could have fixed it and
>> started/encouraged a new release with the one-liner fix, yet your
>> first/primary point was to insult others for having touched your
>> (alphally broken) code and introduced a (betally edge) regression,
>> which His Alpha Most Serene Highness' test suite didn't caught btw.
>>
>> > So far, the only thing to come of putting apreq inside httpd is that
>> third party quality control teams put some elbow grease into fuzzing its
>> various parsers and found a sore spot that you bland engineers felt put
>> upon to fix.  And so you botched that patch too, largely out of spite for
>> the makework.
>>
>> Actually it did find multiple sore spots, otherwise you can imagine
>> that we plebs would never have dared to touch as much of His Alpha
>> Most Serene Highness' code.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

You mean the 2.17 release, where Joe Orton actually patched the test suite
out of your coercion?

Great engineering.

http://svn.apache.org/viewvc?view=revision=1903489


Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Thu, Feb 15, 2024 at 2:13 PM Yann Ylavic  wrote:

> On Thu, Feb 15, 2024 at 5:12 AM Joe Schaefer wrote:
> >
> > I gave you beta males an entire year
>
> His Alpha Most Serene Highness is too kind to us..
>
> > to find an excuse for completely boning the modperl user community for
> no good reason,
>
> _You_ did that (boning the modperl user community), by spitting your
> venom on everyone here (and in all the forums) and nothing else.
> You, as a member of the httpd team, could have fixed it and
> started/encouraged a new release with the one-liner fix, yet your
> first/primary point was to insult others for having touched your
> (alphally broken) code and introduced a (betally edge) regression,
> which His Alpha Most Serene Highness' test suite didn't caught btw.
>
> > So far, the only thing to come of putting apreq inside httpd is that
> third party quality control teams put some elbow grease into fuzzing its
> various parsers and found a sore spot that you bland engineers felt put
> upon to fix.  And so you botched that patch too, largely out of spite for
> the makework.
>
> Actually it did find multiple sore spots, otherwise you can imagine
> that we plebs would never have dared to touch as much of His Alpha
> Most Serene Highness' code.
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Twenty years in core, with one bug to fix.
And you couldn’t even manage without three different botched releases.

Please, for the love of its users, stop fixing it.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Wed, Feb 14, 2024 at 11:12 PM Joe Schaefer  wrote:

> Look Eric,
>
> I gave you beta males an entire year to find an excuse for completely
> boning the modperl user community for no good reason, other than your
> precious egos were harmed while going though the motions for the past ten
> years with this project.
>
> So far, the only thing to come of putting apreq inside httpd is that third
> party quality control teams put some elbow grease into fuzzing its various
> parsers and found a sore spot that you bland engineers felt put upon to
> fix.  And so you botched that patch too, largely out of spite for the
> makework.
>
> There’s a reason the Dean Gaudet‘s of the development sector lost interest
> in hanging out with the weenie tot brigade people like Eric represent.
>
> It’s why I want out now too.
>
>
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>
>
> On Wed, Feb 14, 2024 at 10:33 PM Joe Schaefer  wrote:
>
>> Bite me Eric.
>>
>> Next?
>>
>>
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>>
>>
>> On Wed, Feb 14, 2024 at 10:25 PM Eric Covener  wrote:
>>
>>> On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer  wrote:
>>> >
>>> > Assuming Google hasn't found any more fuzzing vulnerabilities with
>>> apreq, we should call the subproject done after releasing it, rolling any
>>> new efforts into httpd's internal copy of the codebase for the next major
>>> release of httpd.
>>> >
>>> > Sound like a plan?  I can get the ball rolling on the RM process
>>> assuming I still have working login (or can reacquire it via pw reset.
>>>
>>> I think another apreq release makes sense.
>>>
>>> But from the few relevant threads over the years (many on private
>>> lists), there seems to be little maintainer support for apreq much
>>> less apreq embedded in httpd. If there ever were a release branched
>>> from trunk, I don't think it's likely the embedded apreq would
>>> survive.  I think it's a big consideration for what's done with the
>>> standalone tree.
>>>
>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Look Eric,

I gave you beta males an entire year to find an excuse for completely
boning the modperl user community for no good reason, other than your
precious egos were harmed while going though the motions for the past ten
years with this project.

So far, the only thing to come of putting apreq inside httpd is that third
party quality control teams put some elbow grease into fuzzing its various
parsers and found a sore spot that you bland engineers felt put upon to
fix.  And so you botched that patch too, largely out of spite for the
makework.

There’s a reason the Dean Gaudet‘s of the development sector lost interest
in hanging out with the weenie tot brigade people like Eric represent.

It’s why I want out now too.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Wed, Feb 14, 2024 at 10:33 PM Joe Schaefer  wrote:

> Bite me Eric.
>
> Next?
>
>
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>
>
> On Wed, Feb 14, 2024 at 10:25 PM Eric Covener  wrote:
>
>> On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer  wrote:
>> >
>> > Assuming Google hasn't found any more fuzzing vulnerabilities with
>> apreq, we should call the subproject done after releasing it, rolling any
>> new efforts into httpd's internal copy of the codebase for the next major
>> release of httpd.
>> >
>> > Sound like a plan?  I can get the ball rolling on the RM process
>> assuming I still have working login (or can reacquire it via pw reset.
>>
>> I think another apreq release makes sense.
>>
>> But from the few relevant threads over the years (many on private
>> lists), there seems to be little maintainer support for apreq much
>> less apreq embedded in httpd. If there ever were a release branched
>> from trunk, I don't think it's likely the embedded apreq would
>> survive.  I think it's a big consideration for what's done with the
>> standalone tree.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Bite me Eric.

Next?

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Wed, Feb 14, 2024 at 10:25 PM Eric Covener  wrote:

> On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer  wrote:
> >
> > Assuming Google hasn't found any more fuzzing vulnerabilities with
> apreq, we should call the subproject done after releasing it, rolling any
> new efforts into httpd's internal copy of the codebase for the next major
> release of httpd.
> >
> > Sound like a plan?  I can get the ball rolling on the RM process
> assuming I still have working login (or can reacquire it via pw reset.
>
> I think another apreq release makes sense.
>
> But from the few relevant threads over the years (many on private
> lists), there seems to be little maintainer support for apreq much
> less apreq embedded in httpd. If there ever were a release branched
> from trunk, I don't think it's likely the embedded apreq would
> survive.  I think it's a big consideration for what's done with the
> standalone tree.
>

release apreq 2.18 and mothball the project

[Joe Schaefer]

Assuming Google hasn't found any more fuzzing vulnerabilities with apreq,
we should call the subproject done after releasing it, rolling any new
efforts into httpd's internal copy of the codebase for the next major
release of httpd.

Sound like a plan?  I can get the ball rolling on the RM process assuming I
still have working login (or can reacquire it via pw reset.

-- 
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: using changes-entries or write in CHANGES directly

[Joe Orton]

On Wed, Feb 14, 2024 at 11:28:15AM +0100, jean-frederic clere wrote:
> So for 2.4.x on my accepted back port I have don't need changes-entries and
> I have to process CHANGES by hands as I missed creating a changes-entries
> file in trunk.

If you file a Github PR for the backport you can still add a 
changes-entries/ file there (same if you create a patch and upload it 
somewhere). It makes the change easy to merge independent of other 
commits, avoiding conflicts adding directly to CHANGES. Works really 
well (thanks Rűdiger!)

Regards, Joe

Re: svn commit: r1915534 - in /httpd/httpd/branches/2.4.x: ./ modules/cache/mod_socache_shmcb.c modules/proxy/balancers/mod_lbmethod_heartbeat.c os/unix/unixd.c server/buildmark.c server/scoreboard.c

[Joe Orton]

On Fri, Feb 02, 2024 at 03:29:34PM +0100, Ruediger Pluem wrote:
> > Modified: httpd/httpd/branches/2.4.x/server/util_expr_parse.c
> > URL: 
> > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/util_expr_parse.c?rev=1915534=1915533=1915534=diff
> > ==
> > --- httpd/httpd/branches/2.4.x/server/util_expr_parse.c (original)
> > +++ httpd/httpd/branches/2.4.x/server/util_expr_parse.c Fri Feb  2 11:50:07 
> > 2024
> > @@ -1326,6 +1326,8 @@ YYSTYPE yylval;
> >  
> >goto yysetstate;
> >  
> > +  /* TODO: comppiler warning that this is unused, and it seems to */
> 
> Typo :-) compiler

Thanks -> r1915543

Re: svn commit: r1915516 - in /httpd/httpd/branches/2.4.x: ./ CHANGES configure.in docs/man/htpasswd.1 support/htpasswd.c support/passwd_common.c support/passwd_common.h

[Joe Orton]

On Fri, Feb 02, 2024 at 08:29:48AM +0100, Ruediger Pluem wrote:
> 
> 
> On 2/1/24 5:54 PM, jor...@apache.org wrote:
> > Author: jorton
> > Date: Thu Feb  1 16:54:40 2024
> > New Revision: 1915516
> > 
> > URL: http://svn.apache.org/viewvc?rev=1915516=rev
> > Log:
...
> > -" -B  Force bcrypt encryption of the password (very secure)." NL
> > +" -2  Force SHA-256 crypt() hash of the password (secure)." NL
> > +" -5  Force SHA-512 crypt() hash of the password (secure)." NL
> > +" -B  Force bcrypt aencryption of the password (very secure)." NL
> 
> We have a typo above:aencryption

Good catch, thanks. Looks like a couple of the follow-up commits to this 
were missed which fixed that and improved the wording, I'll submit 
another backport.

Re: PR #363

[Joe Orton]

On Thu, Jan 25, 2024 at 08:12:24AM +0100, Ruediger Pluem wrote:
> Tried it in r1915391 and it seems to work. Not sure if there are 
> general downsides / objections with regards to symlinks in our 
> repository. But trunk is CTR :-).

Oh, that looks really nice. +1

Thanks to you, Rich, and Mayank Patil.

Regards, Joe

Re: PR #363

[Joe Schaefer]

With GFM, each line break separates paragraphs.

Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 




On Wed, Jan 24, 2024 at 11:01 AM Yann Ylavic  wrote:

> On Wed, Jan 24, 2024 at 4:56 PM Mads Toftum  wrote:
> >
> > On Wed, Jan 24, 2024 at 10:06:43AM -0500, rbo...@rcbowen.com wrote:
> > > I've been poking at some of our open PRs looking for docs-only changes
> > > that we can possibly clean up.
> > >
> > > PR #363 - https://github.com/apache/httpd/pull/363 - converts README
> > > from plaintext to markdown, and makes no other changes. This makes it
> > > prettier on GitHub.
> > >
> > > I almost just CTR'ed it, but it occurred to me that someone might find
> > > this objectionable, so I thought I'd ask first.
> >
> > I don't have strong opinions on this, but we'll end up with a READNE
> > that's less readable for those not viewing it through github.
>
> Maybe we could keep the line breaks as before for the text to keep it
> as readable as before w/o a markdown viewer?
>
>
> Regards;
> Yann.
>

Re: svn commit: r1914804 - in /httpd/httpd/trunk: changes-entries/flushing-chunks.txt modules/http/chunk_filter.c

[Joe Orton]

On Wed, 20 Dec 2023, 16:30 Yann Ylavic,  wrote:

> On Wed, Dec 20, 2023 at 5:20 PM Yann Ylavic  wrote:
> >
> > On Wed, Dec 20, 2023 at 4:56 PM  wrote:
> > >
> > > Author: jorton
> > > Date: Wed Dec 20 15:56:15 2023
> > > New Revision: 1914804
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1914804=rev
> > > Log:
> > > * modules/http/chunk_filter.c (ap_http_chunk_filter): For a brigade
> > >   containing [FLUSH EOS], insert the last-chunk terminator before the
> > >   FLUSH rather than between the FLUSH and the EOS.
> > >
> > > Github: closes #400
> >
> > It seems that we should set the last-chunk before the FLUSH only if
> > the latter precedes an EOS?
> >
> > So below:
> >
> > > --- httpd/httpd/trunk/modules/http/chunk_filter.c (original)
> > > +++ httpd/httpd/trunk/modules/http/chunk_filter.c Wed Dec 20 15:56:15
> 2023
> > > @@ -64,7 +64,7 @@ apr_status_t ap_http_chunk_filter(ap_fil
> > >
> > >  for (more = tmp = NULL; b; b = more, more = NULL) {
> > >  apr_off_t bytes = 0;
> > > -apr_bucket *eos = NULL;
> > > +apr_bucket *eos = NULL; /* EOS bucket, or FLUSH preceding EOS
> */
> > >  apr_bucket *flush = NULL;
> > >  /* XXX: chunk_hdr must remain at this scope since it is used
> in a
> > >   *  transient bucket.
> > > @@ -99,8 +99,20 @@ apr_status_t ap_http_chunk_filter(ap_fil
> > >  }
> > >  if (APR_BUCKET_IS_FLUSH(e)) {
> > >  flush = e;
> >
> > Don't set "flush" above.
> >
> > > +
> > > +/* Special case to catch common brigade ending of
> > > + * [FLUSH] [EOS] - insert the last_chunk before
> > > + * the FLUSH rather than between the FLUSH and the
> > > + * EOS. */
> > >  if (e != APR_BRIGADE_LAST(b)) {
> > > -more = apr_brigade_split_ex(b,
> APR_BUCKET_NEXT(e), tmp);
> > > +if (APR_BUCKET_IS_EOS(APR_BUCKET_NEXT(e))) {
> >
> > But here only?
> >
> > > +eos = e;
> > > +/* anything after EOS is dropped, no need
> > > + * to split. */
> > > +}
> > > +else {
> > > +more = apr_brigade_split_ex(b,
> APR_BUCKET_NEXT(e), tmp);
> > > +}
> > >  }
> > >  break;
> > >  }
> > > @@ -173,12 +185,12 @@ apr_status_t ap_http_chunk_filter(ap_fil
> > >   * FLUSH bucket, or appended to the brigade
> > >   */
> > >  e = apr_bucket_immortal_create(CRLF_ASCII, 2,
> c->bucket_alloc);
> > > -if (eos != NULL) {
> > > -APR_BUCKET_INSERT_BEFORE(eos, e);
> > > -}
> > > -else if (flush != NULL) {
> > > +if (flush != NULL) {
> > >  APR_BUCKET_INSERT_BEFORE(flush, e);
> > >  }
> > > +else if (eos != NULL) {
> > > +APR_BUCKET_INSERT_BEFORE(eos, e);
> > > +}
> > >  else {
> > >  APR_BRIGADE_INSERT_TAIL(b, e);
> > >  }
>
> Ah no, this is for every chunk so we are good here.
> For the last-chunk, I think we need
>

I think that's not necessary because in the special case eos=flush, in the
normal case flush is NULL. Actually the reordering of the tests above
doesn't make any difference either, I could have skipped that. In the first
iteration of the patch I renamed eos to "terminator" to make it more
obvious.

Index: modules/http/chunk_filter.c
> ===
> --- modules/http/chunk_filter.c(revision 1914804)
> +++ modules/http/chunk_filter.c(working copy)
> @@ -217,7 +217,7 @@ apr_status_t ap_http_chunk_filter(ap_filter_t *f,
>   * now.
>   */
>  if (eos && !ctx->bad_gateway_seen) {
> -ap_h1_add_end_chunk(b, eos, f->r, ctx->trailers);
> +ap_h1_add_end_chunk(b, flush ? flush : eos, f->r,
> ctx->trailers);
>  }
>
>  /* pass the brigade to the next filter. */
> --
> ?
>
>

Re: [PATCH] mod_deflate: remove filter after seeing EOS

[Joe Orton]

On Wed, Dec 20, 2023 at 04:24:32PM +0100, Ruediger Pluem wrote:
> On 12/20/23 4:08 PM, Yann Ylavic wrote:
> > On Wed, Dec 20, 2023 at 2:40 PM Joe Orton  wrote:
> >> https://github.com/apache/httpd/pull/400
> > 
> > Thanks, looks good to me.
> 
> +1

Thanks a lot for the quick reviews. Merged in r1914804 and happy Xmas :)

Regards, Joe

Re: [PATCH] mod_deflate: remove filter after seeing EOS

[Joe Orton]

On Wed, Dec 20, 2023 at 10:07:19AM -0500, Eric Norris via dev wrote:
> Thanks Joe, and no need to apologize, that's totally understandable.
> 
> I also appreciate you taking a look at the chunk filter behavior as that
> was actually going to be the next patch I proposed. I had written it here:
> https://github.com/ericnorris/httpd/commit/5f8fa24786b937ab611160b3c765cededa6dcb12,
> though in retrospect I'm not sure why this (or your patch) alone isn't
> enough, and why I thought the mod_deflate patch was also needed.

In the repro case you posted, only one brigade is passed by the handler, 
with that I saw the "delayed last chunk" behaviour but not the Zlib 
double-deinit error log. I think the Zlib error would only be triggered 
by passing a second brigade with a FLUSH.

It is incorrect for a handler to pass anything after EOS but filters are 
also supposed to be robust against it anyway.

> If I understand correctly, either patch would send the flush bucket after
> the last chunk marker and before the EOS bucket (i.e. [crlf last-chunk
> FLUSH EOS]), so there's no need for "userspace" to send an additional flush
> after the EOS bucket, and so mod_deflate wouldn't complain. Does that sound
> right?

I don't think the mod_deflate patch fixed the "delayed last-chunk" 
problem in my testing, but it is definitely correct & necessary to fix 
the Zlib error as above.

> Apologies on my part if that's the case - it had been a few months since I
> had written the patches, so I might have lost that context by the time I
> was able to investigate submitting the patches. I possibly should have
> submitted the chunk filter patch first. Either way, like I said I
> appreciate your time.

Thanks for taking the time to investigate & report it!

Regards, Joe

Re: [PATCH] mod_deflate: remove filter after seeing EOS

[Joe Orton]

On Mon, Oct 30, 2023 at 10:47:44AM -0400, Eric Norris via dev wrote:
> Hello again,
> 
> I'd like to politely bump this message to see if anyone would mind
> taking a look at this patch, either here or on GitHub.

Apologies, I got quite distracted by the "rapid reset" security stuff 
earlier in the year. I've merged your patch - thanks!

I was surprised this made a difference to the behaviour on the wire. It 
seems like the chunk filter has suboptimal behaviour here. If you take 
an output brigade like either:

a) [HEAP FLUSH EOS]
b) [HEAP FLUSH EOS FLUSH]

in both cases the chunk filter would output two brigades:

[chunk-hdr HEAP crlf FLUSH] [last-chunk EOS]

Significantly there is no FLUSH in the second brigade even for case (b), 
because the chunk filter also drops everything after EOS. It would be 
clearly better/correct if the chunk filter produces a single brigade for 
this very common output pattern:

[chunk-hdr HEAP crlf last-chunk FLUSH EOS]

correctly preserving the semantics of the FLUSH. I've tried this here:

https://github.com/apache/httpd/pull/400

Regards, Joe

> 
> Eric Norris
> Etsy
> 
> On Mon, Oct 9, 2023 at 2:50 PM Eric Norris  wrote:
> >
> > Hello all,
> >
> > I've submitted a pull request on GitHub here:
> > https://github.com/apache/httpd/pull/387, per the instructions I found
> > at https://httpd.apache.org/contribute. I figured it may also be
> > useful to share the patch here, but please feel free to redirect me as
> > this is my first time contributing.
> >
> > Thanks!
> >
> > Eric Norris
> > Etsy
> >
> >
> > At Etsy, we use mod_php and were investigating what we thought was
> > surprising behavior - that code executed during PHP's shutdown phase
> > prevented the request from terminating, even if we didn't expect to send
> > any additional output to the client.
> >
> > We determined that this was not surprising given mod_php's
> > implementation, but after we developed a proof-of-concept patch that
> > sent an EOS bucket and a flush bucket via a "userland" PHP function, we
> > were surprised that it didn't work when compression was enabled for the
> > request.
> >
> > I was able to reproduce this behavior with a simple Apache module built
> > on top of mod_example_hooks:
> >
> > https://gist.github.com/ericnorris/37c7dac401b50d270867e82a47bdd294
> >
> > It seems that this is because mod_deflate receives the EOS bucket and
> > then calls `deflateEnd` but remains in the filter chain. This means that
> > it receives the next flush bucket and attempts to call
> > `flush_libz_buffer`, which of course fails, causing it to print an
> > AH01385 error to the Apache error log, and perhaps most importantly, to
> > "eat" the flush bucket and not pass it down the bucket brigade.
> >
> > We found that this patch allows us to successfully send an EOS bucket
> > *and* promptly flush the connection so that the client knows the request
> > is finished.
> > ---
> >  modules/filters/mod_deflate.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/modules/filters/mod_deflate.c b/modules/filters/mod_deflate.c
> > index b7a68d2d43..ad753dc618 100644
> > --- a/modules/filters/mod_deflate.c
> > +++ b/modules/filters/mod_deflate.c
> > @@ -941,6 +941,10 @@ static apr_status_t deflate_out_filter(ap_filter_t *f,
> >  }
> >
> >  deflateEnd(>stream);
> > +
> > +/* We've ended the libz stream, so remove ourselves. */
> > +ap_remove_output_filter(f);
> > +
> >  /* No need for cleanup any longer */
> >  apr_pool_cleanup_kill(r->pool, ctx, deflate_ctx_cleanup);
> >
> > --
> > 2.40.1
> 

Re: svn commit: r1914045 - in /httpd/httpd/trunk: changes-entries/ab-source-address.txt docs/man/ab.1 support/ab.c

[Joe Orton]

On Wed, Nov 22, 2023 at 05:19:50PM -, minf...@apache.org wrote:
> Author: minfrin
> Date: Wed Nov 22 17:19:49 2023
> New Revision: 1914045
> 
> URL: http://svn.apache.org/viewvc?rev=1914045=rev
> Log:
> Add an option to specify a source address.

Saw this in the backports list - doesn't this duplicate existing the -B 
option for ab - or am I missing something?

Regards, Joe

Re: svn commit: r1914365 - in /httpd/httpd/trunk: changes-entries/ssl-providers.txt docs/log-message-tags/next-number docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_p

[Joe Orton]

On Wed, Dec 13, 2023 at 11:33:16AM +0100, Ingo Franzki wrote:
> On 13.12.2023 10:55, Joe Orton wrote:
> > On Wed, Dec 06, 2023 at 01:02:01PM +0100, Yann Ylavic wrote:
> >> Oh, scratch that. Actually the engine API requires a "SSLCryptoDevice
> >> pkcs11" too, so we wouldn't take the !mc->szCryptoDevice path.
> >> Sorry for the noise.
> > 
> > Yes it should remain compatible like that, though you prompted me to 
> > re-read that and it would break for a no-engine build: r1914622.
> Good catch!
> How would one compile without OpenSSL having the engine API ?
> At least currently, any supported OpenSSL version still does have the Engine 
> API. 

If you configure OpenSSL with the "no-engine" flag, you get 
OPENSSL_NO_ENGINE #define'd in the OpenSSL headers, and the engine API 
is not available.

Looks like a few more places which assume ->szCryptoDevice is always 
there, so there may be other build issues. We need a CI config for this.

> > I am not sure but we might want to add a new directive (yay) which loads 
> > a named provider, or we could rely on users doing that in openssl.cnf 
> > since configuring providers may be non-trivial (e.g. [1]).
> I would not try to load a named provider. While loading a named provider can 
> be done using the OpenSSL provider API,
> it is not possible to supply configuration parameters to that provider after 
> loading it. 
> Most provider I know do need specific configuration settings, they won't work 
> without them, especially the PKCS#11 providers. 
> So we must rely on users doing that in openssl.cnf.

That makes sense to me, thank you.

> > Other thing a colleage mentioned was that we may want to expand the list 
> > of URI schemes accepted here from just pkcs11://.
> Sure, the provider code in general should work for any kind of URIs, not only 
> 'pkcs11:'. 
> It would even work for the 'file:' URI, loading the keys/certs from PEM files 
> (like the non-provider/non-engine code is doing already).
> Actually it would even work for file names without a scheme at all, since the 
> default scheme is 'file:' anyway. 
> So it could theoretically replace the non-provider/non-engine load key/cert 
> code (not that I would suggests to change that as of today).

Yup. We would have to be careful to make the logic around loading the 
chain from the file would work exactly the same if a file:// URI was 
used. I'm not sure what the best approach is - try loading everything 
via a store and then fallback to the old way, or again add a new config 
option(s?) SSLBlahURI.

Regards, Joe

Re: svn commit: r1914365 - in /httpd/httpd/trunk: changes-entries/ssl-providers.txt docs/log-message-tags/next-number docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_p

[Joe Orton]

On Wed, Dec 06, 2023 at 01:02:01PM +0100, Yann Ylavic wrote:
> Oh, scratch that. Actually the engine API requires a "SSLCryptoDevice
> pkcs11" too, so we wouldn't take the !mc->szCryptoDevice path.
> Sorry for the noise.

Yes it should remain compatible like that, though you prompted me to 
re-read that and it would break for a no-engine build: r1914622.

I am not sure but we might want to add a new directive (yay) which loads 
a named provider, or we could rely on users doing that in openssl.cnf 
since configuring providers may be non-trivial (e.g. [1]).

Other thing a colleage mentioned was that we may want to expand the list 
of URI schemes accepted here from just pkcs11://.

[1] 
https://github.com/tpm2-software/tpm2-openssl/blob/master/docs/initialization.md#tpm-command-transmission-interface-tcti

Re: mod_dav_fs locking / Re: apr_dbm and concurrency

[Joe Orton]

On Thu, Nov 23, 2023 at 05:42:10PM +, Emmanuel Dreyfus wrote:
> On Thu, Nov 23, 2023 at 05:36:06PM +0000, Joe Orton wrote:
> > 3) in the mean time I worked up a PR for mod_dav_fs which adds a global 
> > mutex around the dbm lockdb use. This passes my stress tests for the 
> > first time.
> 
> How concurent is the stress test? 

I've been testing with 20 concurrent clients on an 8 core machine.

> In the past, I have been badly hurt by a few WebDAV clients proactively 
> exploring the filesystem using locksdiscovery. That compeltely killed the 
> service. I introduced the DavLockDiscovery directive to work it around.

This is a good point. Was the load in that case PRPOFIND/depth:infinity 
do you know or "just" depth:1? A global lock like in my PR would make 
the PROPFIND load even worse, since the lock is held for the duration of 
the response and there are no concurrent read-only locks.

It might be necessary to disable lock discovery by default then, I don't 
know if any clients rely on or expose that but it's only a "MAY" that 
lock discvovery is possible in RFC4918. I suspect the lock recovery 
mechanism for most users & clients is to delete the lockdb.

Regards, Joe

mod_dav_fs locking / Re: apr_dbm and concurrency

[Joe Orton]

Adding dev@httpd to a dev@apr thread about apr_dbm locking being broken.

On Sun, Nov 12, 2023 at 07:43:13AM -0600, Greg Stein wrote:
> Or, apps can stick to an older APR. ... we don't have to carry this forward
> into future versions of APR (IMO).
> 
> To your point, it is probably a single page with code samples to show how
> to do K/V with sqlite, to replace the apr_dbm calls. That's gonna be way
> easier than locking code integrated into apr_dbm.

This seems reasonable to me for the mod_dav use case where the database 
is an implementation detail which users don't care about. For other use 
cases in httpd I'm not so sure, but saying "dbm is dead, sqlite is the 
way" is probably possible for all of them. It does mean someone writing 
a lot of new modules to replace mod_auth*dbm etc tho ;)

There are a few alternative approaches I looked at:

1) we could hack fcntl-based locks to work on Linux by using F_OFD_SETLK 
etc which a sane locking model rather than the weird/dumb F_SETLK which 
has the traditional/POSIX non-thread-safe model. Linux-specific, so...

2) try to shoehorn "proper" locking into apr_dbm is hard because there 
isn't a suitable locking primitive that can be used at this level. Maybe 
the only approach that might work would be filesystem-based locking 
based off open/O_EXCL but this is not exactly reliable.

3) in the mean time I worked up a PR for mod_dav_fs which adds a global 
mutex around the dbm lockdb use. This passes my stress tests for the 
first time. Kind of ugly but this seems like the least ugly option at 
this point other than the "start again with sqlite": 
https://github.com/apache/httpd/pull/395

Any comments/review/flames from either dev@ welcome.

Regards, Joe

Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[Joe Schaefer]

Steve Hay was a great resource once upon a time ago, but meh, you can't
draw blood from a stone forever.

On Tue, Oct 17, 2023 at 12:32 PM Steffen  wrote:

> For me still -1.
>
> > Op 17 okt 2023 om 18:18 heeft Stefan Eissing via dev <
> dev@httpd.apache.org> het volgende geschreven:
> >
> > Just got a reply from a contact that build rc3 on win64 and ran it
> successfully. I invited him to participate here, not sure if he will feel
> like it.
> >
> > I count that as a +1 on win64 unless someone objects.
> >
> > Cheers,
> > Stefan
> >
> >
> >> Am 17.10.2023 um 12:05 schrieb Stefan Eissing via dev <
> dev@httpd.apache.org>:
> >>
> >> I am trying to contact another person that builds regularly mod_h2 on
> Windows.
> >>
>  Am 17.10.2023 um 11:30 schrieb Steffen :
> >>>
> >>> Same error on win64.
> >>> Yes the reported mod_http2 errors on 32 and 64.
> >>> Yes, I am not able to tell what is wrong, only I can report the
> errors. I am not a developer, just building and testing.
> >>>
> >>> Regards, Steffen
> >>>
>  Op 17 okt 2023 om 11:08 heeft Stefan Eissing via dev <
> dev@httpd.apache.org> het volgende geschreven:
> 
>  
> 
> > Am 17.10.2023 um 08:41 schrieb Steffen :
> >
> > -1 does not build on windows.
> 
>  If I understood your reports from yesterday correctly, the situation
> is
>  - you can build on win64
>  - you get compiler errors on your win32 build
>  - you are not able to tell us what is wrong
> 
>  Correct?
> 
>  Cheers,
>  Stefan
> 
> >
> > Steffen
> >
> >>> Op 16 okt 2023 om 17:10 heeft Stefan Eissing via dev <
> dev@httpd.apache.org> het volgende geschreven:
> >>
> >> Hi all,
> >>
> >> after fixing my merge mistake in rc2 (sorry!), we go again:
> >>
> >> 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 httpd-2.4.58-rc3 as 2.4.58:
> >> [ ] +1: It's not just good, it's good enough!
> >> [ ] +0: Let's have a talk.
> >> [ ] -1: There's trouble in paradise. Here's what's wrong.
> >>
> >> The computed digests of the tarball up for vote are:
> >> sha256:
> 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6
> *httpd-2.4.58-rc3.tar.gz
> >> sha512:
> 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3
> *httpd-2.4.58-rc3.tar.gz
> >>
> >> The SVN candidate source is found at tags/2.4.58-rc3-candidate.
> >>
> >> Cheers,
> >> Stefan
> >
> 
> >>>
> >>
> >
>
>

Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[Joe Orton]

On Mon, Oct 16, 2023 at 05:08:11PM +0200, Stefan Eissing via dev wrote:
> Hi all,
> 
> after fixing my merge mistake in rc2 (sorry!), we go again:
> 
> 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 httpd-2.4.58-rc3 as 2.4.58:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.

+1 for release from me, sigs good; builds and passes tests on Fedora 39 
and RHEL 8 and 9, my old computers are happy again ;)

Big thanks for fixes and RMing.

Regards, Joe

Re: windows block

[Joe Orton]

On Mon, Oct 16, 2023 at 04:45:29PM +0200, Stefan Eissing via dev wrote:
> Do I make an rc3 nevertheless? Do we know someone else using VC?
> 
> Advice appreciated.

+1 for rc3 at r1913027.

Someone using VC needs to work out how to fix that rather than just 
report it's broken, it shouldn't hold progress up for the rest of the 
world.

Regads, Joe

Re: svn commit: r1913006 - in /httpd/httpd/branches/2.4.x: ./modules/http2/h2.h

[Joe Orton]

On Mon, Oct 16, 2023 at 03:12:24PM +0200, SteffenAL wrote:
> 
> checkout.
> 
> 
> Looks like h2_ws.h :
> 
> 
> Generating Code...
> h2_ws.h
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h(173,17): error C2143: syntax
> error: missing ';' before '*'
> C:\VS17\Win32\httpd-2.4\modules\http2\h2.h(173,17): error C4430: missing
> type specifier - int assumed. Note: C++ does not support default-int

Windows compiler errors are often specific to the Windows, you should 
not assume anybody else here will understand (or care) about them. So 
rather than reporting, can you work out what the problem is? Line 173 
uses apr_table_t, does adding #include "apr_tables.h" somewhere help 
here?

Regards, Joe

Re: svn commit: r1913019 - in /httpd/httpd/trunk/modules/http2: h2_session.c h2_ws.c

[Joe Orton]

On Mon, Oct 16, 2023 at 02:54:58PM +0200, Ruediger Pluem wrote:
> Fails for me as well. Not sure what fails for Joe such that he removed the 
> include, but if it fails in case H2_USE_WEBSOCKETS is
> not 1 I guess we could move the include (or even all) below the
> 
> #if H2_USE_WEBSOCKETS
> 
> line.

Oh, sorry guys. 

I was building against APR 1.6.x here which doesn't have apr_encode.h, I 
didn't see the apr_pencode use. So how about:

r1913019 + r1913023, +1 for 2.4.x for the pair

Re: [PATCH] fix mod_h2 with older nghttp2

[Joe Orton]

BTW is modules/http2 really CTR for 2.4.x? STATUS says only 
mod_proxy_http2 is.

Anyway: I am +1 for r1913005 and r1913019 for 2.4.x, latter was 
sufficient to get 2.4 building on RHEL8 again (if only we had a CI to do 
this, oh...).

Regards, Joe

[PATCH] fix mod_h2 with older nghttp2

[Joe Orton]

Looks like this broke with the websockets backport. mod_h2 is failing to 
compile on versions of nghttp2 without 
NGHTTP2_SETTINGS_ENABLE_CONNECT_PROTOCOL - looks like this was added in 
nghttp2 v1.34.0 [1] so how about something like this, or is there a 
better way?

(configure check for a declaration is messier)

diff --git a/modules/http2/h2.h b/modules/http2/h2.h
index cfecb3d9a3..06e7087c04 100644
--- a/modules/http2/h2.h
+++ b/modules/http2/h2.h
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include 
+
 struct h2_session;
 struct h2_stream;
 
@@ -39,7 +41,7 @@ struct h2_stream;
 #define H2_USE_POLLFD_FROM_CONN 0
 #endif
 
-#if H2_USE_PIPES
+#if H2_USE_PIPES && defined(NGHTTP2_VERSION_NUM) && NGHTTP2_VERSION_NUM >= 
0x012200
 #define H2_USE_WEBSOCKETS   1
 #else
 #define H2_USE_WEBSOCKETS   0



[1] https://github.com/nghttp2/nghttp2/milestone/30?closed=1 

Re: Please support/enable https by default in the Apache web sever.

[Joe Schaefer]

It is insane to ask this project to cater to the interests of 10 people who
are so PKI illiterate, the PMC needs to put the rest of the user base at
risk just to accommodate them.

Certs require mandatory user serviceable parts.  There is no meaningful way
to  provide a default.

Thanks.

On Sat, Sep 30, 2023 at 10:45 AM General Email <
general.email.12341...@gmail.com> wrote:

>
>
> On Sat, 30 Sep, 2023, 8:00 pm Emmanuel Dreyfus,  wrote:
>
>> On Sat, Sep 30, 2023 at 07:40:34PM +0530, General Email wrote:
>> > By the way, I don't understand how the default certificate can be
>> abused.
>>
>> It is not signed by a trusted CA, hence your browser cannot tell if it
>> is speaking to your legitimate web server, or to some malware lurking
>> in between. Perhaps your web trafic is not worth being evesdropped, but
>> consider a malware could inject an exploit against your browser in your
>> web trafic. The attacker could just be an infected machine on the same
>> LAN.
>>
>> The security level of an untrusted ceritificate is not much better than
>> plain text HTTP.
>>
>
>
> Yes, I understand this.
>
> We will not be using the default untrusted certificate when we go live.
>
> But during development, if 10 people are working on the development of one
> website and each of them has their own apache http installation, then we
> have to generate 10 certificates and do a few changes or more than few
> changes to get https enabled on each of 10 installations.
>
> Having a default certificate (not signed by trusted CA) in official http
> server will make enabling https on each installation much easier and we
> won't have to generate 10 certificates, etc.
>
> Regards,
> GE
>
>

Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"

[Joe Orton]

On Thu, Sep 07, 2023 at 06:46:01PM +0200, Yann Ylavic wrote:
> On Thu, Sep 7, 2023 at 6:09 PM Yann Ylavic  wrote:
> >
> > On Wed, Aug 30, 2023 at 1:22 PM Rainer Jung  wrote:
> > >
> > > OpenSSL 3 flags some abortive shutdowns as an error different to what
> > > 1.1.1 did. This results in info log output in httpd:
> > >
> > > [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737]
> > > SSL Library Error: error:0A000126:SSL routines::unexpected eof while 
> > > reading
> > > [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737]
> > > [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with
> > > abortive shutdown (server myserver:443)
> >
> > The info looks legit to me (someone closed the connection with no
> > close_notify), possibly we want to log it at APLOG_DEBUG/TRACEx still
> > if it happens too often?
> > We don't do that though for SSL_ERROR_ZERO_RETURN in openssl < 3, but
> > maybe we should too like in the attached patch (instead of r1912015)?
> 
> Scratch that patch, SSL_ERROR_ZERO_RETURN is actually when
> close_notify was received, we'd rather need to test SSL_ERROR_SYSCALL
> && errno == 0 with openssl < 0, which is more tricky in httpd with the
> EOS bucket vs APR_EOF.
> Hm, not sure we want to complicate this more..

Yeah, I wondered about that too. Maybe we need some kind of "strict 
mode" in mod_ssl which does better/correct close_notify handling?

Regards, Joe

Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"

[Joe Orton]

On Wed, Aug 30, 2023 at 01:21:11PM +0200, Rainer Jung wrote:
> Hi there,
> 
> OpenSSL 3 flags some abortive shutdowns as an error different to what 1.1.1
> did. This results in info log output in httpd:
> 
> [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737] SSL
> Library Error: error:0A000126:SSL routines::unexpected eof while reading
> [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737]
> [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with abortive
> shutdown (server myserver:443)
> 
> Some background is given in
> 
>   https://github.com/openssl/openssl/issues/18866
> 
> They introduced a new context option "SSL_OP_IGNORE_UNEXPECTED_EOF" to
> suppress this. Some other software now sets it with SSL_CTX_set_options():

Interesting! Just wondering, is there a reason why we'd only want to 
enable this for server-side operation (mctx->pkp == NULL) not also for 
client-side/proxy operation? Seems like it might be better to enable it 
unconditionally.

Regards, Joe

Re: Time for a new libapreq2 release?

[Joe Schaefer]

The readd is an acceptable loss at this point.  Never could avoid Rich’s
spam since he culls from every list.


On Mon, Aug 28, 2023 at 5:51 PM Greg Stein  wrote:

> You "should" have commit access to svn:repos/asf/httpd/ now. We had to
> re-add you to the "committers" list (which also implies receiving future
> emails to that list).
>
>
> On Mon, Aug 28, 2023 at 3:52 PM Joe Schaefer  wrote:
>
>> No objection. Happy to Tag and roll of my account is made available
>> somehow.
>>
>> On Mon, Aug 28, 2023 at 4:50 PM Greg Stein  wrote:
>>
>>> Your LDAP record is still present [1]. You're still on the PMC of httpd
>>> and perl. Commit rights to incubator, sis, subversion. Dunno where httpd
>>> went, but as a PMC member of httpd you should have commit. We can fix that.
>>>
>>> So should we fix this up, so you can walk through a libapreq2 release?
>>>
>>> Cheers,
>>> -g
>>> [1] https://whimsy.apache.org/roster/committer/joes
>>>
>>>
>>> On Mon, Aug 28, 2023 at 8:43 AM Joe Schaefer  wrote:
>>>
>>>> Because my account no longer exists?
>>>>
>>>> On Mon, Aug 28, 2023 at 1:43 AM Greg Stein  wrote:
>>>>
>>>>> you're on the PMC. Why don't you do the tag ?
>>>>>
>>>>> On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer 
>>>>> wrote:
>>>>>
>>>>>> Seems like it’s been a year since the last release, which means it’s
>>>>>> time for good people to take another try at releasing something
>>>>>> nondefective.
>>>>>>
>>>>>> Here to help with the quality control this time around.
>>>>>> --
>>>>>> Joe Schaefer, Ph.D.
>>>>>> <https://sunstarsys.com/orion/features>
>>>>>> Orion - The Enterprise Jamstack Wiki
>>>>>> <https://sunstarsys.com/orion/features>
>>>>>> 
>>>>>> 954.253.3732 
>>>>>>
>>>>>>
>>>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> <https://sunstarsys.com/orion/features>
>>>> Orion - The Enterprise Jamstack Wiki
>>>> <https://sunstarsys.com/orion/features>
>>>> 
>>>> 954.253.3732 
>>>>
>>>>
>>>> --
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: Time for a new libapreq2 release?

[Joe Schaefer]

No objection. Happy to Tag and roll of my account is made available somehow.

On Mon, Aug 28, 2023 at 4:50 PM Greg Stein  wrote:

> Your LDAP record is still present [1]. You're still on the PMC of httpd
> and perl. Commit rights to incubator, sis, subversion. Dunno where httpd
> went, but as a PMC member of httpd you should have commit. We can fix that.
>
> So should we fix this up, so you can walk through a libapreq2 release?
>
> Cheers,
> -g
> [1] https://whimsy.apache.org/roster/committer/joes
>
>
> On Mon, Aug 28, 2023 at 8:43 AM Joe Schaefer  wrote:
>
>> Because my account no longer exists?
>>
>> On Mon, Aug 28, 2023 at 1:43 AM Greg Stein  wrote:
>>
>>> you're on the PMC. Why don't you do the tag ?
>>>
>>> On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer  wrote:
>>>
>>>> Seems like it’s been a year since the last release, which means it’s
>>>> time for good people to take another try at releasing something
>>>> nondefective.
>>>>
>>>> Here to help with the quality control this time around.
>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> <https://sunstarsys.com/orion/features>
>>>> Orion - The Enterprise Jamstack Wiki
>>>> <https://sunstarsys.com/orion/features>
>>>> 
>>>> 954.253.3732 
>>>>
>>>>
>>>> --
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: Time for a new libapreq2 release?

[Joe Schaefer]

Because my account no longer exists?

On Mon, Aug 28, 2023 at 1:43 AM Greg Stein  wrote:

> you're on the PMC. Why don't you do the tag ?
>
> On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer  wrote:
>
>> Seems like it’s been a year since the last release, which means it’s time
>> for good people to take another try at releasing something nondefective.
>>
>> Here to help with the quality control this time around.
>> --
>> Joe Schaefer, Ph.D.
>> <https://sunstarsys.com/orion/features>
>> Orion - The Enterprise Jamstack Wiki
>> <https://sunstarsys.com/orion/features>
>> 
>> 954.253.3732 
>>
>>
>> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Time for a new libapreq2 release?

[Joe Schaefer]

Seems like it’s been a year since the last release, which means it’s time
for good people to take another try at releasing something nondefective.

Here to help with the quality control this time around.
-- 
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: svn commit: r1911908 - /httpd/httpd/branches/2.4.x/STATUS

[Joe Orton]

On Fri, Aug 25, 2023 at 12:11:38PM +0200, Ruediger Pluem wrote:
> > ==
> > --- httpd/httpd/branches/2.4.x/STATUS (original)
> > +++ httpd/httpd/branches/2.4.x/STATUS Fri Aug 25 07:52:31 2023
> > @@ -225,11 +225,12 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
> >*) mod_dav: add DavBasePath (PR 35077)
> >   Trunk version of patch:
> >  https://svn.apache.org/r1911651
> > +https://svn.apache.org/r1911906
> 
> Sorry for being picky, but don't we miss r1911907?

Oh, that rev is docs-only so isn't subject to RTC rules and I didn't 
think about including it here. I will backport the docs bits too though, 
definitely.

Regards, Joe

Re: svn commit: r1910861 - /httpd/httpd/trunk/support/ab.c

[Joe Orton]

On Mon, Jul 10, 2023 at 11:12:09AM +0200, Yann Ylavic wrote:
> I think this is not reached with rtnevents == POLLOUT|POLLHUP because
> it takes the first POLLIN|POLLHUP continue-branch.
> I moved the check for POLLOUT first in r1910911, which fixed the issue for me.

Perfect, works for me too - thanks Yann.

Regards, Joe

Re: svn commit: r1910861 - /httpd/httpd/trunk/support/ab.c

[Joe Orton]

On Fri, Jul 07, 2023 at 03:52:46PM -, yla...@apache.org wrote:
> Author: ylavic
> Date: Fri Jul  7 15:52:45 2023
> New Revision: 1910861
> 
> URL: http://svn.apache.org/viewvc?rev=1910861=rev
> Log:
> ab: Fix accounting of started connections.
> 
> Revert when a kept alive connection is aborted on read.
> Stop the polling loop when there is nothing to poll anymore, it's simpler.

Not related to this change but I noticed that trunk ab has stopped 
failing if trying to connect to a closed port, strace looks like:

epoll_wait(3, [{events=EPOLLOUT|EPOLLERR|EPOLLHUP, data={u32=33073216, 
u64=33073216}}], 2, 3) = 1 
epoll_wait(3, [{events=EPOLLOUT|EPOLLERR|EPOLLHUP, data={u32=33073216, 
u64=33073216}}], 2, 3) = 1 
...

With HUP set in the returned events it enters the first if() at 
https://github.com/apache/httpd/blob/trunk/support/ab.c#L2523 but 
STATE_CONNECTING is not handled there and so it loops indefinitely. 
That's as far as I debugged it, sorry. Any ideas?

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

All good.  Just didn’t want to see needless delays in getting this stuff
incorporated while you build out the non-content handler mode for mod_wasm
that IMO will never be in big demand (if it were, mod_perl wouldn’t be such
a stagnant community over the past two decades).

On Fri, Jul 7, 2023 at 4:07 PM Jesús González  wrote:

> Joe, thanks for your feedback!
>
>
>
> Just to make sure I understand this feedback, what you are mentioning is
> that exposing the internals of Apache diminishes the value of the sandbox
> because programs could potentially perform write operations into the
> internals of httpd state, tables, etc. Is that correct?
>
>
>
> If my understanding is correct, this should not be an issue:
>
>
>
> - The current incarnation of mod_wasm is implemented as a content-handler
> and does not have access to the internals of Apache or tables. All the
> information is passed through environment variables, similar to a
> traditional CGI binary, but running in the Wasm sandbox (so you can control
> tightly any access to filesystem, network, etc.).
>
>
>
> - The proposed changes to mod_wasm that enable writing Apache modules in
> other languages would expose the API, but that’s the idea: to make it easy
> to build fully featured Apache modules using any language that can compile
> to Wasm (ie: Go, Python). Think of this as an ‘universal’ polyglot version
> of mod_lua with added sandboxing capabilities.
>
>
>
> Which mode to use can be configured. You definitely don’t want random
> users having access to the internals of httpd when serving their regular
> application (ie: Drupal).
>
>
>
> Having said all of this, regarding the read-only structs, a Wasm binary
> cannot access the host memory space. So, a pointer to an apr table in the
> httpd memory space cannot be dereferenced within the sandbox. There exist
> opaque reference types (ie: externref) to host objects that comply with
> WebAssembly sandboxing guarantees as explained in
> https://fitzgeraldnick.com/2020/08/27/reference-types-in-wasmtime.html.
> This is great in terms of security, but a drawback from a performance
> perspective. To manipulate data structs, either they are copied into the
> Wasm memory and copied back to the server, or we offer a set of limited
> interfaces to the Wasm binary to perform such actions. So yes, we believe
> your proposal of getting the apreq_* (ARP table-based) interfaces exposed
> as read-only data structures is doable and useful.
>
> Cheers!
>
>
>
> *De: *Joe Schaefer 
> *Fecha: *miércoles, 5 de julio de 2023, 4:59
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> *!! External Email*
>
> The win with having an apr table  api from httpd is that by sharing those
> tables in the sandbox, various programming languages will be able to
> interact with others without stealing the client form inputs.
>
>
>
> Even if you don’t go that route, and just expose the form inputs on stdin
> in your app, users can always configure apreq’s input filter to activate on
> the protocol filter chain before wasm activates. That way other modules
> still can access form input without breaking the Wasm app.
>
>
>
> On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer  wrote:
>
> The more of the API you expose, the less value the sandbox has to end
> users.  For Webapps, easy read/search / write/ iterate is essential.  But
> also form data; which apreq stores in readonly apr tables.
>
>
>
> Joe Schaefer, Ph.D
>
> 
>
> +1 (954) 253-3732
>
> SunStar Systems, Inc.
>
> *Orion - The Enterprise Jamstack Wiki*
>
>
> --
>
> *From:* Jesús González 
> *Sent:* Monday, July 3, 2023 8:49:33 AM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
>
>
> Hola!
>
> mod_wasm v0.12.1
> <https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now
> available!
>
> This maintenance release bumps Wasmtime to 10.0.1, including preliminary
> support for WASI preview 2 among other improvements and fixes.
>
> Best,
> Jesús
>
>
>
> *De: *Jesús González 
> *Fecha: *viernes, 2 de junio de 2023, 19:09
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> Thanks Joe for your encouragement! And yes, your feedback was what
> inspired us to expand mod_wasm in this direction.
>
> In the demo from my colleague Asen, we expose three wrapper functions to
> WebAssembly get_header, set_header, delete_header, that internally make use
> of apr_table_get, apr_table_set and apr_table_unset with the incoming
> request headers (r->headers_in). This

Re: svn commit: r1910820 - in /httpd/httpd/branches/2.4.x: ./ changes-entries/pr60182.txt modules/ssl/ssl_util_stapling.c

[Joe Orton]

On Thu, Jul 06, 2023 at 10:58:07PM +0200, Christophe JAILLET wrote:
> Le 06/07/2023 à 18:11, jor...@apache.org a écrit :
> > Author: jorton
> > Date: Thu Jul  6 16:11:56 2023
> > New Revision: 1910820
> > 
> > URL: http://svn.apache.org/viewvc?rev=1910820=rev
> > Log:
> > Merge r1875355 from trunk:
> > 
> > * modules/ssl/ssl_util_stapling.c (stapling_check_response) Don't stop
> >Certificate Revoked messages.
> > 
> >Certificate Revoked Responder messages don't belong to 'error' class.
> >When the server receives one, it MUST be passed on to the client.
> >And stored for the normal period of basic responses.
> > 
> >Also don't log an error each time it is retrieved from cache,
> >only once when it is retrieved from the OCSP responder.
> > 
> > PR: 60182
> > Obtained from: 
> > https://github.com/apache/httpd/commit/7db9795f45fd4688ceb13ee36090e4e2becbc709.diff
> > Submitted by: 
> > Reviewed by: gbechis, icing, ylavic
> 
> Hi,
> 
> I've not seen it in STATUS.
> 
> I'm a bit distant this days, so I may have missed something, but usually
> STATUS is updated just before or after a commit, and I don't see it either.

Hi Christophe - this was voted for in STATUS under "Fix for BZ 66626" 
though I missed that the bug number mentioned is different to the commit 
message. I've fixed the changes entry just now since 66626 is the right 
one. https://github.com/apache/httpd/blob/2.4.x/STATUS#L196

Thanks for checking & thanks for fixing my typo too.

Regards, Joe

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

The win with having an apr table  api from httpd is that by sharing those
tables in the sandbox, various programming languages will be able to
interact with others without stealing the client form inputs.

Even if you don’t go that route, and just expose the form inputs on stdin
in your app, users can always configure apreq’s input filter to activate on
the protocol filter chain before wasm activates. That way other modules
still can access form input without breaking the Wasm app.

On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer  wrote:

> The more of the API you expose, the less value the sandbox has to end
> users.  For Webapps, easy read/search / write/ iterate is essential.  But
> also form data; which apreq stores in readonly apr tables.
>
> Joe Schaefer, Ph.D
> 
> +1 (954) 253-3732
> SunStar Systems, Inc.
> *Orion - The Enterprise Jamstack Wiki*
>
> --
> *From:* Jesús González 
> *Sent:* Monday, July 3, 2023 8:49:33 AM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
>
> Hola!
>
> mod_wasm v0.12.1
> <https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now
> available!
>
> This maintenance release bumps Wasmtime to 10.0.1, including preliminary
> support for WASI preview 2 among other improvements and fixes.
>
> Best,
> Jesús
>
>
>
> *De: *Jesús González 
> *Fecha: *viernes, 2 de junio de 2023, 19:09
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> Thanks Joe for your encouragement! And yes, your feedback was what
> inspired us to expand mod_wasm in this direction.
>
> In the demo from my colleague Asen, we expose three wrapper functions to
> WebAssembly get_header, set_header, delete_header, that internally make use
> of apr_table_get, apr_table_set and apr_table_unset with the incoming
> request headers (r->headers_in). This shows read and write capabilities
> from a Wasm binary using internal Apache APIs. Is this what you are
> referring to with exposing apreq_*?
>
> Limiting to read-only (ie: just get_header) implies that some
> functionality that is possible with other extension modules (mod_headers,
> mod_perl, mod_lua, etc.) won’t be available in mod_wasm. We would love to
> know more about those concerns, so we can understand better how to develop
> mod_wasm in a way that both allows you to develop fully capable modules but
> still address any concerns you may have.
>
> BTW, here is a recent article showing how mod_wasm can help mitigating
> vulnerabilities
> https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/,
> proving how it adds an extra layer of security to traditional applications.
>
> Looking forward to your feedback.
>
>
> *De: *Joe Schaefer 
> *Fecha: *jueves, 1 de junio de 2023, 22:16
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> *!! External Email*
>
> Huge fan, love that you are receptive to my feedback.  If you get to the
> point where the apreq_* (APR table-based) interfaces in trunk can be
> exposed as read-only data structures in mod_wasm as an optional API for
> power httpd users that like the sandboxed functionality you get OOTB, that
> would justify a lot of the more conservative concerns that some devs have
> for not putting incorporating this into the trunk codebase, which would be
> my recommendation at that point for how to get it into a releasable tree at
> some point.
>
>
>
>
>
> On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
> wrote:
>
> I think not making WASM a first class concern in a proxy or server is
> missing out, more so in those platforms where extensibility isn't trivial.
> Apache will remain running in current setups but having limited
> extensibility is something concerning these days as systems are getting
> more and more complex. Writing an apache module isn't something you do
> every day and it probably takes quite some time, writing a wasm app
> following certain ABI is something you can do in minutes, hence supporting
> mod_wasm as a first class concern could be a good point in the
> sustainability of an ecosystem when it comes to moving forward out of the
> status quo.
>
> On 2022/11/14 06:37:34 Jesús González wrote:
> > Hi everyone,
> >
> >
> >
> > I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<
> https://wasmlabs.dev/>, a group focused on creating open source tools for
> WebAssembly.
> >
> > We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would l

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

The more of the API you expose, the less value the sandbox has to end users.  
For Webapps, easy read/search / write/ iterate is essential.  But also form 
data; which apreq stores in readonly apr tables.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Jesús González 
Sent: Monday, July 3, 2023 8:49:33 AM
To: dev@httpd.apache.org 
Subject: Re: mod_wasm: Contributing Upstream to Apache


Hola!

mod_wasm v0.12.1<https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> 
is now available!

This maintenance release bumps Wasmtime to 10.0.1, including preliminary 
support for WASI preview 2 among other improvements and fixes.

Best,
Jesús



De: Jesús González 
Fecha: viernes, 2 de junio de 2023, 19:09
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache

Thanks Joe for your encouragement! And yes, your feedback was what inspired us 
to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to 
WebAssembly get_header, set_header, delete_header, that internally make use of 
apr_table_get, apr_table_set and apr_table_unset with the incoming request 
headers (r->headers_in). This shows read and write capabilities from a Wasm 
binary using internal Apache APIs. Is this what you are referring to with 
exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality 
that is possible with other extension modules (mod_headers, mod_perl, mod_lua, 
etc.) won’t be available in mod_wasm. We would love to know more about those 
concerns, so we can understand better how to develop mod_wasm in a way that 
both allows you to develop fully capable modules but still address any concerns 
you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating 
vulnerabilities 
https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/, 
proving how it adds an extra layer of security to traditional applications.

Looking forward to your feedback.



De: Joe Schaefer 
Fecha: jueves, 1 de junio de 2023, 22:16
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache

!! External Email

Huge fan, love that you are receptive to my feedback.  If you get to the point 
where the apreq_* (APR table-based) interfaces in trunk can be exposed as 
read-only data structures in mod_wasm as an optional API for power httpd users 
that like the sandboxed functionality you get OOTB, that would justify a lot of 
the more conservative concerns that some devs have for not putting 
incorporating this into the trunk codebase, which would be my recommendation at 
that point for how to get it into a releasable tree at some point.





On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
mailto:jcchav...@apache.org>> wrote:

I think not making WASM a first class concern in a proxy or server is missing 
out, more so in those platforms where extensibility isn't trivial. Apache will 
remain running in current setups but having limited extensibility is something 
concerning these days as systems are getting more and more complex. Writing an 
apache module isn't something you do every day and it probably takes quite some 
time, writing a wasm app following certain ABI is something you can do in 
minutes, hence supporting mod_wasm as a first class concern could be a good 
point in the sustainability of an ecosystem when it comes to moving forward out 
of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: 
> wasmlabs.dev<http://wasmlabs.dev/><https://wasmlabs.dev/>, a group focused on 
> creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries 
> inside httpd, and we would like to contribute it upstream. Please see below 
> for more details. We would love to get your feedback and understand what 
> improvements would be needed (if any) before it could be considered for 
> contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction 
> format that is open, portable, efficient, secure, and polyglot. It originated 
> in the browser but is increasingly used in server applications, in particular 
> NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: 
> https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is 
> similar to how mod_php embeds a PHP runtime to run PHP code. This enables any 
> language that supports WebAssembly (including C++, Rust, Go but also Python, 
> PHP, Ruby) to run with mod_wasm and take advantage of the extra level of 
> security and

Re: libapreq 2.17 POST upload with empty filename parameter

[Joe Schaefer]

2.17 was a dud security release.  Use trunk

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Raymond Field via dev 
Sent: Tuesday, July 4, 2023 7:36:33 AM
To: dev@httpd.apache.org 
Subject: libapreq 2.17 POST upload with empty filename parameter

Hi,

I don't know if this is the correct place to report an issue with
libapreq2, please let me know where I should sent this report if this
isn't the correct place.

If I POST a form to the server that contains unfilled file upload fields, the
library seems to give up processing at the first empty filename, e.g. if
I POST

-15448443913271751721417945010
Content-Disposition: form-data; name="postticket"


-15448443913271751721417945010
Content-Disposition: form-data; name="uid"

1263741688468911
-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_file";
filename="some_test.txt"
Content-Type: text/plain

this is some text


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_type"

Document
-15448443913271751721417945010
Content-Disposition: form-data; name="vidlinkhtml"


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_thumbnail"; filename=""
Content-Type: application/octet-stream


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_file_thumbnail"; filename=""
Content-Type: application/octet-stream


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_title"

joe_wicks_crispy_sesame_chicken
-15448443913271751721417945010
Content-Disposition: form-data; name="new_access"

General
-15448443913271751721417945010
Content-Disposition: form-data; name="new_port_name"


-15448443913271751721417945010
Content-Disposition: form-data; name="new_doc_desc"


-15448443913271751721417945010
Content-Disposition: form-data; name="role_7_priv_2"

21
-15448443913271751721417945010
Content-Disposition: form-data; name="new_comments"

YES
-15448443913271751721417945010
Content-Disposition: form-data; name="new_notify"

YES
-15448443913271751721417945010
Content-Disposition: form-data; name="add_submit"

Submit
-15448443913271751721417945010
Content-Disposition: form-data; name="add_submit_button"

Submit
-15448443913271751721417945010--

When looking at $apr->param I only see the following names: postticket
uid new_doc_file vidlinkhtml

i.e. up to but not including the first parameter with filename=""

If I submit the form without the parameters that have empty filenames I
see all of the parameter names.

This started happening when I upgraded a server from Debian 11 to Debian
12, so it worked OK in libapreq 2.13.  The libapreq libraries are not
currently included in the Bookwork package list, so I added them from
testing.  I've also tried installing directly from CPAN, but the same issue.

Kind regards,

Raymond Field

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Huge fan, love that you are receptive to my feedback.  If you get to the
point where the apreq_* (APR table-based) interfaces in trunk can be
exposed as read-only data structures in mod_wasm as an optional API for
power httpd users that like the sandboxed functionality you get OOTB, that
would justify a lot of the more conservative concerns that some devs have
for not putting incorporating this into the trunk codebase, which would be
my recommendation at that point for how to get it into a releasable tree at
some point.


On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
wrote:

> I think not making WASM a first class concern in a proxy or server is
> missing out, more so in those platforms where extensibility isn't trivial.
> Apache will remain running in current setups but having limited
> extensibility is something concerning these days as systems are getting
> more and more complex. Writing an apache module isn't something you do
> every day and it probably takes quite some time, writing a wasm app
> following certain ABI is something you can do in minutes, hence supporting
> mod_wasm as a first class concern could be a good point in the
> sustainability of an ecosystem when it comes to moving forward out of the
> status quo.
>
> On 2022/11/14 06:37:34 Jesús González wrote:
> > Hi everyone,
> >
> >
> >
> > I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<
> https://wasmlabs.dev/>, a group focused on creating open source tools for
> WebAssembly.
> >
> > We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would love to get your feedback and
> understand what improvements would be needed (if any) before it could be
> considered for contribution to the project.
> >
> >
> >
> >
> >
> > The details:
> >
> >
> >
> > WebAssembly (Wasm) is a new binary
> instruction format that is open, portable, efficient, secure, and polyglot.
> It originated in the browser but is increasingly used in server
> applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based
> plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
> >
> >
> >
> > mod_wasm is a way to run WebAssembly modules inside Apache Server. This
> is similar to how mod_php embeds a PHP runtime to run PHP code. This
> enables any language that supports WebAssembly (including C++, Rust, Go but
> also Python, PHP, Ruby) to run with mod_wasm and take advantage of the
> extra level of security and sandboxing. To learn more about mod_wasm you
> can check out the following resources:
> >
> >   *   An overview article
> for the original release.
> >   *   We presented mod_wasm at ApacheCon this year and here are the
> slides<
> https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf>
> and the source code: https://github.com/vmware-labs/mod_wasm.
> >   *   CNCF Talk on mod_wasm showcasing how to run WordPress:
> https://www.youtube.com/watch?v=jXe8kulUscQ
> >
> >
> >
> > In terms of mod_wasm architecture, the module is split into two parts:
> >
> >   *   mod_wasm.so is the extension module for Apache and it’s written in
> C.
> >   *   An external dependency: libwasm_runtime.so, which is written in
> Rust and needs to be installed into the system.
> >
> >
> >
> > We modelled this after mod_tls, a module that is part of httpd and also
> has a Rust dependency.
> >
> > You can take a look at the architecture diagram and instructions on how
> to build the module here:
> https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
> >
> >
> >
> > In terms of the actual contribution, please find a patch attached. We
> tried to follow all existing conventions in terms of autoconf/automake,
> providing module documentation, etc. Please let us know anything that you
> see missing or could be improved. In particular, we do not know yet if it
> is better to keep the Rust code separate, as an external dependency (like
> mod_tls does) or in the Apache source code repository.
> >
> >
> >
> > In summary, we believe mod_wasm is a worthy addition to httpd and it
> will allow us to catch up to some of the other web servers already
> supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim
> Jagielski and Jean-Frederic Clere to submit it for contribution upstream
> and we are looking forward to your feedback.
> >
> >
> >
> > Cheers!
> >
> > Jesús
> >
> >
> >
> >
> >
>

Re: Apache2 chroot problem: towards a solution

[Joe Schaefer]

Awesome that Ubuntu package managers are moonlighting as open source
developer perfectionists instead of working with upstream projects on
issues.

On Thu, May 18, 2023 at 12:47 AM Benjamin Godfrey <
mr.benjamingodf...@gmail.com> wrote:

> Hi, I'm working on the problem of Apache2 ignoring requests to any command
> in the chroot environment.  I have seen complaints about this posted on a
> couple of websites, and I have not seen any solution.   I seem to have
> narrowed the problem down to a relatively small section of the code, but I
> have gotten ambiguous information on how to resolve the issue.
>
> Initially, this problem comes across as a classic system
> compatibility issue, but this it turns out is not the case.   The solution
> seems to be fairly easily solved, but either the Apache2 code would require
> a slight modification, or a module would need to be written, if there isn't
> a module that already solves the problem, that unlocks the Apache for Linux
> users.
>
>
> The errors follow the system information:
>
> Distributor ID: Ubuntu
> Description:Ubuntu 20.04.6 LTS
> Release:20.04
> Codename:   focal
>
> Server version: Apache/2.4.41 (Ubuntu)
>
>
> These are five typical errors:
>
>
> systemctl status
> System has not been booted with systemd as init system (PID 1). Can't
> operate.
> Failed to connect to bus: Host is down
>
>
> sudo systemctl start apache2
> Running in chroot, ignoring request: start
>
>
> sudo apachectl start
> Invoking 'systemctl start apache2'.
> Use 'systemctl status apache2' for more info.
> Running in chroot, ignoring request: start
>
>
> sudo service apache2 restart
>  * Restarting Apache httpd web server apache2
>
>  Invoking 'systemctl start apache2'.
> Use 'systemctl status apache2' for more info.
> Running in chroot, ignoring request: start
>
>
> sudo systemctl status apache2
> Running in chroot, ignoring request: status
>
>
>
> The irony is that the error message is stalling development on important
> issues like the eventual migration to systemd while the text of the message
> seems to point to the cause of the error as related to the systemd  boot
> process not being completed in the chroot.  This isn't the case.  The
> errors are caused by the following code in Apache2:
>
> if (ap_is_in_chroot()) {
>
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, APLOG_NOERRNO,
>
>  "Running in chroot, ignoring request: start");
>
> return APR_SUCCESS;
>
> }
> This code begs the question, why is Apache2 even checking that the "ap" is
> running in a chroot?  It must be understood that using a chroot environment
> is a useful security measure, and checking ap_is_in_chroot in this context
> is limiting the usefulness of Apache for a number of users.
>
> Further information varies, as I haven't been able to locate this segment
> in the code.  I have heard it is in the ap_run_mpm() function,  and in the
> server/mpm/common/main.c file
>
> Other information, of which I am skeptical reports:
>
>The ap_is_in_chroot() function is not a public function. It is an
> internal function that is used by the Apache source code. As such, it is
> not included in the public release of the Apache source code.
>
> I am not sure if there could be a module that would solve this issue, and
> I'm not sure if something like:
>
> if [ -n "$AP_CHROOT_DIR" ]; then
>
>   unset AP_CHROOT_DIR
>
> Fi
> Would be enough to solve the issue?
>
> Benjamin Godfrey
>
>
> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: [VOTE] Switch read/write repository from Subversion to Git

[Joe Schaefer]

I wish more Apache projects reach maintenance mode as part of their maturity 
model.  It’s good to complete your mission instead of always digging deeper 
holes.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Greg Stein 
Sent: Wednesday, May 10, 2023 2:59:24 PM
To: Stefan Sperling 
Cc: dev@httpd.apache.org 
Subject: Re: [VOTE] Switch read/write repository from Subversion to Git

On Wed, May 10, 2023 at 5:18 AM Stefan Sperling 
mailto:s...@apache.org>> wrote:
>...
I did have some hope that we would see individual self-motivated contributors
arriving via various ASF projects because they are all using SVN every day
on svn.apache.org<http://svn.apache.org>, are programmers, might have itches to 
scratch, already have
commit access to ^/subversion, and there is some sense of shared ownership
across the ASF community. I was reminded of all this by Graham's remark.
It's the lack of such interactions that I find disappointing in retrospect.
There certainly have been some, but relatively few.

IMO, it is because Subversion is successful.

It just works. Zero friction. It doesn't cause developers a headache or an 
"itch to scratch".

One doesn't think to improve their dishwasher. It just works. Why change your 
hammer? It works.

I believe that Subversion hit its goal, and then some. I believe that is why 
the *use* of Subversion did not lead to a desire to work/fix/change Subversion.

Cheers,
-g

Re: [VOTE] Switch read/write repository from Subversion to Git

[Joe Orton]

On Thu, May 04, 2023 at 10:34:32AM +0200, Ruediger Pluem wrote:
> This is a formal vote on whether we should move our read/write repository 
> from Subversion to Git.
> This means that our latest read/write repository will be no longer available 
> via svn.apache.org. It
> will be available via Git at 
> https://gitbox.apache.org/repos/asf/httpd-site.git and 
> https://github.com/apache/httpd.git.
> Github also offers the possibility to use a Subversion client:
> https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients
> 
> 
> [X]: Move the read/write repository from Subversion to Git and leverage the 
> features of Github (for now Actions and PR).
> [ ]: Move the read/write repository from Subversion to Git, but I don't want 
> to work with Github and I will only work with
>  what gitbox.apache.org offers.
> [ ]: Leave everything as is.

Thanks for calling the vote again.

Regards, Joe

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

[Joe Orton]

On Wed, May 03, 2023 at 02:31:35PM -0500, Daniel Gruno wrote:
> I am +1 on moving. I do not have any particular love for git or svn on their
> own, and I realize that the proposed change does make outside contributions
> and certain workflows easier.

+1 for the same reasons here. Might be better to call a formal VOTE 
thread on this with a clearer Subject.

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

[Joe Schaefer]

Get over the heartache and brand loyalty and get on rw git.  Github isn't
the only game in town anymore for git hosting, so don't feel trapped by
infra just because it's all they've got in the tank.

On Tue, Apr 25, 2023 at 2:07 PM Eric Covener  wrote:

> On Tue, Apr 25, 2023 at 2:45 AM Ruediger Pluem  wrote:
> >
> >
> >
> > On 4/12/23 2:02 PM, Yann Ylavic wrote:
> > > On Wed, Apr 12, 2023 at 1:31 PM Eric Covener 
> wrote:
> > >>
> > >> On Wed, Apr 12, 2023 at 6:36 AM Yann Ylavic 
> wrote:
> > >>>
> > >>> On Wed, Apr 12, 2023 at 12:26 PM Yann Ylavic 
> wrote:
> > 
> >  On Wed, Apr 12, 2023 at 12:18 PM ylavic 
> wrote:
> > >
> > > @ylavic approved this pull request.
> > >
> > > Three approvals to get ci started?
> > 
> >  Nope.. It seems that gh actions don't run for PRs whatever we do.
> >  The docs[1] say that there should be an "Approve and run" button
> near
> >  the "workflow awaiting approval" text, but it's not the case for
> httpd
> >  mirror, while approving the whole PR looks inefficient..
> > >>>
> > >>> We (PMC/committers) once had the right to close any PRs, but that
> > >>> seems to not be the case anymore either.
> > >>> Something changed since
> > >>> https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
> > >>> probably.
> > >>>
> > 
> >  Any more ideas? Help from infra needed?
> > 
> >  Regards;
> >  Yann.
> > 
> >  [1]
> https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
> > >>
> > >>
> > >> We are chatting with Daniel about it on ASF slack.
> > >
> > > Ah ok, I created https://issues.apache.org/jira/browse/INFRA-24457
> FWIW..
> > >
> >
> > I would like to bring this back here, now that we have an answer in the
> ticket.
> > The root cause for the current situation seems to be that our Github
> repository is just a read only mirror of our Subversion
> > repository. Approving PR's requires write permissions to the Github
> repository.
> >
> > As far as I understand from the ticket we have two options:
> >
> > 1. We establish a monitoring process on PR's that ensures that we detect
> misuse of Github actions by non committers.
> >Then Infra could set the PR's back to "auto-approval".
> >
> > 2. We switch from Subversion to Git and use Git as our read / write main
> repository.
> >
> > My 2 cents on the options:
> >
> > 1. I am not sure which exact monitoring will be sufficient, but it may
> put some larger burden on us to ensure that we
> >detect misuse in a timely manner. Furthermore the question to me will
> be what we can do to stop misuse quickly if we
> >detect it.
> >
> > 2. Switching from Subversion to Git is mostly an emotional problem for
> me. We have some closer ties to Subversion by some
> >overlaps in the community and via mod_dav_svn we kind of partially
> eat our very own dogfood here by using Subversion.
> >We wouldn't do that any longer with Git. Plus it would switch another
> of our development tools from an Apache license to GPL.
> >Apart from technical aspects that this change would create we should
> check if all of the current active committers are fine
> >using Github. While people could use Gitbox and thus avoid Github
> when we use Git I would like us to leverage the features of
> >Github when we would do this switch and I think this cannot be done
> if active committers would have issues with Github.
>
>
> I think r/w github is the way to go, but I know from previous threads
> there are strong feelings against it.
> Right now we seem to not be optimized for either maintainers or
> contributors, it's just inertia. I think it's bad for our image.
>

Re: svn commit: r1909135 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h server/core.c

[Joe Orton]

On Wed, Apr 19, 2023 at 08:08:49PM +0200, Yann Ylavic wrote:
> On Fri, Apr 14, 2023 at 4:02 PM  wrote:
> >
> > Author: minfrin
> > Date: Fri Apr 14 14:02:11 2023
> > New Revision: 1909135
> >
> > URL: http://svn.apache.org/viewvc?rev=1909135=rev
> > Log:
> > core: Be explicit if an enclosing directive contains a path or a
> > regex.
> 
> Currently all the tests (framework) are broken due to cmd->regex not
> being properly stacked/scoped.

Trunk has been broken for a week, Graham could you move this work to a 
branch or PR until the regressions are fixed?

Regards, Joe

Re: [VOTE] Release httpd-2.4.57-rc1 as httpd-2.4.57

[Joe Orton]

On Sun, Apr 02, 2023 at 12:10:25PM -0400, Eric Covener wrote:
> 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 httpd-2.4.57-rc1 as 2.4.57:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.

+1 for release, CHANGES looks good, sigs match, tests pass on RHEL 8+9. 
Thanks for RMing.

Regards, Joe

Re: svn commit: r1908835 - /httpd/httpd/trunk/.github/workflows/linux.yml

[Joe Orton]

On Fri, Mar 31, 2023 at 09:47:05AM +0200, Yann Ylavic wrote:
> On Fri, Mar 31, 2023 at 9:22 AM  wrote:
> >
> > Author: jorton
> > Date: Fri Mar 31 07:21:37 2023
> > New Revision: 1908835
> >
> > URL: http://svn.apache.org/viewvc?rev=1908835=rev
> > Log:
> > Try running CI for 2.* tags. [skip ci]
> 
> It seems that gh actions are not triggered anymore for trunk and
> 2.4.x, but I have no clue as to what the cause can be.
> The Last run was for r1908714 which should not have happened
> (paths-ignore: docs/**), nothing since then but PRs..
> 
> Any ideas?

Yeah I'm not sure why the CI ran for that commit, that's odd.

It looks like the github mirroring has stopped working a few days ago. 
I've created https://issues.apache.org/jira/browse/INFRA-24412

Regards, Joe

Re: svn commit: r1908684 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/cache/mod_cache_disk.c

[Joe Orton]

On Fri, Mar 24, 2023 at 08:50:19AM -, gbec...@apache.org wrote:
> Author: gbechis
> Date: Fri Mar 24 08:50:19 2023
> New Revision: 1908684
> 
> URL: http://svn.apache.org/viewvc?rev=1908684=rev
> Log:
> add error message when storing data to temp file fails.
> Github: closes #182

Hi Giovanni, thanks for taking care of the PRs, that is really great to 
see.

FYI when you are committing code written by someone else it is customary 
to include "Submitted by:" in the commit message to give them due 
credit, like:

Submitted by: Name of Person 

There are guidelines here: 
https://httpd.apache.org/dev/guidelines.html#changes-file-and-subversion-logs

If you use Ruediger's apply_trunk_pr.sh script from here: 
https://svn.apache.org/repos/asf/httpd/dev-tools/github/ 
it will do this automatically for you for a PR, including extracting the 
full name properly from the github metadata (which is really neat).

Regards, Joe

Re: svn commit: r1908537 - /httpd/httpd/trunk/modules/ssl/

[Joe Orton]

On Sun, Mar 19, 2023 at 09:30:47PM -, yla...@apache.org wrote:
> Author: ylavic
> Date: Sun Mar 19 21:30:47 2023
> New Revision: 1908537
> 
> URL: http://svn.apache.org/viewvc?rev=1908537=rev
> Log:
> mod_ssl: Fix deprecation warnings with openssl-3.

Great stuff, thank you Yann!

Re: svn commit: r1908060 - in /httpd/httpd/trunk/test/modules: http1/htdocs/cgi/ http2/ http2/htdocs/cgi/ md/ tls/ tls/htdocs/a.mod-tls.test/ tls/htdocs/b.mod-tls.test/

[Joe Orton]

On Tue, Mar 07, 2023 at 09:15:59AM +0100, Stefan Eissing via dev wrote:
> 
> 
> > Am 06.03.2023 um 17:53 schrieb Joe Orton :
> > 
> > [resent to dev@]
> > 
> > On Sat, Mar 04, 2023 at 01:40:39PM -, ic...@apache.org wrote:
> >> Author: icing
> >> Date: Sat Mar  4 13:40:38 2023
> >> New Revision: 1908060
> >> 
> >> URL: http://svn.apache.org/viewvc?rev=1908060=rev
> >> Log:
> >> Test case updates related to macOS ventura changes:
> >> 
> >> - python 3.11 deprecates the `cg` module, replacing
> >>  url query and multipart form-data handling with new code
> >> - adaptions to changes in openssl/curl behaviours
> >> - all mod_tls test cases now have prefix `test_tls_` for
> >>  easier scoping.
> > 
> > This seems to be failing:
> > 
> > https://github.com/apache/httpd/actions/runs/4341851149/jobs/7581956398
> > 
> > 1) Maybe some new pypi requirement or something?  Looks like the CGI 
> > scripts are now giving 500 errors.
> 
> Yes, for the deprecated `cgi` python module, the `multipart` module
> is recommended by the PyGods to replace parts of it. I have no idea
> how that is named on ubuntu-latest.

It exists but it is prehistoric or something completely different to 
what is in pypi as "multipart" now - apt-get logs say:

Setting up python3-multipart (0.0.5-2) ...

which is not listed here: https://pypi.org/project/multipart/#history

The new error_log is:

[Tue Mar 07 09:34:12.322270 2023] [cgid:error] [pid 51124:tid 139809792149056] 
[client 127.0.0.1:34504] AH01215: stderr from 
/home/runner/work/httpd/httpd/test/gen/apache/htdocs/b.mod-tls.test/vars.py: 
AttributeError: module 'multipart' has no attribute 'parse_form_data'

maybe we should "pip install" the deps here rather than relying on 
Ubuntu packages.

> > 2) What is the path to the relevant error_log when running those tests, 
> > we can tweak the config to grab that file and upload it for easy 
> > diagnosis.
> 
> The server error log on all pytests is found in 
> test/gen/apache/logs/error_log. It is cleared on test start.

Thanks, that works at least.

Regards, Joe

Re: svn commit: r1908060 - in /httpd/httpd/trunk/test/modules: http1/htdocs/cgi/ http2/ http2/htdocs/cgi/ md/ tls/ tls/htdocs/a.mod-tls.test/ tls/htdocs/b.mod-tls.test/

[Joe Orton]

[resent to dev@]

On Sat, Mar 04, 2023 at 01:40:39PM -, ic...@apache.org wrote:
> Author: icing
> Date: Sat Mar  4 13:40:38 2023
> New Revision: 1908060
> 
> URL: http://svn.apache.org/viewvc?rev=1908060=rev
> Log:
> Test case updates related to macOS ventura changes:
> 
> - python 3.11 deprecates the `cg` module, replacing
>   url query and multipart form-data handling with new code
> - adaptions to changes in openssl/curl behaviours
> - all mod_tls test cases now have prefix `test_tls_` for
>   easier scoping.

This seems to be failing:

https://github.com/apache/httpd/actions/runs/4341851149/jobs/7581956398

1) Maybe some new pypi requirement or something?  Looks like the CGI 
scripts are now giving 500 errors.

2) What is the path to the relevant error_log when running those tests, 
we can tweak the config to grab that file and upload it for easy 
diagnosis.

Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56

[Joe Orton]

On Sun, Mar 05, 2023 at 04:31:34PM -0500, Eric Covener 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 httpd-2.4.56-rc1 as 2.4.56:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.

+1, tests pass on RHEL 8+9 (x86_64), sigs good, thanks for RMing.

Seems there is some tweak required to get Actions to work for a tag 
which I will look into.

Regards, Joe

Re: svn commit: r1907974 - in /httpd/httpd/trunk: CMakeLists.txt modules/dav/fs/config6.m4 modules/dav/fs/mod_dav_fs.c modules/dav/fs/mod_dav_fs.dsp modules/dav/fs/repos.c modules/dav/fs/repos.h modul

[Joe Orton]

On Thu, Mar 02, 2023 at 02:36:32PM -, m...@apache.org wrote:
> Author: manu
> Date: Thu Mar  2 14:36:31 2023
> New Revision: 1907974
> 
> URL: http://svn.apache.org/viewvc?rev=1907974=rev
> Log:
> Add RFC4331 quotas for mod_dav_fs

Hi Emmanuel - looks like you forgot to "svn add" the new quota.c in this 
commit.

Regards, Joe

Re: [VOTE] broader RTC exception for 2.4.x CI changes

[Joe Orton]

Thanks all, applied in r1907783.

Regards, Joe

Re: svn commit: r1907680 - /httpd/httpd/trunk/modules/dav/main/ms_wdv.c

[Joe Orton]

On Wed, Feb 15, 2023 at 02:07:14PM -, m...@apache.org wrote:
> Author: manu
> Date: Wed Feb 15 14:07:14 2023
> New Revision: 1907680
> 
> URL: http://svn.apache.org/viewvc?rev=1907680=rev
> Log:
> Fix warnings

Thanks! There are a still a couple more warnings with GCC 10 from a %s 
argument being passed a constant NULL:

https://github.com/apache/httpd/actions/runs/4184691029/jobs/7250692033#step:10:2774

In function ‘mswdv_combined_lock’,
inlined from ‘dav_mswdv_preprocessing’ at 
/home/runner/work/httpd/httpd/modules/dav/main/ms_wdv.c:693:20:
/home/runner/work/httpd/httpd/include/http_log.h:454:23: error: ‘%s’ directive 
argument is null [-Werror=format-overflow=]
  454 | #define ap_log_rerror ap_log_rerror_
/home/runner/work/httpd/httpd/modules/dav/main/ms_wdv.c:410:5: note: in 
expansion of macro ‘ap_log_rerror’
  410 | ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
  | ^
/home/runner/work/httpd/httpd/include/http_log.h:454:23: error: ‘%s’ directive 
argument is null [-Werror=format-overflow=]
  454 | #define ap_log_rerror ap_log_rerror_
/home/runner/work/httpd/httpd/modules/dav/main/ms_wdv.c:410:5: note: in 
expansion of macro ‘ap_log_rerror’
  410 | ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
  | ^
cc1: all warnings being treated as errors

[VOTE] broader RTC exception for 2.4.x CI changes

[Joe Orton]

Per my previous Travis is dead, long live GitHub actions.

I propose to broaden the RTC exception in 2.4.x/STATUS to allow CI 
config changes and scripts to be merged from trunk:

Index: STATUS
===
--- STATUS  (revision 1907679)
+++ STATUS  (working copy)
@@ -141,7 +141,7 @@
 . non-Unix, single-platform code
 . routine APLOGNO() backports
 . .gdbinit
-. Travis integration: .travis.yml and test/travis*.sh
+. CI configuration and scripts
 . mod_tls
 
 RELEASE SHOWSTOPPERS:

CI status update: Travis out, GitHub Actions in

[Joe Orton]

Support for Travis has now been dropped, so we are relying only on 
GitHub Actions for CI from today.

There are some gaps in the GHA configuration compared to what we had 
running in Travis: notably, we're currently only testing on the latest 
Ubuntu release, and nothing has been ported back to 2.4.x yet. I will 
propose a vote separately for the 2.4.x RTC exception to extend to CI 
configuration. 

On the positive side, the GHA configuration is a lot more flexible, and 
e.g. not triggering CI on docs changes was a simple change. Any help 
filling remaining gaps would be very welcome, there is a TODO list in 
test/README.ci.

Another significant change is that GHA is configured to require approval 
on PRs from non-committers - currently only for the first PR filed, but 
from March 19th the ASF default will switch to requiring approval for 
every PR filed by a non-contributor. I don't think this is a big deal 
but will require committers to actively review and hit "approve" on each 
such PR to get it tested.

I'm happy to try to answer any questions about GHA, but I'm still 
learning how it works so very much a non-expert here.

Regards, Joe

Re: CPU affinity request

[Joe Schaefer]

Nice proof of concept, but the code needs a serious porting effort to non-Linux 
platforms as well, and they’re all quirky in their own ways about this 
featureset.

Doable tho.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Martin Ma 
Sent: Thursday, February 2, 2023 4:49:33 AM
To: dev@httpd.apache.org 
Subject: CPU affinity request


Hi All,

During httpd performance evaluation in Alibaba Cloud instance, I found httpd 
performance improved significantly after using “taskset” to set CPU affinity 
for httpd processes/threads, because it decreased the amount of CPU migrations. 
Performance improved 60% in arm instance g8y.2xlarge(8 vcpus, 32GiB memory, 
40GB ESSD), also improved 20% in x86 instance g7.2xlarge(8 vcpus, 32GiB memory, 
40GB ESSD). Test case: run httpd with event mode on g8y.2xlarge or g7.2xlarge, 
run traffic generator/benchmark 'wrk' on g8y.4xlarge(16 vcpus, 32GiB memory, 
40GB ESSD), wrk command is 'wrk -t 32 -c 1000 -d 30 --latency 
http://$ServerIP<http://%24serverip/>'

mpm event parameters:

StartServers  8
ServerLimit 100
ThreadLimit2000
MinSpareThreads  75
MaxSpareThreads2000
ThreadsPerChild 125
MaxRequestWorkers  2000


But httpd didn't have related parameters to support CPU affinity, so I used 
"taskset" to optimize.

After source code analysis, I made a prototype for the affinity solution(add 
set_affinity function when worker/lister thread created). We can observe the 
same improvement by this solution. However, this prototype only applied the 
above special “event mpm” configuration for 8 cores server. I think it also 
needs to modify the current mechanism to dynamically adapt to the perceived 
load and add new parameters for the affinity setting.

I had created a ticket on bugzilla, and Christophe JAILLET suggested discussing 
it in the dev mail list. I am not the developer on httpd, hope experts can 
evaluate this request and add cpu affinity function in future versions. Any 
commnet, please let me know.

bugzilla ticket link: https://bz.apache.org/bugzilla/show_bug.cgi?id=66424

Prototype patch(based on version 2.4.37) as below:

diff --git a/server/mpm/event/event.c b/server/mpm/event/event.c
index ffe8a23cbd..d23d115fff 100644
--- a/server/mpm/event/event.c
+++ b/server/mpm/event/event.c
@@ -1586,6 +1586,8 @@ static void * APR_THREAD_FUNC 
listener_thread(apr_thread_t * thd, void *dummy)
 int have_idle_worker = 0;
 apr_time_t last_log;

+ap_setaffinity(process_slot);
+
 last_log = apr_time_now();
 free(ti);

@@ -1998,6 +2000,8 @@ static void *APR_THREAD_FUNC worker_thread(apr_thread_t * 
thd, void *dummy)
 apr_status_t rv;
 int is_idle = 0;

+ap_setaffinity(process_slot);
+
 free(ti);

 ap_scoreboard_image->servers[process_slot][thread_slot].pid = ap_my_pid;
@@ -2456,6 +2460,8 @@ static void child_main(int child_num_arg, int 
child_bucket)
 apr_thread_t *start_thread_id;
 int i;

+ap_setaffinity(process_slot);
+
 /* for benefit of any hooks that run as this child initializes */
 retained->mpm->mpm_state = AP_MPMQ_STARTING;

@@ -3862,6 +3868,17 @@ static const char *set_worker_factor(cmd_parms * cmd, 
void *dummy,
 return NULL;
 }

+void ap_setaffinity(int cpu_affinity)
+{
+cpu_set_t mask;
+
+CPU_ZERO();
+CPU_SET(cpu_affinity, );
+
+sched_setaffinity(0, sizeof(cpu_set_t), );
+
+printf("set thread_id=%d CPU affinity to Core %d\n", gettid(), 
cpu_affinity);
+}

 static const command_rec event_cmds[] = {
 LISTEN_COMMANDS,

--
Thanks & Best Regards
Martin Ma

Re: Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Part of the really cool things you'd like to have as an app-server author
that knows the APR/APU/HTTPd runtime are subrequests, including the
portions that interact with the filter API.
I'm always writing home-grown app-specific SSI-ish filters via mod_perl to
process application pages as event-driven streams.  It will be interesting
to compare mod_wasm with mod_perl2
in terms of security / sandbox models and weigh them against other
nonfunctional features (memory, latency, CPU, etc).


On Fri, Jan 27, 2023 at 12:28 PM Jesús González  wrote:

> Hi Eric,
>
> Thanks for the feedback. Though Wasm is relatively new it is being adopted
> by other HTTP-related projects, like NGINX and Envoy proxy and even ASF
> projects like APISIX. We want to contribute upstream to bring some of these
> new features to the Apache web server, similarly to how we are working to
> contribute our changes to other projects upstream (SQLite, PHP). We plan to
> continue to development and maintenance regardless of future VMware
> involvement. In fact, the reason we started this project was because our
> manager Daniel Lopez was an early ASF member and he looks at this as a way
> to contribute back to the community. We are initially targeting support for
> regular web apps such as WordPress, but we plan for mod_wasm to enable
> safely extending Apache's own functionality, providing access to the module
> API from Wasm code.
>
> On 2023/01/24 20:36:44 Eric Covener wrote:
> > > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
> >
> > As a pessimistic PMC member not caring about WASM or these languages,
> > I worry that marrying the lifecycle together is not advantageous for
> > either side. Of course I worry about being stuck with the pieces when
> > employer interest wanes or after turnover. It does not seem like it's
> > strictly necessary to be part of the server distribution (there are
> > many examples of successful out-of-tree modules).
> >
> > However the above is no veto.
> >
>

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Looking over the WASM Roadmap, it appears that they have a plan for
multithreading within a single target language.  That would allow you to
fully support every silly GIL-addled language runtime out there, which
would be very compelling.

On Fri, Jan 27, 2023 at 1:33 PM Joe Schaefer  wrote:

> A native interface outside of CGI compat for apreq would be a killer new
> feature, because it really finishes our vision for apreq as the
> one-HTML-spec-parser for all native apps, regardless of language choice. Of
> course this would be a new opt-in feature for target languages to take
> advantage of, but it will really set apart the speed freaks in your
> userbase.
>
>

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

A native interface outside of CGI compat for apreq would be a killer new
feature, because it really finishes our vision for apreq as the
one-HTML-spec-parser for all native apps, regardless of language choice. Of
course this would be a new opt-in feature for target languages to take
advantage of, but it will really set apart the speed freaks in your
userbase.

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Still, the idea is wicked cool if mod_wasm really can isolate the Python,
PHP, etc targets onto individual POSIX threads.

Very exciting stuff for HTTP/2 Webapps.

On Wed, Jan 25, 2023 at 4:31 AM Joe Schaefer  wrote:

> Looked at the PR- the IO is pretty primitive (no streaming anywhere).
> Probably not fatal for Webapps, but it could use some better relations with
> the filter stack and bucket brigades.
>
> Joe Schaefer, Ph.D
> 
> +1 (954) 253-3732
> SunStar Systems, Inc.
> *Orion - The Enterprise Jamstack Wiki*
>
> ------
> *From:* Joe Schaefer 
> *Sent:* Tuesday, January 24, 2023 4:06:13 PM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
> Would be great to marry it to apreq, too.
>
> On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer  wrote:
>
> It is impossible to run mod_h2 without it or similar.
>
> On Tue, Jan 24, 2023 at 3:37 PM Eric Covener  wrote:
>
> > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
>
> As a pessimistic PMC member not caring about WASM or these languages,
> I worry that marrying the lifecycle together is not advantageous for
> either side. Of course I worry about being stuck with the pieces when
> employer interest wanes or after turnover.  It does not seem like it's
> strictly necessary to be part of the server distribution (there are
> many examples of successful out-of-tree modules).
>
> However the above is no veto.
>
> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Looked at the PR- the IO is pretty primitive (no streaming anywhere).  Probably 
not fatal for Webapps, but it could use some better relations with the filter 
stack and bucket brigades.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Joe Schaefer 
Sent: Tuesday, January 24, 2023 4:06:13 PM
To: dev@httpd.apache.org 
Subject: Re: mod_wasm: Contributing Upstream to Apache

Would be great to marry it to apreq, too.

On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:
It is impossible to run mod_h2 without it or similar.

On Tue, Jan 24, 2023 at 3:37 PM Eric Covener 
mailto:cove...@gmail.com>> wrote:
> We are still very interested in contributing this module upstream and helping 
> to maintain it. Please, let us know what improvements or changes would be 
> needed for it to be considered ready for inclusion.

As a pessimistic PMC member not caring about WASM or these languages,
I worry that marrying the lifecycle together is not advantageous for
either side. Of course I worry about being stuck with the pieces when
employer interest wanes or after turnover.  It does not seem like it's
strictly necessary to be part of the server distribution (there are
many examples of successful out-of-tree modules).

However the above is no veto.

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

Would be great to marry it to apreq, too.

On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer  wrote:

> It is impossible to run mod_h2 without it or similar.
>
> On Tue, Jan 24, 2023 at 3:37 PM Eric Covener  wrote:
>
>> > We are still very interested in contributing this module upstream and
>> helping to maintain it. Please, let us know what improvements or changes
>> would be needed for it to be considered ready for inclusion.
>>
>> As a pessimistic PMC member not caring about WASM or these languages,
>> I worry that marrying the lifecycle together is not advantageous for
>> either side. Of course I worry about being stuck with the pieces when
>> employer interest wanes or after turnover.  It does not seem like it's
>> strictly necessary to be part of the server distribution (there are
>> many examples of successful out-of-tree modules).
>>
>> However the above is no veto.
>>
>

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

It is impossible to run mod_h2 without it or similar.

On Tue, Jan 24, 2023 at 3:37 PM Eric Covener  wrote:

> > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
>
> As a pessimistic PMC member not caring about WASM or these languages,
> I worry that marrying the lifecycle together is not advantageous for
> either side. Of course I worry about being stuck with the pieces when
> employer interest wanes or after turnover.  It does not seem like it's
> strictly necessary to be part of the server distribution (there are
> many examples of successful out-of-tree modules).
>
> However the above is no veto.
>

Re: [VOTE] Release httpd-2.4.55-rc1 as httpd-2.4.55

[Joe Orton]

On Tue, Jan 10, 2023 at 10:21:55AM -0500, Eric Covener wrote:
> On Tue, Jan 10, 2023 at 10:17 AM Giovanni Bechis  wrote:
...
> > In file included from /usr/include/openssl/asn1.h:27,
> >  from /usr/include/openssl/rsa.h:21,
> >  from ab.c:169:
> > /usr/include/openssl/bio.h:279:28: note: declared here
> >   279 | OSSL_DEPRECATEDIN_3_0 void BIO_set_callback(BIO *b, BIO_callback_fn 
> > callback);
> >   |^~~~
> > cc1: all warnings being treated as errors
> > -
> >
> > Is this considered a blocker ?
> > This can be workarounded by building with different "-Werror" options.
> >  Giovanni
> 
> I think it's a known issue in ab.c and openssl 3.0
> I think no regression, no veto -- but everyones vote (beyond veto) is
> their own. AFAIK it has been there since 3.0 toleration was added.

Yup - there are many more deprecation warnings in mod_ssl itself too 
when building against OpenSSL 3.x. Some of them are worthwhile fixing 
but IIRC some looked quite involved to fix.

> I was going to send an email on this one, reminded by the recent
> Actions CI activity.  I think we could drop the -wno-error-deprecated
> from CI if ab.c was either fixed or maybe had something in its build
> to set this itself. That way deprecated stuff sneaking in elsewhere
> would not be supresed in maintainer mode.

Adding -Wno-deprecated-declarations or -Wno-error-etc is probably a good 
idea for all OpenSSL 3 builds, yeah.

Regards, Joe

Re: [VOTE] Release httpd-2.4.55-rc1 as httpd-2.4.55

[Joe Orton]

On Tue, Jan 10, 2023 at 08:40:52AM -0500, Eric Covener 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 httpd-2.4.55-rc1 as 2.4.55:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha256: 5276ea8bc6fff31eed5c82132ae51a0b2ee05f9e6b61a00fa877f6cadab3b638
> *httpd-2.4.55-rc1.tar.gz
> sha512: 
> ca0d03b5e74078977378fe711ca3ed8cf63c109b7dbe73f2c43f7f30f7e522bbe46f93189a183b7675394d57fffb0c2526facd8d40508be984a7a8f64d18f8d6
> *httpd-2.4.55-rc1.tar.gz

+1 for release, thank you for RMing!

Test suite passes on RHEL 8 and 9 (x86_64).

Regards, Joe

Re: svn commit: r1906487 - /httpd/httpd/trunk/modules/dav/main/util.c

[Joe Orton]

On Tue, Jan 10, 2023 at 07:30:37AM +0100, Ruediger Pluem wrote:
> On 1/9/23 5:16 PM, Joe Orton wrote:
> > It seems consistent with other error cases to return straight away, but 
> > I'm not following the second part, can you explain more?  An 'N' 
> > followed by whitespace should be caught and treated as an error now (as 
> > desired & expected).
> 
> Sorry for the confusion. It is treated as an error now. I was referring to my
> other approach were it would not be caught. I also found another case that 
> would not be
> caught by my proposal (an 'N' at the end of the string). Hence all good. Your 
> approach
> is the correct and better one.

Ah, great, thanks for looking at it! Any chance of a +1 for the 2.4 
backport? Just need one more vote :)

Regards, Joe

Re: svn commit: r1906487 - /httpd/httpd/trunk/modules/dav/main/util.c

[Joe Orton]

On Mon, Jan 09, 2023 at 04:47:33PM +0100, Ruediger Pluem wrote:
> On 1/9/23 1:01 PM, jor...@apache.org wrote:
> > Author: jorton
> > Date: Mon Jan  9 12:01:56 2023
> > New Revision: 1906487
> > 
> > URL: http://svn.apache.org/viewvc?rev=1906487=rev
> > Log:
> > * modules/dav/main/util.c (dav_process_if_header): Fix error
> >   path for "Not" prefix parsing.
> > 
> > Modified:
> > httpd/httpd/trunk/modules/dav/main/util.c
> > 
> > Modified: httpd/httpd/trunk/modules/dav/main/util.c
> > URL: 
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/util.c?rev=1906487=1906486=1906487=diff
> > ==
> > --- httpd/httpd/trunk/modules/dav/main/util.c (original)
> > +++ httpd/httpd/trunk/modules/dav/main/util.c Mon Jan  9 12:01:56 2023
> > @@ -801,8 +801,14 @@ static dav_error * dav_process_if_header
> >   "for the same state.");
> >  }
> >  condition = DAV_IF_COND_NOT;
> > +list += 2;
> > +}
> > +else {
> > +return dav_new_error(r->pool, HTTP_BAD_REQUEST,
> > + DAV_ERR_IF_UNK_CHAR, 0,
> > + "Invalid \"If:\" header: "
> > + "Unexpected character in 
> > List");
> 
> Do we want to return here to save cycles or do we do another cycle in 
> the while loop and reuse the error message from 'default:' and thus 
> also ignore single 'N' s that are followed by a ' \t<['?

It seems consistent with other error cases to return straight away, but 
I'm not following the second part, can you explain more?  An 'N' 
followed by whitespace should be caught and treated as an error now (as 
desired & expected).

Regards, Joe

Re: CVE-2022-22728: libapreq2: libapreq2 multipart form parse memory corruption

[Joe Schaefer]

2.17 is a dud.  What’s in trunk works fine though.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: enge...@gsuite.cloud.apache.org  on 
behalf of Apache Security Team 
Sent: Monday, January 2, 2023 7:30:43 AM
To: dev@httpd.apache.org 
Cc: Apache Security Team 
Subject: Re: CVE-2022-22728: libapreq2: libapreq2 multipart form parse memory 
corruption

Hi,

I noticed there was some confusion online as to whether this issue is
fixed in 2.17 (https://www.openwall.com/lists/oss-security/2022/08/26/4).

Unless anyone objects I'll amend the CVE text to make it explicit that
users are recommended to update to 2.17 or later.

Luckily with the new CVE format the version ranges are more explicit,
so this kind of confusion is less likely to occur again.


Kind regards,

Arnout

On Thu, Aug 25, 2022 at 4:09 PM Joe Orton  wrote:
>
> Severity: important
>
> Description:
>
> A flaw in libapreq2 versions 2.16 and earlier could cause a buffer overflow 
> while processing multipart form uploads.  A remote attacker could send a 
> request causing a process crash which could lead to a denial of service 
> attack.
>

Re: MS-WDV (was Re: Help with buckets)

[Joe Orton]

On Fri, Dec 02, 2022 at 08:53:07AM +, Emmanuel Dreyfus wrote:
> Hello
> 
> I made some progress with the combined GET+PROPFIND specified
> by MS-WDV (for a summary, see
> https://lists.apache.org/thread/57s1vvl6k9qpdv5ym7mtcl29bd933w7k )
> 
> Attached is the diff against trunk, form comments.

Hi Emmanuel,

That's a very weird protocol design, wow. Have you tested this with a 
long PROPFIND response? It needs to buffer the entire response in the 
output brigade to work out the length in the "multipart" prefix, but 
mod_dav will flush output brigades down the filter chain regularly 
during the multistatus response processing.

I think this might need to do something more complex, maybe running the 
PROPFIND in a subrequest properly and capturing (buffering) the output 
in a custom filter, rather than using the mod_dav internal API directly. 
Have you tried using ap_sub_req_method_uri()? Not sure this has been 
tried before with mod_dav so might well be something I'm missing.

Regards, Joe

Re: mod_wasm: Contributing Upstream to Apache

[Joe Schaefer]

vel of security and sandboxing. To learn more about mod_wasm you can
> check out the following resources:
>
>- An overview article
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwasmlabs.dev%2Farticles%2Fapache-mod-wasm%2F=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=d2MpWnkiKJA4fDOUdNghYPg0p4fMsGTeGiFR6kfcwyg%3D=0>
> for the original release.
>- We presented mod_wasm at ApacheCon this year and here are the slides
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapachecon.com%2Facna2022%2Fslides%2F01_Gonz%25C3%25A1lez_mod-wasm_Bringing_WebAssembly.pdf=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=c9U4xL6091Lei7hPlQ83PP6naUCI0SMIxmW0qvRJCq4%3D=0>
> and the source code: https://github.com/vmware-labs/mod_wasm
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvmware-labs%2Fmod_wasm=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=5oF9oB7rTpJZfUyECkvOfSnEkdaRT1UhIgOIVBD%2F9fs%3D=0>
>.
>- CNCF Talk on mod_wasm showcasing how to run WordPress:
>https://www.youtube.com/watch?v=jXe8kulUscQ
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DjXe8kulUscQ=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=GTh0dro4fqACMKnluAvXITVQFNOUL1BEiijKuSgdVkA%3D=0>
>
>
>
> In terms of mod_wasm architecture, the module is split into two parts:
>
>- *mod_wasm.so* is the extension module for Apache and it’s written in
>C.
>- An external dependency: *libwasm_runtime.so*, which is written in
>Rust and needs to be installed into the system.
>
>
>
> We modelled this after mod_tls, a module that is part of httpd and also
> has a Rust dependency.
>
> You can take a look at the architecture diagram and instructions on how to
> build the module here:
> https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvmware-labs%2Fmod_wasm%23%25EF%25B8%258F-building-mod_wasm=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=riwxB9vHMxT%2ByvYzGUXBXtgqMi%2B9%2BRVb1zUZSaTxTHE%3D=0>
>
>
>
> In terms of the actual contribution, please find a patch attached. We
> tried to follow all existing conventions in terms of autoconf/automake,
> providing module documentation, etc. Please let us know anything that you
> see missing or could be improved. In particular, we do not know yet if it
> is better to keep the Rust code separate, as an external dependency (like
> mod_tls does) or in the Apache source code repository.
>
>
>
> In summary, we believe mod_wasm is a worthy addition to httpd and it will
> allow us to catch up to some of the other web servers already supporting
> Wasm, like NGINX. We were encouraged by Rich Bowen, Jim Jagielski and
> Jean-Frederic Clere to submit it for contribution upstream and we are
> looking forward to your feedback.
>
>
>
> Cheers!
>
> Jesús
>
>
>
>
>
-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

New committer: Emmanuel Dreyfus

[Joe Orton]

The Project Management Committee (PMC) for the Apache HTTP Server has 
invited Emmanuel Dreyfus to become a committer and we are pleased to 
announce that they have accepted.

Welcome, Emmanuel!

Regards, Joe

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Last patch: this one includes autoconf/automake repairs as well.

On Fri, Nov 4, 2022 at 9:02 PM Joe Schaefer  wrote:

> Sometime before end of year, perhaps I can upgrade apreq's autotool deps
> to something Ubuntu 22 can handle,
> for the purpose of dockerizing a build environment for the self-contained
> test suite in library/t.  Getting automated builds that run those
> tests, at least periodically, will make a substantial difference in the
> quality of the development effort for apreq, even in httpd's trunk.
>
> On Fri, Nov 4, 2022 at 3:40 PM Joe Schaefer  wrote:
>
>> One of these tests actually reported a problem with the "whimsical" patch
>> under consideration, Yann.
>> But instead of confronting you about it, Joe O just removed that test
>> from the suite prior to release.
>>
>> This is the very last time I expect to say something critical about
>> 2.17.  Let's make it the last time I say
>> something critical about the team effort into producing any rapreq elease
>> going forward.  You guys know better,
>> and all I ask is that you keep your own standards intact for apreq
>> (without adding any formal process to ensure it).
>> In the end, we're all volunteers- but don't dismiss the work of your
>> predecessors so quickly in the future.
>>
>>
>> On Fri, Nov 4, 2022 at 2:01 PM  wrote:
>>
>>> There's literally over 1M tests in library/t/parsers.c; all of them are
>>> trivial to adjust to taste.
>>> Going forward, if you want to establish different types of parser
>>> behaviors, positively document those behaviors in the test suite, just like
>>> your predecessors did.
>>> Let's not make what happened with 2.17 a new status quo for your efforts.
>>>
>>> -Original Message-
>>> From: Yann Ylavic 
>>> Sent: Wednesday, November 2, 2022 9:47 AM
>>> To: dev@httpd.apache.org
>>> Cc: Joe Schaefer 
>>> Subject: Re: [libapreq2] nits to pick about the patches to util.c over
>>> the past few years
>>>
>>> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
>>> >
>>> > The reason this took so long for the community to diagnose isn't
>>> > because of ill-intent, but because it constituted a change of behavior
>>> in the parser logic that wasn't surfaced in the Changes file.
>>>
>>> Please review r1905018 (with a CHANGES entry this time), along with
>>> r1905019 and r1905020 eventually.
>>> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
>>> filter/mark subjects with "/httpd/apreq" if you don't want to miss anything.
>>>
>>> >
>>> > There is never going to come a time when there is any need for urgent
>>> > action on apreq- if it was easy to zero-day it, it would have happened
>>> > by now.  Thus, take as much time as you need between releases to
>>> > communicate with the community about the nature of the deltas you
>>> intend to ship with any GA release.  You have my email address if you need
>>> to spitball any patchsets you are toying with; it's a lot less painful to
>>> get my input in advance than after the fact.
>>>
>>> That's not how it usually works though: r1895107 is dated "Nov 17,
>>> 2021", the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25, which
>>> left you 8 months to review the changes in trunk (and chime in..).
>>>
>>>
>>> Regards;
>>> Yann.
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 
Index: configure.ac
===
--- configure.ac(revision 1905068)
+++ configure.ac(working copy)
@@ -1,7 +1,7 @@
 dnl Process this file with autoconf to produce a configure script.
 
-AC_PREREQ(2.53)
-AC_INIT(Apache HTTP Server Request Library, 2.18, apreq-...@httpd.apache.org, 
libapreq2)
+AC_PREREQ([2.71])
+AC_INIT([Apache HTTP Server Request 
Library],[2.18],[apreq-...@httpd.apache.org],[libapreq2])
 dnl Generate config.nice script- macro must be here at the top
 dnl to avoid corruption of $0 and $@.
 APR_CONFIG_NICE(config.nice)
@@ -19,7 +19,7 @@
 
 dnl Checks for programs.
 AC_PROG_CC
-AM_PROG_LIBTOOL
+LT_INIT
 AC_PROG_RANLIB
 AC_PROG_INSTALL
 AC_PROG_LN_S
Index: library/t/parsers.c

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Sometime before end of year, perhaps I can upgrade apreq's autotool deps to
something Ubuntu 22 can handle,
for the purpose of dockerizing a build environment for the self-contained
test suite in library/t.  Getting automated builds that run those
tests, at least periodically, will make a substantial difference in the
quality of the development effort for apreq, even in httpd's trunk.

On Fri, Nov 4, 2022 at 3:40 PM Joe Schaefer  wrote:

> One of these tests actually reported a problem with the "whimsical" patch
> under consideration, Yann.
> But instead of confronting you about it, Joe O just removed that test from
> the suite prior to release.
>
> This is the very last time I expect to say something critical about 2.17.
> Let's make it the last time I say
> something critical about the team effort into producing any rapreq elease
> going forward.  You guys know better,
> and all I ask is that you keep your own standards intact for apreq
> (without adding any formal process to ensure it).
> In the end, we're all volunteers- but don't dismiss the work of your
> predecessors so quickly in the future.
>
>
> On Fri, Nov 4, 2022 at 2:01 PM  wrote:
>
>> There's literally over 1M tests in library/t/parsers.c; all of them are
>> trivial to adjust to taste.
>> Going forward, if you want to establish different types of parser
>> behaviors, positively document those behaviors in the test suite, just like
>> your predecessors did.
>> Let's not make what happened with 2.17 a new status quo for your efforts.
>>
>> -Original Message-----
>> From: Yann Ylavic 
>> Sent: Wednesday, November 2, 2022 9:47 AM
>> To: dev@httpd.apache.org
>> Cc: Joe Schaefer 
>> Subject: Re: [libapreq2] nits to pick about the patches to util.c over
>> the past few years
>>
>> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
>> >
>> > The reason this took so long for the community to diagnose isn't
>> > because of ill-intent, but because it constituted a change of behavior
>> in the parser logic that wasn't surfaced in the Changes file.
>>
>> Please review r1905018 (with a CHANGES entry this time), along with
>> r1905019 and r1905020 eventually.
>> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
>> filter/mark subjects with "/httpd/apreq" if you don't want to miss anything.
>>
>> >
>> > There is never going to come a time when there is any need for urgent
>> > action on apreq- if it was easy to zero-day it, it would have happened
>> > by now.  Thus, take as much time as you need between releases to
>> > communicate with the community about the nature of the deltas you
>> intend to ship with any GA release.  You have my email address if you need
>> to spitball any patchsets you are toying with; it's a lot less painful to
>> get my input in advance than after the fact.
>>
>> That's not how it usually works though: r1895107 is dated "Nov 17, 2021",
>> the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25, which left
>> you 8 months to review the changes in trunk (and chime in..).
>>
>>
>> Regards;
>> Yann.
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

One of these tests actually reported a problem with the "whimsical" patch
under consideration, Yann.
But instead of confronting you about it, Joe O just removed that test from
the suite prior to release.

This is the very last time I expect to say something critical about 2.17.
Let's make it the last time I say
something critical about the team effort into producing any rapreq elease
going forward.  You guys know better,
and all I ask is that you keep your own standards intact for apreq (without
adding any formal process to ensure it).
In the end, we're all volunteers- but don't dismiss the work of your
predecessors so quickly in the future.


On Fri, Nov 4, 2022 at 2:01 PM  wrote:

> There's literally over 1M tests in library/t/parsers.c; all of them are
> trivial to adjust to taste.
> Going forward, if you want to establish different types of parser
> behaviors, positively document those behaviors in the test suite, just like
> your predecessors did.
> Let's not make what happened with 2.17 a new status quo for your efforts.
>
> -Original Message-
> From: Yann Ylavic 
> Sent: Wednesday, November 2, 2022 9:47 AM
> To: dev@httpd.apache.org
> Cc: Joe Schaefer 
> Subject: Re: [libapreq2] nits to pick about the patches to util.c over the
> past few years
>
> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer  wrote:
> >
> > The reason this took so long for the community to diagnose isn't
> > because of ill-intent, but because it constituted a change of behavior
> in the parser logic that wasn't surfaced in the Changes file.
>
> Please review r1905018 (with a CHANGES entry this time), along with
> r1905019 and r1905020 eventually.
> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
> filter/mark subjects with "/httpd/apreq" if you don't want to miss anything.
>
> >
> > There is never going to come a time when there is any need for urgent
> > action on apreq- if it was easy to zero-day it, it would have happened
> > by now.  Thus, take as much time as you need between releases to
> > communicate with the community about the nature of the deltas you intend
> to ship with any GA release.  You have my email address if you need to
> spitball any patchsets you are toying with; it's a lot less painful to get
> my input in advance than after the fact.
>
> That's not how it usually works though: r1895107 is dated "Nov 17, 2021",
> the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25, which left
> you 8 months to review the changes in trunk (and chime in..).
>
>
> Regards;
> Yann.
>


-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732