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

[Greg Stein]

On Mon, May 8, 2023 at 9:08 AM Stefan Sperling  wrote:
>...

> If the ASF at large was confident in SVN as a technology then our current
> reality would look quite different. The Subversion project never managed
> to grow its developer base by becoming part of the ASF. We've mostly seen
>

That is simply untrue.

Case in point: WANdisco did not materially contribute to svn *until* the
project left the CollabNet umbrella. At that point, WD put several
full-time developers onto the project, and ramped up their project plans.
This is a specific *fact* directly from my conversations with the CEO, over
the phone and in-person at their offices in Sheffield. And WANdisco offered
many developers', over many years, with very significant and important
contributions.

The ASF is completely confident in svn, and basically 99% of our corporate
records, and some of our key workflows (eg. account requests, TLP
graduation, ICLA recording) is all based on Apache Subversion. Also a fact.
And zero plans to change that. Git is not envisioned to replace any of that.

Your implication that the Foundation was somehow required to grow the svn
community is misplaced. That is not its purpose. The Apache Subversion
community is responsible for growing itself. In 2011, the Board of
Directors specifically declined to assist a TLP with its community (*way*
larger than svn) because that is not the purpose of the Foundation. We do
not want some people "over there" on the Foundation/administrative side
interfering with the technical operation, and the community dynamics of one
of the communities. Or, even worse, to *pick* which communities get
assistance, while others do not. No winners. No losers. (clearly: I am
upset by your implication that you've been let down; the true answer is
missing a step on the Foundation's role)

As Daniel notes else-thread, the suggestion is not git vs. svn. It is
entirely about "Do we want the tools offered by GitHub, to be made
available to the Apache HTTPD community?"

I'm an svn partisan, but I also appreciate GitHub for its utility. I
voted +1 to move, for that reason only. Hands-down, I'd -1 a move to git.
It was only GitHub that changed my opinion on this issue.

Cheers,
-g

Re: Fwd: [apache/httpd] don't forward invalid query strings (d78a166)

[Eric Covener]

On Tue, May 9, 2023 at 3:14 PM Ruediger Pluem  wrote:
>
>
>
> On 5/9/23 8:01 PM, Eric Covener wrote:
> > On Tue, May 9, 2023 at 11:51 AM Ruediger Pluem  wrote:
> >>
> >>
> >>
> >> On 5/9/23 4:33 PM, Yann Ylavic wrote:
> >>> On Tue, May 9, 2023 at 2:10 PM Yann Ylavic  wrote:
> 
>  On Tue, May 9, 2023 at 12:55 PM Ruediger Pluem  wrote:
> >
> > On 5/9/23 12:16 PM, Eric Covener wrote:
> >> Still getting feedback in the PR about breakage. Any thoughts on 
> >> options here, like allowing spaces or encoding rather than failing?
> >
> > Allowing spaces is out of question for me as it creates an invalid 
> > request and opens the door to response splitting. At best we
> > could encode automatically. It is really a good question if we could 
> > not make BCTLS the default.
> 
>  BCTLS by default looks fine to me, it changes the behaviour for users
>  that (used to) expect/handle decoded spaces in the query-string in
>  their scripts, but it's blocked now anyway..
> >>>
> >>> Hm, actually we don't really know where the backref is placed (either
> >>> in the uri-path or in the query-string), so escaping unconditionally
>
> Good point. Hence I think the only options left are that people fix their 
> configurations or
> that we scan r->args and encode all spaces. But this leaves the question 
> open: Encode to what? '+' or %20?
> Maybe we can put this job somehow in splitout_queryargs? It would have access 
> to the RewriteRule flags and
> we could decide based on if RULEFLAG_ESCAPENOPLUS is set or not.
>
> Something along the following (partly pseudocode, not optimized):
>
> Index: modules/mappers/mod_rewrite.c
> ===
> --- modules/mappers/mod_rewrite.c   (revision 1909373)
> +++ modules/mappers/mod_rewrite.c   (working copy)
> @@ -854,6 +854,31 @@
> }
>  }
>
> +if (global_option_encode_spaces) {
> +if (flags & RULEFLAG_ESCAPENOPLUS) {
> +char *p1, p2;
> +
> +p1 = apr_palloc(r->pool, strlen(r->args) * 3 + 1);
> +for (p2 = r->args; *p2; p2++) {
> +if (*p2 == ' ') {
> +strcpy(p1, "%20");
> +p1 += 3;
> +}
> +else {
> +*p1++ = *p2;
> +}
> +}
> +*p1 = '\0';
> +}
> +else {
> +for (char *pos = r->args; *pos; pos++) {
> +if (*pos == ' ') {
> +*pos = '+';
> +}
> +}
> +}
> +}
> +
>  rewritelog(r, 3, NULL, "split uri=%s -> uri=%s, args=%s", olduri,
> r->filename, r->args ? r->args : "");
>  }
>
> >>> might lead to double-escaping in the uri-path. Maybe it's simpler to
> >>> remove the check and leave it to mod_proxy only..
> >>
> >> Do we have an example config where this currently breaks that does not 
> >> forward it to a proxy backend?
> >
> >>From some of the GH activity, I think there is some mod_proxy_fcgi
> > sending to FPM and PHP. In this case the query is in an environment
> > variable.
> >
> > Are spaces over proxy_http really that much of a smoking gun? Wouldn't
> > any smuggling/splitting/desynch already be fatal if it's in the
> > request line? It can't be terminated early if we only allow spaces.
>
> You mean if there are just spaces and no control characters? I am not sure if 
> you can do smuggling without \r and/or \n, but
> the HTTP RFC is strict about what is allowed in the request URL and literal 
> spaces are definitely not allowed.
> If we allow them we send a non RFC compliant HTTP request to the backend. I 
> think we must not do this.

