[ANN] New committer: Chuck Caldarale

[Mark Thomas]

On behalf of the Tomcat committers I am delighted to announce that
Chuck Caldarale (n828cl) has been voted in as a new Tomcat committer.

Please join me in congratulating Chuck.

Kind regards,

Mark

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

Re: [ANN] New committer: Chuck Caldarale

[Subodh Joshi]

Congratulations

On Wed, Jul 3, 2024 at 5:54 PM Mark Thomas  wrote:

> On behalf of the Tomcat committers I am delighted to announce that
> Chuck Caldarale (n828cl) has been voted in as a new Tomcat committer.
>
> Please join me in congratulating Chuck.
>
> Kind regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Subodh Chandra Joshi
subodh1_josh...@yahoo.co.in
http://www.trendsinnews.com

RE: [ANN] New committer: Chuck Caldarale

[Mcalexander, Jon J.]

Congratulations Chuck!

From: Mark Thomas 
Sent: Wednesday, July 3, 2024 7:25 AM
To: Tomcat Developers List ; Tomcat Users List 

Subject: [ANN] New committer: Chuck Caldarale
Importance: High

On behalf of the Tomcat committers I am delighted to announce that Chuck 
Caldarale (n828cl) has been voted in as a new Tomcat committer. Please join me 
in congratulating Chuck. Kind regards, Mark 
-


On behalf of the Tomcat committers I am delighted to announce that

Chuck Caldarale (n828cl) has been voted in as a new Tomcat committer.



Please join me in congratulating Chuck.



Kind regards,



Mark



-

To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: 
users-h...@tomcat.apache.org

Re: [ANN] New committer: Chuck Caldarale

[Terence M. Bandoian]

Congratulations, Chuck!

-Terence Bandoian

On 7/3/2024 7:24 AM, Mark Thomas wrote:

On behalf of the Tomcat committers I am delighted to announce that
Chuck Caldarale (n828cl) has been voted in as a new Tomcat committer.

Please join me in congratulating Chuck.

Kind regards,

Mark

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

Re: [ANN] New committer: Chuck Caldarale

[Zala Pierre GOUPIL]

Congrats Chuck and thanks for all these years of support. I think this is
totally deserved and I guess that it it another start in your life.

Cheers,

Pierre



On Wed, Jul 3, 2024 at 7:54 PM Terence M. Bandoian 
wrote:

> Congratulations, Chuck!
>
> -Terence Bandoian
>
> On 7/3/2024 7:24 AM, Mark Thomas wrote:
> > On behalf of the Tomcat committers I am delighted to announce that
> > Chuck Caldarale (n828cl) has been voted in as a new Tomcat committer.
> >
> > Please join me in congratulating Chuck.
> >
> > Kind regards,
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>


-- 
Je n'aime pas seulement ma vie, mais aussi celle des autres.

(Blade Runner)

[SECURITY] CVE-2024-34750 Apache Tomcat - Denial of Service

[Mark Thomas]

CVE-2024-34750 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M20
Apache Tomcat 10.1.0-M1 to 10.1.24
Apache Tomcat 9.0.0-M1 to 9.0.89

Description:
When processing an HTTP/2 stream, Tomcat did not handle some cases of 
excessive HTTP headers correctly. This led to a miscounting of active 
HTTP/2 streams which in turn led to the use of an incorrect infinite 
timeout which allowed connections to remain open which should have been 
closed.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M21 or later
- Upgrade to Apache Tomcat 10.1.25 or later
- Upgrade to Apache Tomcat 9.0.90 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by devme4f from VNPT-VCI.


History:
2024-07-03 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html

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

Re: Many CLOSE_WAIT connections causing the app not available

[Christopher Schultz]

Stephen,

On 6/29/24 07:57, Stephen Stevie wrote:

Tomcat not configured on default port


  


Which port is most often showing in the CLOSE_WAIT state?


[...] it was working fine until the start of this year. After that,
it was once a month and now every alternate day, we are seeing this.

Has the usage pattern of your application changed at all? More users, etc.?

-chris


On Thu, Jun 27, 2024 at 9:58 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Stephen,

On 6/26/24 01:18, Stephen Stevie wrote:

We are using Apache Tomcat 8.5.49 and sometimes in a day, we see the
application is going unresponsive though the service is up and running

and

