date:20220301

Re: [users@httpd] How to get someone to look at a Apache bug report on Red Hat's Bugzilla?

2022-03-01 Thread Jeroen Verhoeckx

> Please keep your replies on the mailing list so that everyone can benefit 
> from the discussion.

Oh, sorry, I probably click on Reply and not Reply All! Will keep an eye on 
that in the future!

I'm worried that the version of Apache released by The Apache Software 
Foundation is less safe because of the warnings [on this page of Red 
Hat](https://access.redhat.com/solutions/445713):
https://access.redhat.com/solutions/445713

"Note that the versions of Apache HTTP Server included in the above products 
are in most cases vastly different from the upstream community releases of the 
same version
This is explained by Red Hat's Security Backporting Policy and is the most 
common cause of admins/auditors trying to get a newer version of Apache
For example: EWS 2.1.0 & EAP 6.4.0 include Apache httpd based on upstream 
v2.2.26; however, they also include multiple CVE security fixes which are not 
in the original community release of Apache httpd 2.2.266
Community releases of Apache httpd are NOT supported"

What do you think of this?

- Jeroen


Support the independent web, use 
[Firefox](https://www.mozilla.org/en-US/firefox/new/)

--- Original Message ---
On Tuesday, March 1st, 2022 at 5:27 PM, Yehuda Katz  wrote:

> Please keep your replies on the mailing list so that everyone can benefit 
> from the discussion.
>
> What is your "threat model" in which this way is less safe?
>
> For example: Are you worried that the packaged version from someone else has 
> been modified with a backdoor? Are you worried that you would not be able to 
> get RPMs for new versions in a timely fashion when a security issue is 
> announced?
>
> There are different ways to address different concerns, but if you are more 
> specific, we can make sure you get the best answer.
>
> - Y
>
> Sent from a device with a very small keyboard and hyperactive autocorrect.
>
> On Tue, Mar 1, 2022, 11:18 AM Jeroen Verhoeckx  
> wrote:
>
>>> Since you don't have paid support from RedHat, there is absolutely no 
>>> reason to not install your own version of httpd.
>>
>> I don't mind doing that but I'm afraid it's less safe?
>>
>> Thanks for thinking along!
>>
>> Jeroen Verhoeckx
>>
>> 
>> Support the independent web, use 
>> [Firefox](https://www.mozilla.org/en-US/firefox/new/)
>>
>> --- Original Message ---
>> On Thursday, February 24th, 2022 at 10:41 PM, Yehuda Katz 
>>  wrote:
>>
>>> In terms of getting a RedHat eningeer, it looks like you have done all you 
>>> can do. There are RedHat developers on this list and on the RedHat forums 
>>> and they also look at Bugzilla, so there probably isn't much more you can 
>>> do.
>>>
>>> Since you don't have paid support from RedHat, there is absolutely no 
>>> reason to not install your own version of httpd.
>>>
>>> - Y
>>>
>>> On Thu, Feb 24, 2022 at 9:37 AM Jeroen Verhoeckx 
>>>  wrote:
>>>
 Hello Yehuda,

 First: sorry for my very late reply!

> You mention in the bug report that you are running an old version of 
> HTTPD because you are using the version packaged by RedHat.
> Your bug report asks RedHat to backport the specific fixes for your issue.

 Yes, that's a really good summary of what I try to achieve!

 About the two options:

 - I have the 'Red Hat Developer Subscription for Individuals' and thus I'm 
 not entitled to get any official support.
 - Red Hat strongly discourages the installation of a different version of 
 Apache  (https://access.redhat.com/solutions/445713) .

 I asked the same question on Red Hat Community portal 
 (https://access.redhat.com/discussions/6756211) but so far I didn't get 
 any reaction.

 Does someone know where the Apache developers of Red Hat hang out?

 Jeroen Verhoeckx

 
 Support the independent web, use 
 [Firefox](https://www.mozilla.org/en-US/firefox/new/)

 --- Original Message ---
 On Friday, February 18th, 2022 at 8:38 PM, Yehuda Katz  
 wrote:

> I see two options for you going forward:
> 1. Contacting RedHat: You need a subscription to do this. Posting to the 
> upstream HTTPD mailing list probably won't help.
>
> 2. Use a different package: There are newer rpms available if you don't 
> want to build your own. You can look at rpmfind or build the rpm yourself 
> (https://httpd.apache.org/docs/2.4/platform/rpm.html)
>
> - Y
>
> On Fri, Feb 18, 2022 at 1:02 PM Jeroen Verhoeckx 
>  wrote:
>
>> Hello Apache Administrators,
>>
>> On 6 January I reported a possible bug of Apache on Red Hat's Bugzilla, 
>> but no one has responded since then.
>>
>> It's about this bug report:
>> https://bugzilla.redhat.com/show_bug.cgi?id=2037967
>>
>> Does

Re: [users@httpd] How to get someone to look at a Apache bug report on Red Hat's Bugzilla?

2022-03-01 Thread Yehuda Katz

Please keep your replies on the mailing list so that everyone can benefit
from the discussion.

What is your "threat model" in which this way is less safe?

For example: Are you worried that the packaged version from someone else
has been modified with a backdoor? Are you worried that you would not be
able to get RPMs for new versions in a timely fashion when a security issue
is announced?

There are different ways to address different concerns, but if you are more
specific, we can make sure you get the best answer.

- Y

Sent from a device with a very small keyboard and hyperactive autocorrect.

On Tue, Mar 1, 2022, 11:18 AM Jeroen Verhoeckx 
wrote:

> > Since you don't have paid support from RedHat, there is absolutely no
> reason to not install your own version of httpd.
>
> I don't mind doing that but I'm afraid it's less safe?
>
>
> Thanks for thinking along!
>
> Jeroen Verhoeckx
>
>
>
> 
> *Support the independent web, use **Firefox*
> 
>
>
>
> --- Original Message ---
> On Thursday, February 24th, 2022 at 10:41 PM, Yehuda Katz <
> yeh...@ymkatz.net> wrote:
>
> In terms of getting a RedHat eningeer, it looks like you have done all you
> can do. There are RedHat developers on this list and on the RedHat forums
> and they also look at Bugzilla, so there probably isn't much more you can
> do.
>
> Since you don't have paid support from RedHat, there is absolutely no
> reason to not install your own version of httpd.
>
> - Y
>
> On Thu, Feb 24, 2022 at 9:37 AM Jeroen Verhoeckx <
> j.verhoe...@protonmail.com> wrote:
>
>> Hello Yehuda,
>>
>> First: sorry for my very late reply!
>>
>> > You mention in the bug report that you are running an old version of
>> HTTPD because you are using the version packaged by RedHat.
>> > Your bug report asks RedHat to backport the specific fixes for your
>> issue.
>>
>> Yes, that's a really good summary of what I try to achieve!
>>
>>
>> About the two options:
>>
>>
>>1. I have the 'Red Hat Developer Subscription for Individuals' and
>>thus I'm not entitled to get any official support.
>>2. Red Hat strongly discourages the installation of a different
>>version of Apache (https://access.redhat.com/solutions/445713) .
>>
>>
>>
>> I asked the same question on Red Hat Community portal (
>> https://access.redhat.com/discussions/6756211) but so far I didn't get
>> any reaction.
>>
>>
>> Does someone know where the Apache developers of Red Hat hang out?
>>
>>
>>
>> Jeroen Verhoeckx
>>
>>
>>
>> 
>> *Support the independent web, use **Firefox*
>> 
>>
>>
>>
>> --- Original Message ---
>> On Friday, February 18th, 2022 at 8:38 PM, Yehuda Katz 
>> wrote:
>>
>>
>> I see two options for you going forward:
>> 1. Contacting RedHat: You need a subscription to do this. Posting to the
>> upstream HTTPD mailing list probably won't help.
>>
>> 2. Use a different package: There are newer rpms available if you don't
>> want to build your own. You can look at rpmfind or build the rpm yourself (
>> https://httpd.apache.org/docs/2.4/platform/rpm.html)
>>
>> - Y
>>
>> On Fri, Feb 18, 2022 at 1:02 PM Jeroen Verhoeckx
>>  wrote:
>>
>>> Hello Apache Administrators,
>>>
>>> On 6 January I reported a possible bug of Apache on Red Hat's Bugzilla, but
>>> no one has responded since then.
>>>
>>> It's about this bug report:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=2037967
>>>
>>>
>>> Does someone have an idea about what I could do next?
>>> Does someone know I place where I can contact RHEL Apache
>>> developers/administrators?
>>> Or is there another friendly way to get attention for this bug report?
>>>
>>>
>>> Yours sincerely,
>>>
>>> Jeroen Verhoeckx
>>>
>>>
>>>
>>> 
>>> *Support the independent web, use **Firefox*
>>> 
>>>
>>>
>>>
>>
>

Re: [users@httpd] ProxyPass option mapping=servlet hurts mod_rewrite

2022-03-01 Thread Yann Ylavic

Hi,

>
> I have applied your patch to my httpd-2.4.52 and created two test cases.
> One with a simple RewriteRule and a second one using a RewriteMap.
> Both are working fine. :-)

Thanks for testing! Now checked in https://svn.apache.org/r1898509

Regards;
Yann.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] Is a home directory for the httpd user safe?

2022-03-01 Thread Tom Browder

On Sun, Feb 27, 2022 at 3:24 PM Stormy  wrote:
>
> On 2022-02-27 10:31 a.m., Tom Browder wrote:
> > On Sun, Feb 27, 2022 at 09:11 Jeroen Verhoeckx
> >  wrote:
> >
> >> Why do you need a predefined user with a writeable home directory?
...

Sorry, I was not very clear: Raku has expectations about library
locations, etc., and I'm trying to sort out debugging info in a
strange (to me), hybrid environment. As it turns out, I was using
journalctl incorrectly and seeing old log info which misled me into
thinking I had a different Raku problem. For some reason, the Raku
module I'm using does have problems, but not directly associated with
Apache or systemd.

> Please do not blame your problems on "Raku" -- a quick look shows it to
> be a derivative of c or c++.  I started in FORTRAN in 1957, cobol in
> 1960, and have never, ever, blamed coding for any failure -- crap in,
> crap out -- YMMV.

I started in FORTRAN in 1961, and other languages since. I am a core
developer for  Raku, and I have never "blamed" the languages for my
failures. However, I do blame the language or program when they have
bugs. The problem then becomes whose bug ("blame") is it?  Usually it
is my problem, but this situation has been exasperating for me because
debugging it is hard and my program (and another user's published
module) seemed to behave differently in the systemd environment versus
my user space.

Best regards,

-Tom

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] ProxyPass option mapping=servlet hurts mod_rewrite

2022-03-01 Thread Hendrik Harms

Hi Yann

Anyway, could you please try the attached patch and see if it works for you?
>

I have applied your patch to my httpd-2.4.52 and created two test cases.
One with a simple RewriteRule and a second one using a RewriteMap.
Both are working fine. :-)

Test logs attached: mod_rewrite_vs_proxy_pre_trans-v2_test_log.txt

Thank you for the very quick response!
Regards,
Hendrik

-- 
--
Hendrik Harms
mail: hendrik.ha...@gmail.com

Test-Setup:

## Both test cases:
  httpd-2.4.52 with patch mod_rewrite_vs_proxy_pre_trans-v2.diff

  Hostname:  example.org

  ProxyPass  /alpha  http://server1.localnet:8080/alpha
  ProxyPass  /beta   http://server2.localnet:8080/beta  mapping=servlet


## First test case: "simple RewriteRule"
  RewriteRule "^/alpha" - [F]
  RewriteRule "^/beta"  - [F]

# log extract
# https://example.org/alpha/anypath/
[proxy:trace2] mod_proxy.c(884): AH03461: attempting to match URI path 
'/alpha/anypath/' against prefix '/beta' for proxying
[rewrite:trace2] mod_rewrite.c(480):  init rewrite engine with requested 
uri /alpha/anypath/. Original filename = n/a
[rewrite:trace3] mod_rewrite.c(480):  applying pattern '^/alpha' to uri 
'/alpha/anypath/'
[rewrite:trace2] mod_rewrite.c(480):  forcing responsecode 403 for 
/alpha/anypath/

# log extract
# https://example.org/beta/anypath/
[proxy:trace2] mod_proxy.c(884): AH03461: attempting to match URI path 
'/beta/anypath/' against prefix '/beta' for proxying
[proxy:trace1] mod_proxy.c(986): AH10248: Servlet path '/beta/anypath/' 
(/beta/anypath/) matches proxy handler 
'proxy:http://server2.localnet:8080/beta/anypath/'
[rewrite:trace2] mod_rewrite.c(480):  init rewrite engine with requested 
uri /beta/anypath/. Original filename = 
proxy:http://server2.localnet:8080/beta/anypath/
[rewrite:trace3] mod_rewrite.c(480):  applying pattern '^/alpha' to uri 
'/beta/anypath/'
[rewrite:trace3] mod_rewrite.c(480):  applying pattern '^/beta' to uri 
'/beta/anypath/'
[rewrite:trace2] mod_rewrite.c(480):  forcing responsecode 403 for 
/beta/anypath/



## Second test case using RewriteMap to set a maintanance page covering the 
backend.
## We could set this maintanance page without restarting the httpd server by 
using
## a RewriteMap :-)

# map-maintain.conf
  alpha  /cover/503.shtml
  beta   /cover/503.shtml

# httpd.conf e.g. extra/httpd-default.conf
  RewriteMap   maintain txt:conf/map-maintain.conf
  RewriteRule  ^/([^/]+)  ${maintain:$1|%{REQUEST_URI}} [NC,PT]

# log extract 
# https://example.org/alpha/anypath/
[proxy:trace2] mod_proxy.c(884): AH03461: attempting to match URI path 
'/alpha/anypath/' against prefix '/beta' for proxying
[rewrite:trace2] mod_rewrite.c(480):  init rewrite engine with requested 
uri /alpha/anypath/. Original filename = n/a
[rewrite:trace3] mod_rewrite.c(480):  applying pattern '^/([^/]+)' to uri 
'/alpha/anypath/'
[rewrite:trace6] mod_rewrite.c(480):  cache lookup FAILED, forcing new map 
lookup
[rewrite:trace5] mod_rewrite.c(480):  map lookup OK: map=maintain[txt] 
key=alpha -> val=/cover/503.shtml
[rewrite:trace2] mod_rewrite.c(480):  rewrite '/alpha/anypath/' -> 
'/cover/503.shtml'
[rewrite:trace2] mod_rewrite.c(480):  forcing '/cover/503.shtml' to get 
passed through to next API URI-to-filename handler


# log extract
# https://example.org/beta/anypath/
[proxy:trace2] mod_proxy.c(884): AH03461: attempting to match URI path 
'/beta/anypath/' against prefix '/beta' for proxying
[proxy:trace1] mod_proxy.c(986): AH10248: Servlet path '/beta/anypath/' 
(/beta/anypath/) matches proxy handler 
'proxy:http://server2.localnet:8080/beta/anypath/'
[rewrite:trace2] mod_rewrite.c(480):  init rewrite engine with requested 
uri /beta/anypath/. Original filename = 
proxy:http://server2.localnet:8080/beta/anypath/
[rewrite:trace3] mod_rewrite.c(480):  applying pattern '^/([^/]+)' to uri 
'/beta/anypath/'
[rewrite:trace6] mod_rewrite.c(480):  cache lookup FAILED, forcing new map 
lookup
[rewrite:trace5] mod_rewrite.c(480):  map lookup OK: map=maintain[txt] 
key=beta -> val=/cover/503.shtml
[rewrite:trace2] mod_rewrite.c(480):  rewrite '/beta/anypath/' -> 
'/cover/503.shtml'
[rewrite:trace2] mod_rewrite.c(480):  forcing '/cover/503.shtml' to get 
passed through to next API URI-to-filename handler



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] How to get someone to look at a Apache bug report on Red Hat's Bugzilla?

Re: [users@httpd] How to get someone to look at a Apache bug report on Red Hat's Bugzilla?

Re: [users@httpd] ProxyPass option mapping=servlet hurts mod_rewrite

Re: [users@httpd] Is a home directory for the httpd user safe?

Re: [users@httpd] ProxyPass option mapping=servlet hurts mod_rewrite

5 matches

Site Navigation

Mail list logo

Footer information