I was assuming the 403s are coming from mod_rewrite, not the proxy
modules, and that we'd only change the former.   But it's not 100%
clear for the people following up in the PR.

If it's true, the proxy modules would then still return an error
before putting unencoded/decoded spaces into the query.

Call for Presentations, Community Over Code 2023

[Rich Bowen]

(Note: You are receiving this because you are subscribed to the dev@
list for one or more Apache Software Foundation projects.)

The Call for Presentations (CFP) for Community Over Code (formerly
Apachecon) 2023 is open at
https://communityovercode.org/call-for-presentations/, and will close
Thu, 13 Jul 2023 23:59:59 GMT.

The event will be held in Halifax, Canada, October 7-10, 2023.

We welcome submissions on any topic related to the Apache Software
Foundation, Apache projects, or the communities around those projects.
We are specifically looking for presentations in the following
catetegories:

Fintech
Search
Big Data, Storage
Big Data, Compute
Internet of Things
Groovy
Incubator
Community
Data Engineering
Performance Engineering
Geospatial
API/Microservices
Frameworks
Content Wrangling
Tomcat and httpd
Cloud and Runtime
Streaming
Sustainability

Re: Fwd: [apache/httpd] don't forward invalid query strings (d78a166)

[Ruediger Pluem]

On 5/9/23 8:01 PM, Eric Covener wrote:
> On Tue, May 9, 2023 at 11:51 AM Ruediger Pluem  wrote:
>>
>>
>>
>> On 5/9/23 4:33 PM, Yann Ylavic wrote:
>>> On Tue, May 9, 2023 at 2:10 PM Yann Ylavic  wrote:

 On Tue, May 9, 2023 at 12:55 PM Ruediger Pluem  wrote:
>
> On 5/9/23 12:16 PM, Eric Covener wrote:
>> Still getting feedback in the PR about breakage. Any thoughts on options 
>> here, like allowing spaces or encoding rather than failing?
>
> Allowing spaces is out of question for me as it creates an invalid 
> request and opens the door to response splitting. At best we
> could encode automatically. It is really a good question if we could not 
> make BCTLS the default.

 BCTLS by default looks fine to me, it changes the behaviour for users
 that (used to) expect/handle decoded spaces in the query-string in
 their scripts, but it's blocked now anyway..
>>>
>>> Hm, actually we don't really know where the backref is placed (either
>>> in the uri-path or in the query-string), so escaping unconditionally

Good point. Hence I think the only options left are that people fix their 
configurations or
that we scan r->args and encode all spaces. But this leaves the question open: 
Encode to what? '+' or %20?
Maybe we can put this job somehow in splitout_queryargs? It would have access 
to the RewriteRule flags and
we could decide based on if RULEFLAG_ESCAPENOPLUS is set or not.

Something along the following (partly pseudocode, not optimized):

Index: modules/mappers/mod_rewrite.c
===
--- modules/mappers/mod_rewrite.c   (revision 1909373)
+++ modules/mappers/mod_rewrite.c   (working copy)
@@ -854,6 +854,31 @@
}
 }

+if (global_option_encode_spaces) {
+if (flags & RULEFLAG_ESCAPENOPLUS) {
+char *p1, p2;
+
+p1 = apr_palloc(r->pool, strlen(r->args) * 3 + 1);
+for (p2 = r->args; *p2; p2++) {
+if (*p2 == ' ') {
+strcpy(p1, "%20");
+p1 += 3;
+}
+else {
+*p1++ = *p2;
+}
+}
+*p1 = '\0';
+}
+else {
+for (char *pos = r->args; *pos; pos++) {
+if (*pos == ' ') {
+*pos = '+';
+}
+}
+}
+}
+
 rewritelog(r, 3, NULL, "split uri=%s -> uri=%s, args=%s", olduri,
r->filename, r->args ? r->args : "");
 }

