Re: NOTICE: Intent to T late this week

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 7/22/20 19:32, Daniel Ruggeri wrote:
> Hi, all; It's been a while since we've rolled a release and gotten
> fixes/etc in our community's hands. Apologies for not suggesting
> this sooner. How about a T Friday? That will let vote run through
> the weekend.

If I clean-up my patch for
https://bz.apache.org/bugzilla/show_bug.cgi?id=64338 is there a chance
it could make it into this release?

I'm super-ignorant about the httpd release process so I apologize if
that's a ridiculous question.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8Z2BUACgkQHPApP6U8
pFiQig/9EoMU1nfImF1hwwMEkJCSmkIY9flImsMzd4yF+apeK8YS1uzA9yLGfGgw
++5FEOEBjNbpZTnQWJ5Lgc3dBIZ9l/Q9Jg5OryaX31JEOoRaTuwHvxx4KTXfJriW
lDCjmoB18N3ze2jNRfRxJuBDbYeDWbluz9lb28qZdkCGwpmUdz5PoS1oNYxu6V3h
AVccJEos0eMdKhfIuVtjcUoZ9gb9+eq4CJwNBeyMOV8tW+vY/Zf00OCy4tTvenE2
HDf+nx7AbnrpTAOJBbrvjXbpYTaWY/NbtRaCQFEGFPYPrv+4k/4tlyn4V+p6LAcQ
Ol03TqE6Q6APAq3BsvgvRUKTVzJdnxfUS6XjaePh4l+q14kF06umPHAUo4DNn0MD
o3hU0LZUpyftklxvkYALMeoNflDXzPw9pkVq+VSYwGLk0/DiqVRvIJsMacr41a/Y
9sm8OWMkK4um/HNhR4USkIhVzsEDsY+bQR1m2f8m50FDXiU+I+AD5Rg9Yt0qwWZ3
TM3FhdFsARp2l9jSucY0cQKz8WYZGGoED5ccRBzOnnKaPePQwwOAQoQcBzoU3tLk
Yre8IAuGN4TvtTp6hViLDDSdEvs6ogmmOIB5RovWE6WGnn6S60D21ySkOca5IKi6
DRaIIx11UspPKRACb8VHmjlhYejlBQ2p/8ZqPxPT+zG40ePLPW0=
=ZoLM
-END PGP SIGNATURE-

Fixed: apache/httpd#1013 (trunk - c82fb45)

[Travis CI]

Build Update for apache/httpd
-

Build: #1013
Status: Fixed

Duration: 33 mins and 42 secs
Commit: c82fb45 (trunk)
Author: Yann Ylavic
Message: Follow up to r1880205, APLOGNO().

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1880214 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/fb08e475bf32...c82fb455e3d3

View the full build log and details: 
https://travis-ci.org/github/apache/httpd/builds/711141915?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=69847_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: NOTICE: Intent to T late this week

[Yann Ylavic]

On Thu, Jul 23, 2020 at 1:32 AM Daniel Ruggeri  wrote:
>
> It's been a while since we've rolled a release and gotten fixes/etc in our 
> community's hands. Apologies for not suggesting this sooner. How about a T 
> Friday? That will let vote run through the weekend.

+1

Regards;
Yann.

Broken: apache/httpd#1012 (trunk - fb08e47)

[Travis CI]

Build Update for apache/httpd
-

Build: #1012
Status: Broken

Duration: 32 mins and 26 secs
Commit: fb08e47 (trunk)
Author: Yann Ylavic
Message: mod_proxy_uwsgi: Error out on HTTP header larger than 16K

The uwsgi protocol does not let us serialize more than 16K of HTTP header,
so fail early with 500 if it happens.



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1880205 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/ba08e0602958...fb08e475bf32

View the full build log and details: 
https://travis-ci.org/github/apache/httpd/builds/711106822?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=69847_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: NOTICE: Intent to T late this week

[Jim Jagielski]

Sure. Go ahead. +1

> On Jul 22, 2020, at 7:32 PM, Daniel Ruggeri  wrote:
> 
> Hi, all;
> It's been a while since we've rolled a release and gotten fixes/etc in our 
> community's hands. Apologies for not suggesting this sooner. How about a T 
> Friday? That will let vote run through the weekend.
> -- 
> Daniel Ruggeri