giving 503 (service unavailable error). When netstat for the port is run,
we see many CLOSE_WAIT connections. Once we restart the service, the
application is coming back and sometimes this comes back on its own.

We have not made any changes to Tomcat in recent times and it was working
fine until the start of this year. After that, it was once a month and

now

every alternate day, we are seeing this. We're using 16GB RAM Web Server

(2

servers) and can see 1k-1.5k users connected to the application in a day.


Please post your  configuration, minus any secrets.

-chris

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






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

Re: Errors after upgrading to Tomcat 9.0.90

[Christopher Schultz]

Francesco,

On 7/2/24 05:44, Francesco Chicchiriccò wrote:

On 2024/06/27 14:47:48 Christopher Schultz wrote:

Rainer,

On 6/21/24 07:55, Rainer Jung wrote:

Am 20.06.24 um 17:52 schrieb Christopher Schultz:

Francesco,

On 6/20/24 09:03, Francesco Chicchiriccò wrote:

On 2024/06/20 12:18:15 Konstantin Kolinko wrote:

чт, 20 июн. 2024 г. в 13:25, Francesco Chicchiriccò
:


Hi there,
at Syncope we usually use the latest Tomcat versions to run a large
chunk of our integration tests.

In our master branch we relay on Tomcat 10.1.x, and upgrading to
10.1.25 from 10.1.24 went smooth as usual.

In our 3_0_X branch we relay on Tomcat 9.0.x; with 9.0.89
everything goes as expected, but with 9.0.90 we are getting the
exception [1].

Any idea of what could be changed in 9.0.90 within this regard?
Thank you.

[1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34



The "java.lang.IllegalStateException: The request object has been
recycled and is no longer associated with this facade" message means
that a Request object has been (illegally) stored and is accessed
outside of its lifecycle - when the underlying structures and buffers
have already been recycled and may have been reused to process
subsequent requests.

Mark wrote:

You could try explicitly setting discardFacades to false.


In general, not recommended.
https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors

Calling getScheme() might be safe (as IIRC the info will come from a
connector configuration), but anything beyond that may lead to either
false results or to security issues. It would be better to identify
and fix the underlying cause.


Are you suggesting there is something to fix on Syncope's or CXF's
code? Or rather on Tomcat?


This is a protection that Tomcat is providing to the application.
There is no known bug in Tomcat's code.

It's not clear to me whether Syncope's or CXF's code is retaining such
a reference, but, given the stack trace I would suspect that
UserServiceImpl in Syncope's code is where you should start looking.


As I am writing above, we have no issues with Tomcat 9.0.89 nor with
Tomcat 10.1.25.


It looks like this change was made in 9.0.90 *only* and was not ported
to the other June releases. Honestly, this change should have been
made to all active branches... I'm not sure why Rémy only applied it
to 9.0.x.


The default value for discardFacades is already "true" in 10.1 and 11
and the old system property
org.apache.catalina.connector.RECYCLE_FACADES no longer exists for
these. So setting discardFacades to "true" in 9.0.x makes the default
behavior consistent.


+1 thanks for pointing this out. This commit was Rémy aligning 9.0.x
with the other active branches, not making it /out/ of alignment.


No idea, why the application now shows different behavior for 9.0.x
and 10.1.x.

Agreed. But wrapping in HttpServletRequestWrapper, using Async, and
performing what the OP described as "multiplex[ing] the incoming request
onto atomic requests, injected to CXF service processing" sounds like a
recipe for retaining references to these objects after they go out of scope.


Hi Chris,
the fix mentioned above was exactly addressed to copy (as opposite as 
reference) the needed values from the original request.
While coding the fix, however, I've discovered that the Syncope master branch 
(run on Tomcat 10.1) was already updated to work this way, while the 3_0_X 
branch (run on Tomcat 9) was simply not as fresh.

Everything is back working as expected, thanks for information.

Finally, about:


If your application is retaining a reference to an HttpServletRequest
after the request has been completed, then your application has a bug.
You can tell me it doesn't have a bug, but it does. If you want
information from that request, you should copy it out of the request.


I just wanted to reassure you that my intention was not to deny there was an issue, just 
to explain that probably it was not much about "security and/or privacy".


I disagree. If you retain references to those objects, it's entirely 
possible to return data in a response to the wrong user. Or get 
information from a request whose user has changed out from underneath you.


Any time user A and user B can see each other's data, that's a privacy 
and/or security issue in my book.


-chris

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