>>> might lead to double-escaping in the uri-path. Maybe it's simpler to
>>> remove the check and leave it to mod_proxy only..
>>
>> Do we have an example config where this currently breaks that does not 
>> forward it to a proxy backend?
> 
>>From some of the GH activity, I think there is some mod_proxy_fcgi
> sending to FPM and PHP. In this case the query is in an environment
> variable.
> 
> Are spaces over proxy_http really that much of a smoking gun? Wouldn't
> any smuggling/splitting/desynch already be fatal if it's in the
> request line? It can't be terminated early if we only allow spaces.

You mean if there are just spaces and no control characters? I am not sure if 
you can do smuggling without \r and/or \n, but
the HTTP RFC is strict about what is allowed in the request URL and literal 
spaces are definitely not allowed.
If we allow them we send a non RFC compliant HTTP request to the backend. I 
think we must not do this.

Regards

Rüdiger

Re: Fwd: [apache/httpd] don't forward invalid query strings (d78a166)

[Eric Covener]

On Tue, May 9, 2023 at 11:51 AM Ruediger Pluem  wrote:
>
>
>
> On 5/9/23 4:33 PM, Yann Ylavic wrote:
> > On Tue, May 9, 2023 at 2:10 PM Yann Ylavic  wrote:
> >>
> >> On Tue, May 9, 2023 at 12:55 PM Ruediger Pluem  wrote:
> >>>
> >>> On 5/9/23 12:16 PM, Eric Covener wrote:
>  Still getting feedback in the PR about breakage. Any thoughts on options 
>  here, like allowing spaces or encoding rather than failing?
> >>>
> >>> Allowing spaces is out of question for me as it creates an invalid 
> >>> request and opens the door to response splitting. At best we
> >>> could encode automatically. It is really a good question if we could not 
> >>> make BCTLS the default.
> >>
> >> BCTLS by default looks fine to me, it changes the behaviour for users
> >> that (used to) expect/handle decoded spaces in the query-string in
> >> their scripts, but it's blocked now anyway..
> >
> > Hm, actually we don't really know where the backref is placed (either
> > in the uri-path or in the query-string), so escaping unconditionally
> > might lead to double-escaping in the uri-path. Maybe it's simpler to
> > remove the check and leave it to mod_proxy only..
>
> Do we have an example config where this currently breaks that does not 
> forward it to a proxy backend?

>From some of the GH activity, I think there is some mod_proxy_fcgi
sending to FPM and PHP. In this case the query is in an environment
variable.

Are spaces over proxy_http really that much of a smoking gun? Wouldn't
any smuggling/splitting/desynch already be fatal if it's in the
request line? It can't be terminated early if we only allow spaces.

Re: Fwd: [apache/httpd] don't forward invalid query strings (d78a166)

[Ruediger Pluem]

On 5/9/23 4:33 PM, Yann Ylavic wrote:
> On Tue, May 9, 2023 at 2:10 PM Yann Ylavic  wrote:
>>
>> On Tue, May 9, 2023 at 12:55 PM Ruediger Pluem  wrote:
>>>
>>> On 5/9/23 12:16 PM, Eric Covener wrote:
 Still getting feedback in the PR about breakage. Any thoughts on options 
 here, like allowing spaces or encoding rather than failing?
>>>
>>> Allowing spaces is out of question for me as it creates an invalid request 
>>> and opens the door to response splitting. At best we
>>> could encode automatically. It is really a good question if we could not 
>>> make BCTLS the default.
>>
>> BCTLS by default looks fine to me, it changes the behaviour for users
>> that (used to) expect/handle decoded spaces in the query-string in
>> their scripts, but it's blocked now anyway..
> 
> Hm, actually we don't really know where the backref is placed (either
> in the uri-path or in the query-string), so escaping unconditionally
> might lead to double-escaping in the uri-path. Maybe it's simpler to
> remove the check and leave it to mod_proxy only..

Do we have an example config where this currently breaks that does not forward 
it to a proxy backend?

Regards

Rüdiger

Re: Fwd: [apache/httpd] don't forward invalid query strings (d78a166)

[Yann Ylavic]