Re: svn commit: r1879401 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h mod_proxy_http.c mod_proxy_wstunnel.c proxy_util.c

[Yann Ylavic]

On Wed, Jul 22, 2020 at 9:15 PM Ruediger Pluem  wrote:
>
> Will you commit?

r1880200, wider change aiming at addressing this issue and anything
POLLERR related.

Regards;
Yann.

Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize

[jean-frederic clere]

On 21/07/2020 06:51, William A Rowe Jr wrote:



On Mon, Jul 20, 2020, 10:24 Ruediger Pluem > wrote:




On 7/20/20 4:45 PM, Yann Ylavic wrote:
 > On Thu, Jul 16, 2020 at 10:31 PM Eric Covener mailto:cove...@gmail.com>> wrote:
 >>
 >> On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem
mailto:rpl...@apache.org>> wrote:
 >>>
 >>>
 >>>
 >>> On 6/24/20 1:27 PM, Eric Covener wrote:
 >
 > ProxyMappingDecoded is not needed anymore (and was removed).
 > The mapping= tells mod_proxy at which stage ([pre_]translate) it
 > should map the request path.
  +1
 
 >>>
 >>> Getting back to an old topic. Shouldn't we have a directive
similar to
 >>> AllowEncodedSlashes that allows us to block URI's that contain
 >>> URL fragments like /.; and /..; in order to avoid that someone
plays
 >>> silly games that bypass Location settings and RewriteRules
 >>> that might be used with a servlet engine in the backend? Happy
 >>> to have that set to a default that allows /.; and /..;.
 >>
 >> +, but I'd want the safer default.
 >
 > Is this something we should care about outside the proxy
mapping=servlet case?
 > In the other cases, "/.;" and "/..;" are nothing but plain text (they
 > won't be treated as "/." and "/.." on the filesystem AFAICT), so we
 > could let them 404 normally.

I think for the default handler this is no problem. As you state
such URL's likely produce just a 404 and we are done.

 > In the mapping=servlet case, servlet normalization is applied to
 > r->[parsed_]uri (no "/.;" or "/..;" anymore), so Location/..
matchings
 > use the same uri-path than the backend.

But only if you have an appropriate ProxyPass in place. With
RewriteRules this does not work.
Hence I think we need an additional mechanism to handle this in case
of no ProxyPass directives.
I still fail to see a real use case for /..; and /.; segments. Hence
I think denying them should
be possible with a simple option without the need for a ProxyPass
directive or an additional
RewriteRule. This would also keep path parameters in other segments
as they are.
As said I am even happy if the default of this directive would keep
the current behavior.

 > This sounds a bit like we want to reject "/.;" or "/..;" for the
 > servlet case but still accept "/." and "/.." unconditionally for the
 > non-servlet case. So possibly we want a general "AllowPathTraversal"
 > directive (off by default) for the core to allow/reject "." and ".."
 > AND proxy mapping=servlet to extend it to "/.;" or "/.;" (and
probably
 > "/;" too since it's the same as "/.;" when MergeSlashes applies)?

I don't want to allow/deny '.' and '..'. Without path parameters I
just want to remove ('.') / shrink them ('..') without going
past root like we do today.


 From the beginning of this dialog, that isn't the function of an HTTP/1 
proxy. We have no business in that PER THE SPECS.


I don't understand why the Tomcat project and other servlet providers, 
after given evidence they broke the spec, and downgrade of their 
reservations of the ;params logic out of the URI spec, keep insisting 
the behavior is necessary for the HTTP transport providers to consider.


I don't understand why, Ruediger, some keep defending the .; or ..; as a 
normative acceptable path element, and refuse to consider the idea that 
every such occurance is malicious, without evidence of a single legit 
application of that formation.


If you don't want to let them slide, we *could* deny \.;.* and \.\.;.* 
by default. Or we already *can* when ajp users would like to add rewrite 
rules.


mod_proxy_http and mod_proxy_ajp behave the same way, mod_jk will return 
DECLINED and end normally in 404.


; in the URI is for a parameter like ;foo=bar I was first just 
suggesting to return 400 in possibly "unsafe" ..;/ URI using a parameter 
to prevent "regressions", but I think we ended looking to something too 
complex :-(









--
Cheers

Jean-Frederic