[Bug 61817] AuthLDAPBindPassword exec: directive (ap_get_exec_line()) creates defunct/zombie

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61817

detlef.pangratz@ing.com changed:

   What|Removed |Added

 CC||detlef.pangratz@ing.com

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



[Bug 68905] CONTENT_LENGTH omitted from POST requests

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

Eric Covener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Eric Covener  ---
I updated the doc and opened a bug for making the opt-in less necessary:
68907

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



[Bug 68907] New: replace ap_trust_cgilike_cl with a validating CL filter

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=68907

Bug ID: 68907
   Summary: replace ap_trust_cgilike_cl with a validating CL
filter
   Product: Apache httpd-2
   Version: 2.4.59
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Core
  Assignee: bugs@httpd.apache.org
  Reporter: cove...@gmail.com
  Target Milestone: ---

Instead of the current ban on Content-Length from CGI-like modules, we could
let these headers through and validate the length in some core filter, making
sure a short or long response results in a terminated connection.

This would replace the whitelisting via ap_trust_cgilike_cl

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



[Bug 68905] CONTENT_LENGTH omitted from POST requests

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

--- Comment #1 from Eric Covener  ---
The thread seems to be about responses from a CGI rather than requests.

I owe an update to https://httpd.apache.org/docs/2.4/env.html to document the
variable (that we hoped wouldn't be widely needed but we added so we could
respond without a new build)

I think the gist of the final post of the thread is fair. If the CGI is trusted
(untrusted users can't supply it) and can't be fooled into doing bad things,
the variable is fine and very narrow.

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



[Bug 68906] New: When a directory is named “core”, a bomb icon is displayed in FancyIndex

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=68906

Bug ID: 68906
   Summary: When a directory is named “core”, a bomb icon is
displayed in FancyIndex
   Product: Apache httpd-2
   Version: 2.5-HEAD
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P2
 Component: mod_autoindex
  Assignee: bugs@httpd.apache.org
  Reporter: de...@jwo.cz
  Target Milestone: ---

Created attachment 39670
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=39670=edit
Screenshot of the directory listing, with directory “core” and files “uwu.core”
and “uwucore”.

When the FancyIndex listing contains a directory with name “core”, a bomb icon
(intended for coredumps) is displayed instead of the normal directory icon.

I provide a screenshot in the attachment. (I use custom stylesheet on the
directory listing, but that does not have any effect on the icon displayed.)

If I recall correctly, there was a bug that caused displaying this icon for
files with names ending with “core”.

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



[Bug 68905] New: CONTENT_LENGTH omitted from POST requests

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=68905

Bug ID: 68905
   Summary: CONTENT_LENGTH omitted from POST requests
   Product: Apache httpd-2
   Version: 2.5-HEAD
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: mod_cgi
  Assignee: bugs@httpd.apache.org
  Reporter: d...@sqlite.org
  Target Milestone: ---

I am the project lead for SQLite and Fossil.  I have not verified this report
personally.  The information here is gleaned from a thread on the Fossil Forum:
 

Fossil is a version-control system, used by SQLite and many other projects. 
Fossil includes a web-interface that can be run using CGI.  There are thousands
of project teams using Fossil, and many of them run Fossil underneath Apache
using mod_cgi.

We have multiple reports from the field that after a recent Apache security
update, Fossil has stopped working.  We have traced the problem to a missing
CONTENT_LENGTH meta-variable.  In other words, it appears (as best as we can
determine so far) that Apache has stopped setting the CONTENT_LENGTH
environment variable for CGI requests that have content - such as POST
requests.

According to RFC 3875, "The server MUST set this meta-variable if and only if
the request is accompanied by a message-body entity."  Indeed, there is no way
for Fossil to discover the content length on its own if the CONTENT_LENGTH
environment variable is missing.  Fossil has to assume that CONTENT_LENGTH is
zero, but that causes POST content to go missing.

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



[Bug 67860] mod_tls: Fails to build with rustls_ffi 0.11.0

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=67860

--- Comment #6 from Daniel  ---
I heard from Stefan out-of-band and he agreed to help support an update. I will
try to start working on this Soon(TM).

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



[Bug 68902] [PATCH] Fixed args parsing in htdbm.c

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=68902

Victoriia  changed:

   What|Removed |Added

   Keywords||PatchAvailable

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



[Bug 68902] New: [PATCH] Fixed args parsing in htdbm.c

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=68902

Bug ID: 68902
   Summary: [PATCH] Fixed args parsing in htdbm.c
   Product: Apache httpd-2
   Version: 2.4.59
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: support
  Assignee: bugs@httpd.apache.org
  Reporter: vegor...@astralinux.ru
  Target Milestone: ---

Created attachment 39669
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=39669=edit
Args parse fix in htdbm

An error was detected in the htdbm in processing arguments, which subsequently
causes SEGV (https://bz.apache.org/bugzilla/show_bug.cgi?id=66637 and
https://bz.apache.org/bugzilla/show_bug.cgi?id=66638).
Previously, arguments were processed this way:
1. The args_left value is initialized, which is responsible for the number of
remaining arguments after the flags (username, database, password, depending on
the flags, some of them are required or not)
2. When a certain flag appears, the value of args_left is decreased or
increased. In this case, incorrect processing is possible when the value was
decreased, although the flags were not processed correctly (for example, in the
case of the input string "-nx-B",  first n and x will be processed as flags,
and then the loop will be exited. Since in the "case n" we decreased args_left
to 1, then only one argument is expected after the flag. After processing x, an
invalid character will be encountered - and processing of the flags in the loop
will be interrupted, so the entire input will be accepted as one whole
argument, but the value of args_left has already been changed).

The attached patch corrects this problem as follows: instead of changing the
value of args_left inside the loop, the value changes after it depending on the
command, and also transferred changes to the values of flags responsible for a
specific argument (for example, user_needed)

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



[Bug 68863] Requests using a DH-key of 2048 bytes are blocked since httpd/2.4.59

2024-04-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=68863

--- Comment #12 from Ruediger Pluem  ---
Proposed for backport as r1917010.

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