On Tue, May 9, 2023 at 2:10 PM Yann Ylavic  wrote:
>
> On Tue, May 9, 2023 at 12:55 PM Ruediger Pluem  wrote:
> >
> > On 5/9/23 12:16 PM, Eric Covener wrote:
> > > Still getting feedback in the PR about breakage. Any thoughts on options 
> > > here, like allowing spaces or encoding rather than failing?
> >
> > Allowing spaces is out of question for me as it creates an invalid request 
> > and opens the door to response splitting. At best we
> > could encode automatically. It is really a good question if we could not 
> > make BCTLS the default.
>
> BCTLS by default looks fine to me, it changes the behaviour for users
> that (used to) expect/handle decoded spaces in the query-string in
> their scripts, but it's blocked now anyway..

Hm, actually we don't really know where the backref is placed (either
in the uri-path or in the query-string), so escaping unconditionally
might lead to double-escaping in the uri-path. Maybe it's simpler to
remove the check and leave it to mod_proxy only..

>
>
> Regards;
> Yann.

Re: Fwd: [apache/httpd] don't forward invalid query strings (d78a166)

[Yann Ylavic]

On Tue, May 9, 2023 at 12:55 PM Ruediger Pluem  wrote:
>
> On 5/9/23 12:16 PM, Eric Covener wrote:
> > Still getting feedback in the PR about breakage. Any thoughts on options 
> > here, like allowing spaces or encoding rather than failing?
>
> Allowing spaces is out of question for me as it creates an invalid request 
> and opens the door to response splitting. At best we
> could encode automatically. It is really a good question if we could not make 
> BCTLS the default.

BCTLS by default looks fine to me, it changes the behaviour for users
that (used to) expect/handle decoded spaces in the query-string in
their scripts, but it's blocked now anyway..


Regards;
Yann.

Re: Fwd: [apache/httpd] don't forward invalid query strings (d78a166)

[Ruediger Pluem]

On 5/9/23 12:16 PM, Eric Covener wrote:
> Still getting feedback in the PR about breakage. Any thoughts on options 
> here, like allowing spaces or encoding rather than failing?

Allowing spaces is out of question for me as it creates an invalid request and 
opens the door to response splitting. At best we
could encode automatically. It is really a good question if we could not make 
BCTLS the default.


> 
> -- Forwarded message -
> From: *Ivan Zahariev*  >
> Date: Tue, May 9, 2023, 5:25 AM
> Subject: Re: [apache/httpd] don't forward invalid query strings (d78a166)
> To: apache/httpd mailto:ht...@noreply.github.com>>
> Cc: Eric Covener mailto:cove...@apache.org>>, Mention 
>  >
> 
> 
> Hi @covener . This is impacting lots of existing 
> websites already.
> 
> What is the downside if BCTLS can be enabled by default with an Apache config 
> option, and there is a new flag to disable it in
> each RewriteRule in the rare case where we need to forward a non-encoded URL?
> 
> —
> Reply to this email directly, view it on GitHub
> ,
>  or unsubscribe
> .
> You are receiving this because you were mentioned.Message ID:
> 
> 

Regards

Rüdiger

Fwd: [apache/httpd] don't forward invalid query strings (d78a166)

[Eric Covener]

Still getting feedback in the PR about breakage. Any thoughts on options
here, like allowing spaces or encoding rather than failing?

-- Forwarded message -
From: Ivan Zahariev 
Date: Tue, May 9, 2023, 5:25 AM
Subject: Re: [apache/httpd] don't forward invalid query strings (d78a166)
To: apache/httpd 
Cc: Eric Covener , Mention 


Hi @covener . This is impacting lots of
existing websites already.

What is the downside if BCTLS can be enabled by default with an Apache
config option, and there is a new flag to disable it in each RewriteRule in
the rare case where we need to forward a non-encoded URL?

—
Reply to this email directly, view it on GitHub
,
or unsubscribe

.
You are receiving this because you were mentioned.Message ID:

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

[Ruediger Pluem]

On 5/8/23 9:16 AM, Greg Stein wrote:
> I might suggest another day or two because of the weekend and because it is 
> so high-impact. Maybe an extra post to private@ in
> case some PMC members aren't tracking dev@ very closely.
> 
> 

I intend to close this vote in about 48 hours. It has been open then for a week.

Regards

Rüdiger

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

[jean-frederic clere]

On 5/4/23 10:34, Ruediger Pluem wrote:

[X]: Move the read/write repository from Subversion to Git and leverage the 
features of Github (for now Actions and PR).


--
Cheers

Jean-Frederic

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

[Ruediger Pluem]

On 5/9/23 12:00 AM, Daniel Gruno wrote:

> 
> VHS vs BetaMax anyone? :)

Video 2000 (https://en.wikipedia.org/wiki/Video_2000) rules  :-)

Regards

Rüdiger