Re: [ANN] Apache Tomcat 8.5.81 available

[Han Li]

> 2022年6月14日 00:23，Christopher Schultz  写道：
> 
> Li,
> 
> On 6/13/22 08:26, Han Li wrote:
>>> 2022年6月13日 01:44，Christopher Schultz  写道：
>>> 
>>> The Apache Tomcat team announces the immediate availability of Apache
>>> Tomcat 8.5.81.
>>> 
>>> Apache Tomcat 8 is an open source software implementation of the Java
>>> Servlet, JavaServer Pages, Java Unified Expression Language, Java
>>> WebSocket and JASPIC technologies.
>>> 
>>> Apache Tomcat 8.5.81 is a bugfix and feature release. The notable
>>> changes compared to 8.5.79 include:
>>> 
>>> - Ensure that changes made to a request by the RemoteIPValve persist
>>> after the request is put into asynchronous mode.
>>> 
>>> - Correct a regression in the support added for encrypted PKCS#1
>>> formatted private keys in the previous release that broke support
>>> for unencrypted PKCS#1 formatted private keys.
>>> 
>>> - Increase the default buffer size for cluster messages from 43800
>>> to 65536 bytes. This is expected to improve performance for large
>>> messages when running on Linux based systems.
>>> 
>>> - When using TLS with non-blocking writes and the NIO connector,
>>> ensure that flushing the buffers attempts to empty all of the
>>> output buffers.
>>> 
>>> Along with lots of other bug fixes and improvements.
>>> 
>>> Please refer to the change log for the complete list of changes:
>>> https://tomcat.apache.org/tomcat-8.5-doc/changelog.html
>>> 
>>> 
>>> Downloads:
>>> https://tomcat.apache.org/download-80.cgi
>>> 
>>> Migration guides from Apache Tomcat 7.x and 8.0:
>>> https://tomcat.apache.org/migration.html
>>> 
>>> Enjoy!
>>> 
>>> - The Apache Tomcat team
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
>> Hi, Christopher.
>> I think you may have forgotten to update changelog, which is still 8.5.79.
>> ：）
> 
> The changelog has been updated. You may be seeing a cached page from the CDN. 
> Please let me know if it's still showing the old version.
> 
> -chris
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org 
> 
> For additional commands, e-mail: dev-h...@tomcat.apache.org 
> 
Sorry, I did see the cached data, I cleared my browser cache and it is now up 
to date.

Thanks for your reply.

Han Li

Re: Any interest in a read-only JMX role?

[Christopher Schultz]

Jon,

On 6/13/22 15:28, jonmcalexan...@wellsfargo.com.INVALID wrote:

I'm sorry I interfered.


Sorry, I don't think my tone transmitted well via email.

I was mostly trying to be playful.

If you'd like to comment on making monitoring data available via Tomcat 
using either the Manager app - or some other way - we'd be happy to have 
your feedback.


Thanks,
-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, June 13, 2022 1:36 PM
To: dev@tomcat.apache.org
Subject: Re: Any interest in a read-only JMX role?

Jon,

On 6/13/22 13:43, jonmcalexan...@wellsfargo.com.INVALID wrote:

That's great if you use the manager app, but we don't use it or even make it

available.

Well... this /is/ a conversation about the JMXProxyServlet which is a part of
the Manager app. So either you have something to say (about
JMXProxyServlet) or you don't care about the whole discussion, right?

:)

-chris


-Original Message-
From: Konstantin Kolinko 
Sent: Monday, June 13, 2022 11:54 AM
To: Tomcat Developers List 
Subject: Re: Any interest in a read-only JMX role?

пн, 13 июн. 2022 г. в 19:32, Christopher Schultz
:


All,

I've been thinking about the possibility of making a read-only JMX
role available for the existing manager-jmx capability.

[...]

Does anyone think this is a good idea?



I think it is a bad idea, because passwords (and maybe other secrets)
are visible through JMX, by design.

It might be worth to have some "status" role, but it has to be
defined more specifically than just a "view all" role.

Maybe the way to achieve the same result is to amend the server
status page, which is already provided by the manager app and has a
dedicated role.

Best regards,
Konstantin Kolinko.

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



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



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



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



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

RE: Any interest in a read-only JMX role?

[jonmcalexander]

I'm sorry I interfered.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Christopher Schultz 
> Sent: Monday, June 13, 2022 1:36 PM
> To: dev@tomcat.apache.org
> Subject: Re: Any interest in a read-only JMX role?
> 
> Jon,
> 
> On 6/13/22 13:43, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > That's great if you use the manager app, but we don't use it or even make it
> available.
> 
> Well... this /is/ a conversation about the JMXProxyServlet which is a part of
> the Manager app. So either you have something to say (about
> JMXProxyServlet) or you don't care about the whole discussion, right?
> 
> :)
> 
> -chris
> 
> >> -Original Message-
> >> From: Konstantin Kolinko 
> >> Sent: Monday, June 13, 2022 11:54 AM
> >> To: Tomcat Developers List 
> >> Subject: Re: Any interest in a read-only JMX role?
> >>
> >> пн, 13 июн. 2022 г. в 19:32, Christopher Schultz
> >> :
> >>>
> >>> All,
> >>>
> >>> I've been thinking about the possibility of making a read-only JMX
> >>> role available for the existing manager-jmx capability.
> >>>
> >>> [...]
> >>>
> >>> Does anyone think this is a good idea?
> >>>
> >>
> >> I think it is a bad idea, because passwords (and maybe other secrets)
> >> are visible through JMX, by design.
> >>
> >> It might be worth to have some "status" role, but it has to be
> >> defined more specifically than just a "view all" role.
> >>
> >> Maybe the way to achieve the same result is to amend the server
> >> status page, which is already provided by the manager app and has a
> >> dedicated role.
> >>
> >> Best regards,
> >> Konstantin Kolinko.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For
> >> additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For
> > additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional
> commands, e-mail: dev-h...@tomcat.apache.org


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

Re: Any interest in a read-only JMX role?

[Christopher Schultz]

Mark,

On 6/13/22 14:56, Mark Thomas wrote:

On 13/06/2022 19:34, Christopher Schultz wrote:

Mark,

On 6/13/22 13:19, Mark Thomas wrote:

On 13/06/2022 17:32, Christopher Schultz wrote:

All,

I've been thinking about the possibility of making a read-only JMX 
role available for the existing manager-jmx capability.


The idea would be that this role would only be able to make "get" 
requests (that is, a JMX-get operation, not HTTP-GET). No "set" or 
"invoke" operations would be allowed.


The manager-jmx role has quite a bit of power, and is typically used 
only for monitoring where being able to modify the server is not 
necessary. If manager-jmx is being used "only" for monitoring, then 
opening-up the system for potential reconfiguration by the 
monitoring user is a potential attack vector.


I don't think the level-of-effort would be significant: simply 
require "manager-jmx" for set/invoke operations and require either 
manager-jmx or manager-jmx-read-only (or something similar) for get 
operations.


Does anyone think this is a good idea?

I for one use jmxproxy at $work for both monitoring /and/ 
administrative tasks such as restarting applications, listing users, 
and initiating garbage collection (in very rare cases). For these 
full-write purposes, I could continue to use the (full) jmxproxy 
role, but for the monitoring-only ones, it would be nice to lock 
things down to the absolute minimum.


Given the widespread use of JMX for monitoring combined with the very 
minimal security model provided with JMX, I think there is merit in 
trying to improve the situation.


My concern with a simple read-only approach is that there are lots of 
attributes exposed via JMX that are considered security sensitive 
(AJP secrets, TLS key file passwords etc). With the current model we 
can't easily limit access to specific beans and attributes.


My assumption is that most monitoring tools only need a few 
attributes. Is there something we can do with the URI to move the 
bean name, attribute name, etc into the URI so we can use security 
constraints to limit access?


So like a more REST-style interface where the ACL ends up being just 
"simple" role-based access using the  framework 
already supported by Tomcat?


Yes, something along those sort of lines.

I agree I'd really like to avoid creating a new type of authorization 
system, so this seems like a good path to go down.


Another option that occurred to me reading the rest of this thread was 
some sort of (JSON formatted?) status page that displayed a specified 
sub-set of beans and attributes. There would need to be some sort of 
config file to select beans and attributes but other than that, security 
could be provided by the standard security constraint approach.


If this was a servlet, you could have multiple instances of the Servlet 
with different configurations for different users.


Another fairly good idea IMO. It even addresses Tim's (reasonably) 
paranoid concerns about exposing JMX at all. This could be implemented 
behind the scenes using JMX, but as far as the client is concerned, it 
just sees "status" and doesn't care where the values come from.


It has the added benefit of being able to return multiple status bits at 
once instead of having to make multiple roundtrips to Tomcat to get the 
status of several items separately.


-chris

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

Re: Any interest in a read-only JMX role?

[Tim Funk]

Doing a quick dive and restricting invoke, get, set, query to their own
roles looks "easy" since they have their if() checks.(Easier to lock down
than I recalled)

As for further locking down get() - I guess one could add an init() param
to the servlet called get-approve-list which can be a white space, comma,
(or whatever) separator of regexes to approve in. (And the absence of the
parameter allows .+)

EXAMPLE web.xml

   get-approve-list  
  
java.lang:type=Memory
^java.lang:.+
  


Replacement to around line 112 of existing JMXProxy
qry = request.getParameter("get");
if (qry != null) {
boolean matches = false;
for (String regex:getRestrictions ) {
matches = matches || qry.matches(regex);
}
if (!matches) {
throw new Error403(); /* I made this up */
}

String name = request.getParameter("att");
getAttribute(writer, qry, name, request.getParameter("key"));
return;
}

As for status  If you strike the the active requests from
"/manager/status?XML=true" (Which can leak session info) - You have a
pretty good status monitor (even though its XML)

-Tim

On Mon, Jun 13, 2022 at 2:29 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

>
> I think the JMXProxyServlet is better than JMX itself for a number of
> reasons. Though platform JMX access has improved in the last few
> versions, the fact is that Tomcat's ability to provide access to JMX
> (through HTTP) is far more flexible and secure than the heavy-handed JMX
> capabilities provided by the platform.
>
> I would be strongly against deprecating the JMXProxyServlet for that
> reason moving forward.
>
>

Re: Any interest in a read-only JMX role?

[Mark Thomas]

On 13/06/2022 19:34, Christopher Schultz wrote:

Mark,

On 6/13/22 13:19, Mark Thomas wrote:

On 13/06/2022 17:32, Christopher Schultz wrote:

All,

I've been thinking about the possibility of making a read-only JMX 
role available for the existing manager-jmx capability.


The idea would be that this role would only be able to make "get" 
requests (that is, a JMX-get operation, not HTTP-GET). No "set" or 
"invoke" operations would be allowed.


The manager-jmx role has quite a bit of power, and is typically used 
only for monitoring where being able to modify the server is not 
necessary. If manager-jmx is being used "only" for monitoring, then 
opening-up the system for potential reconfiguration by the monitoring 
user is a potential attack vector.


I don't think the level-of-effort would be significant: simply 
require "manager-jmx" for set/invoke operations and require either 
manager-jmx or manager-jmx-read-only (or something similar) for get 
operations.


Does anyone think this is a good idea?

I for one use jmxproxy at $work for both monitoring /and/ 
administrative tasks such as restarting applications, listing users, 
and initiating garbage collection (in very rare cases). For these 
full-write purposes, I could continue to use the (full) jmxproxy 
role, but for the monitoring-only ones, it would be nice to lock 
things down to the absolute minimum.


Given the widespread use of JMX for monitoring combined with the very 
minimal security model provided with JMX, I think there is merit in 
trying to improve the situation.


My concern with a simple read-only approach is that there are lots of 
attributes exposed via JMX that are considered security sensitive (AJP 
secrets, TLS key file passwords etc). With the current model we can't 
easily limit access to specific beans and attributes.


My assumption is that most monitoring tools only need a few 
attributes. Is there something we can do with the URI to move the bean 
name, attribute name, etc into the URI so we can use security 
constraints to limit access?


So like a more REST-style interface where the ACL ends up being just 
"simple" role-based access using the  framework 
already supported by Tomcat?


Yes, something along those sort of lines.

I agree I'd really like to avoid creating a new type of authorization 
system, so this seems like a good path to go down.


Another option that occurred to me reading the rest of this thread was 
some sort of (JSON formatted?) status page that displayed a specified 
sub-set of beans and attributes. There would need to be some sort of 
config file to select beans and attributes but other than that, security 
could be provided by the standard security constraint approach.


If this was a servlet, you could have multiple instances of the Servlet 
with different configurations for different users.


Mark

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

[tomcat] branch 8.5.x updated: TLS handshake debugging is supported in NIO2 as well

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 1d3374d63b TLS handshake debugging is supported in NIO2 as well
1d3374d63b is described below

commit 1d3374d63bf0c6b20f02fbf44b49ad9f51bd49fb
Author: Mark Thomas 
AuthorDate: Mon Jun 13 19:51:17 2022 +0100

TLS handshake debugging is supported in NIO2 as well
---
 webapps/docs/changelog.xml | 5 +++--
 webapps/docs/ssl-howto.xml | 6 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index d563715ed7..3932930373 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -108,8 +108,9 @@
   
 
   
-Provide a dedicated logger
-(org.apache.tomcat.util.net.NioEndpoint.handshake) for TLS
+Provide dedicated loggers
+(org.apache.tomcat.util.net.NioEndpoint.handshake /
+org.apache.tomcat.util.net.Nio2Endpoint.handshake) for TLS
 handshake failures. (markt)
   
 
diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml
index dd357d9e53..ff4aae5651 100644
--- a/webapps/docs/ssl-howto.xml
+++ b/webapps/docs/ssl-howto.xml
@@ -567,8 +567,12 @@ for more information about installation of APR. A basic 
OCSP-enabled connector
 
 Additional information may be obtained about TLS handshake failures by
 configuring the dedicated TLS handshake logger to log debug level messages by
-adding the following to 
$CATALINA_BASE/conf/logging.properties:
+adding the following to $CATALINA_BASE/conf/logging.properties:
 org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE
+or
+org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE
+depending on the Connector being used.
+
 
 Here is a list of common problems that you may encounter when setting up
 SSL communications, and what to do about them.


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

[tomcat] branch 9.0.x updated: TLS handshake debugging is supported in NIO2 as well

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new a270eec02b TLS handshake debugging is supported in NIO2 as well
a270eec02b is described below

commit a270eec02b8b8769c5d4df25d3ca77e9e4d8607b
Author: Mark Thomas 
AuthorDate: Mon Jun 13 19:51:17 2022 +0100

TLS handshake debugging is supported in NIO2 as well
---
 webapps/docs/changelog.xml | 5 +++--
 webapps/docs/ssl-howto.xml | 6 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index a7e484b690..96f1dd4f3e 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -117,8 +117,9 @@
   
 
   
-Provide a dedicated logger
-(org.apache.tomcat.util.net.NioEndpoint.handshake) for TLS
+Provide dedicated loggers
+(org.apache.tomcat.util.net.NioEndpoint.handshake /
+org.apache.tomcat.util.net.Nio2Endpoint.handshake) for TLS
 handshake failures. (markt)
   
 
diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml
index dd357d9e53..ff4aae5651 100644
--- a/webapps/docs/ssl-howto.xml
+++ b/webapps/docs/ssl-howto.xml
@@ -567,8 +567,12 @@ for more information about installation of APR. A basic 
OCSP-enabled connector
 
 Additional information may be obtained about TLS handshake failures by
 configuring the dedicated TLS handshake logger to log debug level messages by
-adding the following to 
$CATALINA_BASE/conf/logging.properties:
+adding the following to $CATALINA_BASE/conf/logging.properties:
 org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE
+or
+org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE
+depending on the Connector being used.
+
 
 Here is a list of common problems that you may encounter when setting up
 SSL communications, and what to do about them.


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

[tomcat] branch 10.0.x updated: TLS handshake debugging is supported in NIO2 as well

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/10.0.x by this push:
 new a3b6100972 TLS handshake debugging is supported in NIO2 as well
a3b6100972 is described below

commit a3b6100972473d2480106d52dcdf9c6d3c118e29
Author: Mark Thomas 
AuthorDate: Mon Jun 13 19:51:17 2022 +0100

TLS handshake debugging is supported in NIO2 as well
---
 webapps/docs/changelog.xml | 5 +++--
 webapps/docs/ssl-howto.xml | 6 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index a78d375731..7c088a7856 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -117,8 +117,9 @@
   
 
   
-Provide a dedicated logger
-(org.apache.tomcat.util.net.NioEndpoint.handshake) for TLS
+Provide dedicated loggers
+(org.apache.tomcat.util.net.NioEndpoint.handshake /
+org.apache.tomcat.util.net.Nio2Endpoint.handshake) for TLS
 handshake failures. (markt)
   
 
diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml
index 97fb9f184e..f297fcd738 100644
--- a/webapps/docs/ssl-howto.xml
+++ b/webapps/docs/ssl-howto.xml
@@ -579,8 +579,12 @@ for more information about installation of APR. A basic 
OCSP-enabled connector
 
 Additional information may be obtained about TLS handshake failures by
 configuring the dedicated TLS handshake logger to log debug level messages by
-adding the following to 
$CATALINA_BASE/conf/logging.properties:
+adding the following to $CATALINA_BASE/conf/logging.properties:
 org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE
+or
+org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE
+depending on the Connector being used.
+
 
 Here is a list of common problems that you may encounter when setting up
 SSL communications, and what to do about them.


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

[tomcat] branch main updated: TLS handshake debugging is supported in NIO2 as well

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
 new 9ebfe1393e TLS handshake debugging is supported in NIO2 as well
9ebfe1393e is described below

commit 9ebfe1393e5fcab03eb825a4983cb96984a3ebd4
Author: Mark Thomas 
AuthorDate: Mon Jun 13 19:51:17 2022 +0100

TLS handshake debugging is supported in NIO2 as well
---
 webapps/docs/changelog.xml | 5 +++--
 webapps/docs/ssl-howto.xml | 6 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 21a65b9443..b223e83add 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -117,8 +117,9 @@
   
 
   
-Provide a dedicated logger
-(org.apache.tomcat.util.net.NioEndpoint.handshake) for TLS
+Provide dedicated loggers
+(org.apache.tomcat.util.net.NioEndpoint.handshake /
+org.apache.tomcat.util.net.Nio2Endpoint.handshake) for TLS
 handshake failures. (markt)
   
 
diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml
index ab62bfbeac..a5a7015fcf 100644
--- a/webapps/docs/ssl-howto.xml
+++ b/webapps/docs/ssl-howto.xml
@@ -524,8 +524,12 @@ nsComment="Testing OCSP Certificate"
 
 Additional information may be obtained about TLS handshake failures by
 configuring the dedicated TLS handshake logger to log debug level messages by
-adding the following to 
$CATALINA_BASE/conf/logging.properties:
+adding the following to $CATALINA_BASE/conf/logging.properties:
 org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE
+or
+org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE
+depending on the Connector being used.
+
 
 Here is a list of common problems that you may encounter when setting up
 SSL communications, and what to do about them.


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

[Bug 65401] do no silently fail on javax.net.ssl.SSLHandshakeException "No appropriate protocol (protocol is disabled or cipher suites are inappropriate)"

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65401

Mark Thomas  changed:

   What|Removed |Added

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

--- Comment #1 from Mark Thomas  ---
I've spent a bit of time looking into this today.

It appears that the TLS error message have been improved and that a clearer
exception is thrown from a different point in the process.

I have also added a dedicated logger for TLS handshake failures. If you only
want debug logging for handshake failures then you can enable debug logging for

org.apache.tomcat.util.net.NioEndpoint.handshake

or

org.apache.tomcat.util.net.Nio2Endpoint.handshake

as appropriate.

With a recent JRE and latest Tomcat, I think this is addressed. If there is
still a combination where the error message is missing / unhelpful feel free to
re-open this issue and provide the configuration details and openssl client
command to trigger the issue and we can take another look.

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

Re: Any interest in a read-only JMX role?

[Christopher Schultz]

Jon,

On 6/13/22 13:43, jonmcalexan...@wellsfargo.com.INVALID wrote:

That's great if you use the manager app, but we don't use it or even make it 
available.


Well... this /is/ a conversation about the JMXProxyServlet which is a 
part of the Manager app. So either you have something to say (about 
JMXProxyServlet) or you don't care about the whole discussion, right?


:)

-chris


-Original Message-
From: Konstantin Kolinko 
Sent: Monday, June 13, 2022 11:54 AM
To: Tomcat Developers List 
Subject: Re: Any interest in a read-only JMX role?

пн, 13 июн. 2022 г. в 19:32, Christopher Schultz
:


All,

I've been thinking about the possibility of making a read-only JMX
role available for the existing manager-jmx capability.

[...]

Does anyone think this is a good idea?



I think it is a bad idea, because passwords (and maybe other secrets) are
visible through JMX, by design.

It might be worth to have some "status" role, but it has to be defined more
specifically than just a "view all" role.

Maybe the way to achieve the same result is to amend the server status
page, which is already provided by the manager app and has a dedicated
role.

Best regards,
Konstantin Kolinko.

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



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



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

Re: Any interest in a read-only JMX role?

[Christopher Schultz]

Mark,

On 6/13/22 13:19, Mark Thomas wrote:

On 13/06/2022 17:32, Christopher Schultz wrote:

All,

I've been thinking about the possibility of making a read-only JMX 
role available for the existing manager-jmx capability.


The idea would be that this role would only be able to make "get" 
requests (that is, a JMX-get operation, not HTTP-GET). No "set" or 
"invoke" operations would be allowed.


The manager-jmx role has quite a bit of power, and is typically used 
only for monitoring where being able to modify the server is not 
necessary. If manager-jmx is being used "only" for monitoring, then 
opening-up the system for potential reconfiguration by the monitoring 
user is a potential attack vector.


I don't think the level-of-effort would be significant: simply require 
"manager-jmx" for set/invoke operations and require either manager-jmx 
or manager-jmx-read-only (or something similar) for get operations.


Does anyone think this is a good idea?

I for one use jmxproxy at $work for both monitoring /and/ 
administrative tasks such as restarting applications, listing users, 
and initiating garbage collection (in very rare cases). For these 
full-write purposes, I could continue to use the (full) jmxproxy role, 
but for the monitoring-only ones, it would be nice to lock things down 
to the absolute minimum.


Given the widespread use of JMX for monitoring combined with the very 
minimal security model provided with JMX, I think there is merit in 
trying to improve the situation.


My concern with a simple read-only approach is that there are lots of 
attributes exposed via JMX that are considered security sensitive (AJP 
secrets, TLS key file passwords etc). With the current model we can't 
easily limit access to specific beans and attributes.


My assumption is that most monitoring tools only need a few attributes. 
Is there something we can do with the URI to move the bean name, 
attribute name, etc into the URI so we can use security constraints to 
limit access?


So like a more REST-style interface where the ACL ends up being just 
"simple" role-based access using the  framework 
already supported by Tomcat?


I agree I'd really like to avoid creating a new type of authorization 
system, so this seems like a good path to go down.


-chris

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

Re: Any interest in a read-only JMX role?

[Christopher Schultz]

Konstantin,

On 6/13/22 12:54, Konstantin Kolinko wrote:

пн, 13 июн. 2022 г. в 19:32, Christopher Schultz :


All,

I've been thinking about the possibility of making a read-only JMX role
available for the existing manager-jmx capability.

[...]

Does anyone think this is a good idea?



I think it is a bad idea, because passwords (and maybe other secrets)
are visible through JMX, by design.


How can you view a password through JMX -- assuming you can only make 
JMX "get" requests?



It might be worth to have some "status" role,
but it has to be defined more specifically than just a "view all" role.


I'm okay with a line-item ACL for specific resources. It's just more 
effort to (a) program and (b) implement at a site.



Maybe the way to achieve the same result is to amend the server status page,
which is already provided by the manager app and has a dedicated role.


That's another possibility, but something that can produce small (HTTP) 
responses is preferable to something which requires screen-scraping.


-chris

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

Re: Any interest in a read-only JMX role?

[Christopher Schultz]

Tim,

On 6/13/22 12:54, Tim Funk wrote:

I think JMXProxy should be eventually deprecated. It's "too powerful" for
what it can do. At the time of creation - it was a neat idea that was
powerful. But if I had to imagine if we would create such a servlet today,
security alarms would be loudly clanging.

I think a read only option would help lock things down for those who prefer
only reading JMX stats. So in that sense it's an extra layer of support.
But conversely, I also think it's a false sense of security.


Fair enough.

I think the JMXProxyServlet is better than JMX itself for a number of 
reasons. Though platform JMX access has improved in the last few 
versions, the fact is that Tomcat's ability to provide access to JMX 
(through HTTP) is far more flexible and secure than the heavy-handed JMX 
capabilities provided by the platform.


I would be strongly against deprecating the JMXProxyServlet for that 
reason moving forward.


-chris


On Mon, Jun 13, 2022 at 12:32 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

I've been thinking about the possibility of making a read-only JMX role
available for the existing manager-jmx capability.

The idea would be that this role would only be able to make "get"
requests (that is, a JMX-get operation, not HTTP-GET). No "set" or
"invoke" operations would be allowed.

The manager-jmx role has quite a bit of power, and is typically used
only for monitoring where being able to modify the server is not
necessary. If manager-jmx is being used "only" for monitoring, then
opening-up the system for potential reconfiguration by the monitoring
user is a potential attack vector.

I don't think the level-of-effort would be significant: simply require
"manager-jmx" for set/invoke operations and require either manager-jmx
or manager-jmx-read-only (or something similar) for get operations.






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

RE: Any interest in a read-only JMX role?

[jonmcalexander]

That's great if you use the manager app, but we don't use it or even make it 
available.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


> -Original Message-
> From: Konstantin Kolinko 
> Sent: Monday, June 13, 2022 11:54 AM
> To: Tomcat Developers List 
> Subject: Re: Any interest in a read-only JMX role?
> 
> пн, 13 июн. 2022 г. в 19:32, Christopher Schultz
> :
> >
> > All,
> >
> > I've been thinking about the possibility of making a read-only JMX
> > role available for the existing manager-jmx capability.
> >
> > [...]
> >
> > Does anyone think this is a good idea?
> >
> 
> I think it is a bad idea, because passwords (and maybe other secrets) are
> visible through JMX, by design.
> 
> It might be worth to have some "status" role, but it has to be defined more
> specifically than just a "view all" role.
> 
> Maybe the way to achieve the same result is to amend the server status
> page, which is already provided by the manager app and has a dedicated
> role.
> 
> Best regards,
> Konstantin Kolinko.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional
> commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 9.0.x updated: Javadoc improvements

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new f393873ccd Javadoc improvements
f393873ccd is described below

commit f393873ccd288a7557d20369f1f18cf12890cffd
Author: Mark Thomas 
AuthorDate: Mon Jun 13 18:40:40 2022 +0100

Javadoc improvements

Primarily to trigger a CI build
---
 java/javax/el/ArrayELResolver.java | 12 
 1 file changed, 12 insertions(+)

diff --git a/java/javax/el/ArrayELResolver.java 
b/java/javax/el/ArrayELResolver.java
index c143a6d94c..1f7961 100644
--- a/java/javax/el/ArrayELResolver.java
+++ b/java/javax/el/ArrayELResolver.java
@@ -21,14 +21,26 @@ import java.lang.reflect.Array;
 import java.util.Iterator;
 import java.util.Objects;
 
+/**
+ * Standard ELResolver for working with arrays.
+ */
 public class ArrayELResolver extends ELResolver {
 
 private final boolean readOnly;
 
+/**
+ * Creates a writable instance of the standard array resolver.
+ */
 public ArrayELResolver() {
 this.readOnly = false;
 }
 
+/**
+ * Creates an instance of the standard array resolver.
+ *
+ * @param readOnly  {@code true} if the created instance should be 
read-only
+ *  otherwise false.
+ */
 public ArrayELResolver(boolean readOnly) {
 this.readOnly = readOnly;
 }


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

[tomcat] branch 10.0.x updated: Javadoc improvements

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/10.0.x by this push:
 new 780d55a405 Javadoc improvements
780d55a405 is described below

commit 780d55a405f1e4608d305c85a77f0e17c78c447d
Author: Mark Thomas 
AuthorDate: Mon Jun 13 18:40:40 2022 +0100

Javadoc improvements

Primarily to trigger a CI build
---
 java/jakarta/el/ArrayELResolver.java | 12 
 1 file changed, 12 insertions(+)

diff --git a/java/jakarta/el/ArrayELResolver.java 
b/java/jakarta/el/ArrayELResolver.java
index 7626deb3b6..9049b362ab 100644
--- a/java/jakarta/el/ArrayELResolver.java
+++ b/java/jakarta/el/ArrayELResolver.java
@@ -21,14 +21,26 @@ import java.lang.reflect.Array;
 import java.util.Iterator;
 import java.util.Objects;
 
+/**
+ * Standard ELResolver for working with arrays.
+ */
 public class ArrayELResolver extends ELResolver {
 
 private final boolean readOnly;
 
+/**
+ * Creates a writable instance of the standard array resolver.
+ */
 public ArrayELResolver() {
 this.readOnly = false;
 }
 
+/**
+ * Creates an instance of the standard array resolver.
+ *
+ * @param readOnly  {@code true} if the created instance should be 
read-only
+ *  otherwise false.
+ */
 public ArrayELResolver(boolean readOnly) {
 this.readOnly = readOnly;
 }


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

[tomcat] branch 8.5.x updated: Javadoc improvements

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 28ccc78786 Javadoc improvements
28ccc78786 is described below

commit 28ccc787860682a1f24361ac1c6c825351c105f0
Author: Mark Thomas 
AuthorDate: Mon Jun 13 18:40:40 2022 +0100

Javadoc improvements

Primarily to trigger a CI build
---
 java/javax/el/ArrayELResolver.java | 12 
 1 file changed, 12 insertions(+)

diff --git a/java/javax/el/ArrayELResolver.java 
b/java/javax/el/ArrayELResolver.java
index c143a6d94c..1f7961 100644
--- a/java/javax/el/ArrayELResolver.java
+++ b/java/javax/el/ArrayELResolver.java
@@ -21,14 +21,26 @@ import java.lang.reflect.Array;
 import java.util.Iterator;
 import java.util.Objects;
 
+/**
+ * Standard ELResolver for working with arrays.
+ */
 public class ArrayELResolver extends ELResolver {
 
 private final boolean readOnly;
 
+/**
+ * Creates a writable instance of the standard array resolver.
+ */
 public ArrayELResolver() {
 this.readOnly = false;
 }
 
+/**
+ * Creates an instance of the standard array resolver.
+ *
+ * @param readOnly  {@code true} if the created instance should be 
read-only
+ *  otherwise false.
+ */
 public ArrayELResolver(boolean readOnly) {
 this.readOnly = readOnly;
 }


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

RE: Any interest in a read-only JMX role?

[jonmcalexander]

This sounds like a good idea to me. There may be times that an application team 
wants to be able to monitor their app, but the support engineers don't want to 
give them normal JMX access to a production system. The Read-Only role would be 
good for those types.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Christopher Schultz 
> Sent: Monday, June 13, 2022 11:32 AM
> To: Tomcat Developers List 
> Subject: Any interest in a read-only JMX role?
> 
> All,
> 
> I've been thinking about the possibility of making a read-only JMX role
> available for the existing manager-jmx capability.
> 
> The idea would be that this role would only be able to make "get"
> requests (that is, a JMX-get operation, not HTTP-GET). No "set" or "invoke"
> operations would be allowed.
> 
> The manager-jmx role has quite a bit of power, and is typically used only for
> monitoring where being able to modify the server is not necessary. If
> manager-jmx is being used "only" for monitoring, then opening-up the
> system for potential reconfiguration by the monitoring user is a potential
> attack vector.
> 
> I don't think the level-of-effort would be significant: simply require
> "manager-jmx" for set/invoke operations and require either manager-jmx or
> manager-jmx-read-only (or something similar) for get operations.
> 
> Does anyone think this is a good idea?
> 
> I for one use jmxproxy at $work for both monitoring /and/ administrative
> tasks such as restarting applications, listing users, and initiating garbage
> collection (in very rare cases). For these full-write purposes, I could 
> continue
> to use the (full) jmxproxy role, but for the monitoring-only ones, it would be
> nice to lock things down to the absolute minimum.
> 
> -chris
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional
> commands, e-mail: dev-h...@tomcat.apache.org


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

[tomcat] branch main updated: Javadoc improvements

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
 new 0a812fa323 Javadoc improvements
0a812fa323 is described below

commit 0a812fa3235220c93a325349a7ba7c2e5ea0f14c
Author: Mark Thomas 
AuthorDate: Mon Jun 13 18:40:40 2022 +0100

Javadoc improvements

Primarily to trigger a CI build
---
 java/jakarta/el/ArrayELResolver.java | 12 
 1 file changed, 12 insertions(+)

diff --git a/java/jakarta/el/ArrayELResolver.java 
b/java/jakarta/el/ArrayELResolver.java
index d8d4ff93e3..410c31b9ef 100644
--- a/java/jakarta/el/ArrayELResolver.java
+++ b/java/jakarta/el/ArrayELResolver.java
@@ -21,14 +21,26 @@ import java.lang.reflect.Array;
 import java.util.Iterator;
 import java.util.Objects;
 
+/**
+ * Standard ELResolver for working with arrays.
+ */
 public class ArrayELResolver extends ELResolver {
 
 private final boolean readOnly;
 
+/**
+ * Creates a writable instance of the standard array resolver.
+ */
 public ArrayELResolver() {
 this.readOnly = false;
 }
 
+/**
+ * Creates an instance of the standard array resolver.
+ *
+ * @param readOnly  {@code true} if the created instance should be 
read-only
+ *  otherwise false.
+ */
 public ArrayELResolver(boolean readOnly) {
 this.readOnly = readOnly;
 }


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

Re: Any interest in a read-only JMX role?

[Mark Thomas]

On 13/06/2022 17:32, Christopher Schultz wrote:

All,

I've been thinking about the possibility of making a read-only JMX role 
available for the existing manager-jmx capability.


The idea would be that this role would only be able to make "get" 
requests (that is, a JMX-get operation, not HTTP-GET). No "set" or 
"invoke" operations would be allowed.


The manager-jmx role has quite a bit of power, and is typically used 
only for monitoring where being able to modify the server is not 
necessary. If manager-jmx is being used "only" for monitoring, then 
opening-up the system for potential reconfiguration by the monitoring 
user is a potential attack vector.


I don't think the level-of-effort would be significant: simply require 
"manager-jmx" for set/invoke operations and require either manager-jmx 
or manager-jmx-read-only (or something similar) for get operations.


Does anyone think this is a good idea?

I for one use jmxproxy at $work for both monitoring /and/ administrative 
tasks such as restarting applications, listing users, and initiating 
garbage collection (in very rare cases). For these full-write purposes, 
I could continue to use the (full) jmxproxy role, but for the 
monitoring-only ones, it would be nice to lock things down to the 
absolute minimum.


Given the widespread use of JMX for monitoring combined with the very 
minimal security model provided with JMX, I think there is merit in 
trying to improve the situation.


My concern with a simple read-only approach is that there are lots of 
attributes exposed via JMX that are considered security sensitive (AJP 
secrets, TLS key file passwords etc). With the current model we can't 
easily limit access to specific beans and attributes.


My assumption is that most monitoring tools only need a few attributes. 
Is there something we can do with the URI to move the bean name, 
attribute name, etc into the URI so we can use security constraints to 
limit access?


Mark


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

Re: Any interest in a read-only JMX role?

[Konstantin Kolinko]

пн, 13 июн. 2022 г. в 19:54, Konstantin Kolinko :
>
> пн, 13 июн. 2022 г. в 19:32, Christopher Schultz 
> :
> >
> > All,
> >
> > I've been thinking about the possibility of making a read-only JMX role
> > available for the existing manager-jmx capability.
> >
> > [...]
> >
> > Does anyone think this is a good idea?
> >
>
> I think it is a bad idea, because passwords (and maybe other secrets)
> are visible through JMX, by design.
>
> It might be worth to have some "status" role,
> but it has to be defined more specifically than just a "view all" role.
>
> Maybe the way to achieve the same result is to amend the server status page,
> which is already provided by the manager app and has a dedicated role.

BTW, the server status page might show session ids - in rare circumstances
when session id is visible in the request URI.

So it is also not safe to show the status page to an untrusted party.

Best regards,
Konstantin Kolinko

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

Re: Any interest in a read-only JMX role?

[Tim Funk]

I think JMXProxy should be eventually deprecated. It's "too powerful" for
what it can do. At the time of creation - it was a neat idea that was
powerful. But if I had to imagine if we would create such a servlet today,
security alarms would be loudly clanging.

I think a read only option would help lock things down for those who prefer
only reading JMX stats. So in that sense it's an extra layer of support.
But conversely, I also think it's a false sense of security.

-Tim

On Mon, Jun 13, 2022 at 12:32 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> I've been thinking about the possibility of making a read-only JMX role
> available for the existing manager-jmx capability.
>
> The idea would be that this role would only be able to make "get"
> requests (that is, a JMX-get operation, not HTTP-GET). No "set" or
> "invoke" operations would be allowed.
>
> The manager-jmx role has quite a bit of power, and is typically used
> only for monitoring where being able to modify the server is not
> necessary. If manager-jmx is being used "only" for monitoring, then
> opening-up the system for potential reconfiguration by the monitoring
> user is a potential attack vector.
>
> I don't think the level-of-effort would be significant: simply require
> "manager-jmx" for set/invoke operations and require either manager-jmx
> or manager-jmx-read-only (or something similar) for get operations.
>
>

Re: Any interest in a read-only JMX role?

[Konstantin Kolinko]

пн, 13 июн. 2022 г. в 19:32, Christopher Schultz :
>
> All,
>
> I've been thinking about the possibility of making a read-only JMX role
> available for the existing manager-jmx capability.
>
> [...]
>
> Does anyone think this is a good idea?
>

I think it is a bad idea, because passwords (and maybe other secrets)
are visible through JMX, by design.

It might be worth to have some "status" role,
but it has to be defined more specifically than just a "view all" role.

Maybe the way to achieve the same result is to amend the server status page,
which is already provided by the manager app and has a dedicated role.

Best regards,
Konstantin Kolinko.

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

Any interest in a read-only JMX role?

[Christopher Schultz]

All,

I've been thinking about the possibility of making a read-only JMX role 
available for the existing manager-jmx capability.


The idea would be that this role would only be able to make "get" 
requests (that is, a JMX-get operation, not HTTP-GET). No "set" or 
"invoke" operations would be allowed.


The manager-jmx role has quite a bit of power, and is typically used 
only for monitoring where being able to modify the server is not 
necessary. If manager-jmx is being used "only" for monitoring, then 
opening-up the system for potential reconfiguration by the monitoring 
user is a potential attack vector.


I don't think the level-of-effort would be significant: simply require 
"manager-jmx" for set/invoke operations and require either manager-jmx 
or manager-jmx-read-only (or something similar) for get operations.


Does anyone think this is a good idea?

I for one use jmxproxy at $work for both monitoring /and/ administrative 
tasks such as restarting applications, listing users, and initiating 
garbage collection (in very rare cases). For these full-write purposes, 
I could continue to use the (full) jmxproxy role, but for the 
monitoring-only ones, it would be nice to lock things down to the 
absolute minimum.


-chris

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

Re: [ANN] Apache Tomcat 8.5.81 available

[Christopher Schultz]

Li,

On 6/13/22 08:26, Han Li wrote:




2022年6月13日 01:44，Christopher Schultz  写道：

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.81.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 8.5.81 is a bugfix and feature release. The notable
changes compared to 8.5.79 include:

- Ensure that changes made to a request by the RemoteIPValve persist
  after the request is put into asynchronous mode.

- Correct a regression in the support added for encrypted PKCS#1
  formatted private keys in the previous release that broke support
  for unencrypted PKCS#1 formatted private keys.

- Increase the default buffer size for cluster messages from 43800
  to 65536 bytes. This is expected to improve performance for large
  messages when running on Linux based systems.

- When using TLS with non-blocking writes and the NIO connector,
  ensure that flushing the buffers attempts to empty all of the
  output buffers.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



Hi, Christopher.

I think you may have forgotten to update changelog, which is still  8.5.79.
：）


The changelog has been updated. You may be seeing a cached page from the 
CDN. Please let me know if it's still showing the old version.


-chris

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

[tomcat] branch 8.5.x updated: Provide a dedicated logger for TLS handshake failures

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 95aa22e6dc Provide a dedicated logger for TLS handshake failures
95aa22e6dc is described below

commit 95aa22e6dc493fbac81e2ac94896fde40463e492
Author: Mark Thomas 
AuthorDate: Mon Jun 13 17:07:23 2022 +0100

Provide a dedicated logger for TLS handshake failures
---
 java/org/apache/tomcat/util/net/LocalStrings.properties   | 3 +--
 java/org/apache/tomcat/util/net/LocalStrings_fr.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_ja.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_ko.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_zh_CN.properties | 1 -
 java/org/apache/tomcat/util/net/Nio2Endpoint.java | 6 --
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 6 --
 java/org/apache/tomcat/util/net/SecureNio2Channel.java| 4 +---
 java/org/apache/tomcat/util/net/SecureNioChannel.java | 4 +---
 webapps/docs/changelog.xml| 9 +
 webapps/docs/ssl-howto.xml| 5 +
 11 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/LocalStrings.properties 
b/java/org/apache/tomcat/util/net/LocalStrings.properties
index 77add9f56f..18a006139b 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=Unexpected 
status [{0}] during hand
 channel.nio.ssl.unexpectedStatusDuringWrap=Unexpected status [{0}] during 
handshake WRAP.
 channel.nio.ssl.unwrapFail=Unable to unwrap data, invalid status [{0}]
 channel.nio.ssl.unwrapFailResize=Unable to unwrap data because buffer is too 
small, invalid status [{0}]
-channel.nio.ssl.wrapException=Handshake failed during wrap
 channel.nio.ssl.wrapFail=Unable to wrap data, invalid status [{0}]
 
 endpoint.accept.fail=Socket accept failed
@@ -83,7 +82,7 @@ endpoint.err.accept=Failed to accept socket for end point 
[{0}]
 endpoint.err.attach=Failed to attach SSLContext to socket - error [{0}]
 endpoint.err.close=Caught exception trying to close socket
 endpoint.err.duplicateAccept=Duplicate socket accept detected. This is a known 
Linux kernel bug. The original connection has been processed normally and the 
duplicate has been ignored. The client should be unaffected. Updating the OS to 
a version that uses kernel 5.10 or later should fix the duplicate accept bug.
-endpoint.err.handshake=Handshake failed
+endpoint.err.handshake=Handshake failed for client connection from IP address 
[{0}] and port [{1}]
 endpoint.err.unexpected=Unexpected error processing socket
 endpoint.executor.fail=Executor rejected socket [{0}] for processing
 endpoint.getAttribute=[{0}] is [{1}]
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_fr.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
index 0a638eef41..b259f21dea 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=Statut inattendu 
[{0}] lors de l''U
 channel.nio.ssl.unexpectedStatusDuringWrap=Statut inattendu [{0}] lors du WRAP 
de la négociation
 channel.nio.ssl.unwrapFail=Incapable de désenrober les données ("unwrap 
data"), statut invalide [{0}]
 channel.nio.ssl.unwrapFailResize=Impossible de faire l''unwrap des données 
parce que le tampon est trop petit, statut invalide [{0}]
-channel.nio.ssl.wrapException=La négociation a échouée pendant le wrap
 channel.nio.ssl.wrapFail=Impossible d''enrober (wrap) les données, le status 
est invalide [{0}]
 
 endpoint.accept.fail=Aucun socket n'a pu être accepté
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_ja.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
index 6d8d1e1f67..a6e74bd6fc 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=UNWRAPハンドシェイク中に
 channel.nio.ssl.unexpectedStatusDuringWrap=ハンドシェイクWRAP中に予期しないステータス [{0}] 
が発生しました。
 channel.nio.ssl.unwrapFail=データをアンラップできません、無効なステータス [{0}]
 channel.nio.ssl.unwrapFailResize=バッファが小さすぎるためデータをアンラップできません。無効なステータス [{0}]
-channel.nio.ssl.wrapException=ラップ中にハンドシェイクに失敗しました
 channel.nio.ssl.wrapFail=データをラップできません。無効なステータス [{0}]
 
 endpoint.accept.fail=ソケット受け付け失敗
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_ko.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_ko.properties
index 20e6856310..098943a92a 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_ko.properties
+++ 

[tomcat] branch 9.0.x updated: Provide a dedicated logger for TLS handshake failures

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new bbaa645028 Provide a dedicated logger for TLS handshake failures
bbaa645028 is described below

commit bbaa64502884c4fdded3e343e0f471cd56117379
Author: Mark Thomas 
AuthorDate: Mon Jun 13 17:07:23 2022 +0100

Provide a dedicated logger for TLS handshake failures
---
 java/org/apache/tomcat/util/net/LocalStrings.properties   | 3 +--
 java/org/apache/tomcat/util/net/LocalStrings_fr.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_ja.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_ko.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_zh_CN.properties | 1 -
 java/org/apache/tomcat/util/net/Nio2Endpoint.java | 6 --
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 6 --
 java/org/apache/tomcat/util/net/SecureNio2Channel.java| 4 +---
 java/org/apache/tomcat/util/net/SecureNioChannel.java | 4 +---
 webapps/docs/changelog.xml| 9 +
 webapps/docs/ssl-howto.xml| 5 +
 11 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/LocalStrings.properties 
b/java/org/apache/tomcat/util/net/LocalStrings.properties
index ec95a7f8c2..b184b922fa 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=Unexpected 
status [{0}] during hand
 channel.nio.ssl.unexpectedStatusDuringWrap=Unexpected status [{0}] during 
handshake WRAP.
 channel.nio.ssl.unwrapFail=Unable to unwrap data, invalid status [{0}]
 channel.nio.ssl.unwrapFailResize=Unable to unwrap data because buffer is too 
small, invalid status [{0}]
-channel.nio.ssl.wrapException=Handshake failed during wrap
 channel.nio.ssl.wrapFail=Unable to wrap data, invalid status [{0}]
 
 endpoint.accept.fail=Socket accept failed
@@ -83,7 +82,7 @@ endpoint.err.accept=Failed to accept socket for end point 
[{0}]
 endpoint.err.attach=Failed to attach SSLContext to socket - error [{0}]
 endpoint.err.close=Caught exception trying to close socket
 endpoint.err.duplicateAccept=Duplicate socket accept detected. This is a known 
Linux kernel bug. The original connection has been processed normally and the 
duplicate has been ignored. The client should be unaffected. Updating the OS to 
a version that uses kernel 5.10 or later should fix the duplicate accept bug.
-endpoint.err.handshake=Handshake failed
+endpoint.err.handshake=Handshake failed for client connection from IP address 
[{0}] and port [{1}]
 endpoint.err.unexpected=Unexpected error processing socket
 endpoint.executor.fail=Executor rejected socket [{0}] for processing
 endpoint.getAttribute=[{0}] is [{1}]
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_fr.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
index 6d66394291..7adddcb8dc 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=Statut inattendu 
[{0}] lors de l''U
 channel.nio.ssl.unexpectedStatusDuringWrap=Statut inattendu [{0}] lors du WRAP 
de la négociation
 channel.nio.ssl.unwrapFail=Incapable de désenrober les données ("unwrap 
data"), statut invalide [{0}]
 channel.nio.ssl.unwrapFailResize=Impossible de faire l''unwrap des données 
parce que le tampon est trop petit, statut invalide [{0}]
-channel.nio.ssl.wrapException=La négociation a échouée pendant le wrap
 channel.nio.ssl.wrapFail=Impossible d''enrober (wrap) les données, le status 
est invalide [{0}]
 
 endpoint.accept.fail=Aucun socket n'a pu être accepté
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_ja.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
index fe3d6b12ae..0d475595d4 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=UNWRAPハンドシェイク中に
 channel.nio.ssl.unexpectedStatusDuringWrap=ハンドシェイクWRAP中に予期しないステータス [{0}] 
が発生しました。
 channel.nio.ssl.unwrapFail=データをアンラップできません、無効なステータス [{0}]
 channel.nio.ssl.unwrapFailResize=バッファが小さすぎるためデータをアンラップできません。無効なステータス [{0}]
-channel.nio.ssl.wrapException=ラップ中にハンドシェイクに失敗しました
 channel.nio.ssl.wrapFail=データをラップできません。無効なステータス [{0}]
 
 endpoint.accept.fail=ソケット受け付け失敗
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_ko.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_ko.properties
index 16589df848..b874586e61 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_ko.properties
+++ 

[tomcat] branch 10.0.x updated: Provide a dedicated logger for TLS handshake failures

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/10.0.x by this push:
 new 8e3bdb5f94 Provide a dedicated logger for TLS handshake failures
8e3bdb5f94 is described below

commit 8e3bdb5f94deafb202ec94973d99deea6f4b7f84
Author: Mark Thomas 
AuthorDate: Mon Jun 13 17:07:23 2022 +0100

Provide a dedicated logger for TLS handshake failures
---
 java/org/apache/tomcat/util/net/LocalStrings.properties   | 3 +--
 java/org/apache/tomcat/util/net/LocalStrings_fr.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_ja.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_ko.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_zh_CN.properties | 1 -
 java/org/apache/tomcat/util/net/Nio2Endpoint.java | 6 --
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 6 --
 java/org/apache/tomcat/util/net/SecureNio2Channel.java| 4 +---
 java/org/apache/tomcat/util/net/SecureNioChannel.java | 4 +---
 webapps/docs/changelog.xml| 9 +
 webapps/docs/ssl-howto.xml| 5 +
 11 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/LocalStrings.properties 
b/java/org/apache/tomcat/util/net/LocalStrings.properties
index ec95a7f8c2..b184b922fa 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=Unexpected 
status [{0}] during hand
 channel.nio.ssl.unexpectedStatusDuringWrap=Unexpected status [{0}] during 
handshake WRAP.
 channel.nio.ssl.unwrapFail=Unable to unwrap data, invalid status [{0}]
 channel.nio.ssl.unwrapFailResize=Unable to unwrap data because buffer is too 
small, invalid status [{0}]
-channel.nio.ssl.wrapException=Handshake failed during wrap
 channel.nio.ssl.wrapFail=Unable to wrap data, invalid status [{0}]
 
 endpoint.accept.fail=Socket accept failed
@@ -83,7 +82,7 @@ endpoint.err.accept=Failed to accept socket for end point 
[{0}]
 endpoint.err.attach=Failed to attach SSLContext to socket - error [{0}]
 endpoint.err.close=Caught exception trying to close socket
 endpoint.err.duplicateAccept=Duplicate socket accept detected. This is a known 
Linux kernel bug. The original connection has been processed normally and the 
duplicate has been ignored. The client should be unaffected. Updating the OS to 
a version that uses kernel 5.10 or later should fix the duplicate accept bug.
-endpoint.err.handshake=Handshake failed
+endpoint.err.handshake=Handshake failed for client connection from IP address 
[{0}] and port [{1}]
 endpoint.err.unexpected=Unexpected error processing socket
 endpoint.executor.fail=Executor rejected socket [{0}] for processing
 endpoint.getAttribute=[{0}] is [{1}]
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_fr.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
index 6d66394291..7adddcb8dc 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=Statut inattendu 
[{0}] lors de l''U
 channel.nio.ssl.unexpectedStatusDuringWrap=Statut inattendu [{0}] lors du WRAP 
de la négociation
 channel.nio.ssl.unwrapFail=Incapable de désenrober les données ("unwrap 
data"), statut invalide [{0}]
 channel.nio.ssl.unwrapFailResize=Impossible de faire l''unwrap des données 
parce que le tampon est trop petit, statut invalide [{0}]
-channel.nio.ssl.wrapException=La négociation a échouée pendant le wrap
 channel.nio.ssl.wrapFail=Impossible d''enrober (wrap) les données, le status 
est invalide [{0}]
 
 endpoint.accept.fail=Aucun socket n'a pu être accepté
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_ja.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
index fe3d6b12ae..0d475595d4 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=UNWRAPハンドシェイク中に
 channel.nio.ssl.unexpectedStatusDuringWrap=ハンドシェイクWRAP中に予期しないステータス [{0}] 
が発生しました。
 channel.nio.ssl.unwrapFail=データをアンラップできません、無効なステータス [{0}]
 channel.nio.ssl.unwrapFailResize=バッファが小さすぎるためデータをアンラップできません。無効なステータス [{0}]
-channel.nio.ssl.wrapException=ラップ中にハンドシェイクに失敗しました
 channel.nio.ssl.wrapFail=データをラップできません。無効なステータス [{0}]
 
 endpoint.accept.fail=ソケット受け付け失敗
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_ko.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_ko.properties
index 16589df848..b874586e61 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_ko.properties
+++ 

[tomcat] branch main updated: Provide a dedicated logger for TLS handshake failures

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
 new 69b9a3 Provide a dedicated logger for TLS handshake failures
69b9a3 is described below

commit 69b9a341062dc1930782941bbaa1880e9281
Author: Mark Thomas 
AuthorDate: Mon Jun 13 17:07:23 2022 +0100

Provide a dedicated logger for TLS handshake failures
---
 java/org/apache/tomcat/util/net/LocalStrings.properties   | 3 +--
 java/org/apache/tomcat/util/net/LocalStrings_fr.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_ja.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_ko.properties| 1 -
 java/org/apache/tomcat/util/net/LocalStrings_zh_CN.properties | 1 -
 java/org/apache/tomcat/util/net/Nio2Endpoint.java | 6 --
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 6 --
 java/org/apache/tomcat/util/net/SecureNio2Channel.java| 4 +---
 java/org/apache/tomcat/util/net/SecureNioChannel.java | 4 +---
 webapps/docs/changelog.xml| 9 +
 webapps/docs/ssl-howto.xml| 5 +
 11 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/LocalStrings.properties 
b/java/org/apache/tomcat/util/net/LocalStrings.properties
index 0cac5ed270..847d01144a 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=Unexpected 
status [{0}] during hand
 channel.nio.ssl.unexpectedStatusDuringWrap=Unexpected status [{0}] during 
handshake WRAP.
 channel.nio.ssl.unwrapFail=Unable to unwrap data, invalid status [{0}]
 channel.nio.ssl.unwrapFailResize=Unable to unwrap data because buffer is too 
small, invalid status [{0}]
-channel.nio.ssl.wrapException=Handshake failed during wrap
 channel.nio.ssl.wrapFail=Unable to wrap data, invalid status [{0}]
 
 endpoint.accept.fail=Socket accept failed
@@ -67,7 +66,7 @@ endpoint.debug.unlock.localNone=Failed to unlock acceptor for 
[{0}] because the
 endpoint.duplicateSslHostName=Multiple SSLHostConfig elements were provided 
for the host name [{0}]. Host names must be unique.
 endpoint.err.close=Caught exception trying to close socket
 endpoint.err.duplicateAccept=Duplicate socket accept detected. This is a known 
Linux kernel bug. The original connection has been processed normally and the 
duplicate has been ignored. The client should be unaffected. Updating the OS to 
a version that uses kernel 5.10 or later should fix the duplicate accept bug.
-endpoint.err.handshake=Handshake failed
+endpoint.err.handshake=Handshake failed for client connection from IP address 
[{0}] and port [{1}]
 endpoint.err.unexpected=Unexpected error processing socket
 endpoint.executor.fail=Executor rejected socket [{0}] for processing
 endpoint.getAttribute=[{0}] is [{1}]
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_fr.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
index 15f147ffba..7bd57dc9bc 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings_fr.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=Statut inattendu 
[{0}] lors de l''U
 channel.nio.ssl.unexpectedStatusDuringWrap=Statut inattendu [{0}] lors du WRAP 
de la négociation
 channel.nio.ssl.unwrapFail=Incapable de désenrober les données ("unwrap 
data"), statut invalide [{0}]
 channel.nio.ssl.unwrapFailResize=Impossible de faire l''unwrap des données 
parce que le tampon est trop petit, statut invalide [{0}]
-channel.nio.ssl.wrapException=La négociation a échouée pendant le wrap
 channel.nio.ssl.wrapFail=Impossible d''enrober (wrap) les données, le status 
est invalide [{0}]
 
 endpoint.accept.fail=Aucun socket n'a pu être accepté
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_ja.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
index fde1f981aa..0121306b16 100644
--- a/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
+++ b/java/org/apache/tomcat/util/net/LocalStrings_ja.properties
@@ -41,7 +41,6 @@ channel.nio.ssl.unexpectedStatusDuringUnwrap=UNWRAPハンドシェイク中に
 channel.nio.ssl.unexpectedStatusDuringWrap=ハンドシェイクWRAP中に予期しないステータス [{0}] 
が発生しました。
 channel.nio.ssl.unwrapFail=データをアンラップできません、無効なステータス [{0}]
 channel.nio.ssl.unwrapFailResize=バッファが小さすぎるためデータをアンラップできません。無効なステータス [{0}]
-channel.nio.ssl.wrapException=ラップ中にハンドシェイクに失敗しました
 channel.nio.ssl.wrapFail=データをラップできません。無効なステータス [{0}]
 
 endpoint.accept.fail=ソケット受け付け失敗
diff --git a/java/org/apache/tomcat/util/net/LocalStrings_ko.properties 
b/java/org/apache/tomcat/util/net/LocalStrings_ko.properties
index 5c003487db..342304180e 100644
--- 

[tomcat] branch 10.0.x updated: Remove note discussing deprecated and removed configuration options

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/10.0.x by this push:
 new f5671f21d8 Remove note discussing deprecated and removed configuration 
options
f5671f21d8 is described below

commit f5671f21d897e918f266d89fb941328c5bedf97c
Author: Mark Thomas 
AuthorDate: Mon Jun 13 16:31:32 2022 +0100

Remove note discussing deprecated and removed configuration options
---
 webapps/docs/config/http.xml | 9 -
 1 file changed, 9 deletions(-)

diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml
index 06283c7058..d95e5c8b3a 100644
--- a/webapps/docs/config/http.xml
+++ b/webapps/docs/config/http.xml
@@ -1248,15 +1248,6 @@
   Certificate. The types of the Certificates
   must be unique.
 
-  As of Tomcat 8.5, the majority of the SSL configuration attributes in the
-  Connector are deprecated. If specified, they will be used to
-  configure a SSLHostConfig and Certificate
-  for the defaultSSLHostConfigName. Note that if an explicit
-  SSLHostConfig element also exists for the
-  defaultSSLHostConfigName then that will be treated as a 
configuration
-  error. It is expected that Tomcat 10 will drop support for the SSL
-  configuration attributes in the Connector.
-
   In addition to the standard TLS related request attributes defined in
   section 3.10 of the Servlet specification, Tomcat supports a number of
   additional TLS related attributes. The full list may be found in the 

[tomcat] branch main updated: Remove note discussing deprecated and removed configuration options

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
 new c6e0e9ce40 Remove note discussing deprecated and removed configuration 
options
c6e0e9ce40 is described below

commit c6e0e9ce404f6f5bb964a77bce1e42e7c99b73f5
Author: Mark Thomas 
AuthorDate: Mon Jun 13 16:31:32 2022 +0100

Remove note discussing deprecated and removed configuration options
---
 webapps/docs/config/http.xml | 9 -
 1 file changed, 9 deletions(-)

diff --git a/webapps/docs/config/http.xml b/webapps/docs/config/http.xml
index 7eb6a727d4..1cee41818e 100644
--- a/webapps/docs/config/http.xml
+++ b/webapps/docs/config/http.xml
@@ -1155,15 +1155,6 @@
   Certificate. The types of the Certificates
   must be unique.
 
-  As of Tomcat 8.5, the majority of the SSL configuration attributes in the
-  Connector are deprecated. If specified, they will be used to
-  configure a SSLHostConfig and Certificate
-  for the defaultSSLHostConfigName. Note that if an explicit
-  SSLHostConfig element also exists for the
-  defaultSSLHostConfigName then that will be treated as a 
configuration
-  error. It is expected that Tomcat 10 will drop support for the SSL
-  configuration attributes in the Connector.
-
   In addition to the standard TLS related request attributes defined in
   section 3.10 of the Servlet specification, Tomcat supports a number of
   additional TLS related attributes. The full list may be found in the 

svn commit: r1901880 - in /tomcat/site/trunk: docs/security-8.html xdocs/security-8.xml

[markt]

Author: markt
Date: Mon Jun 13 14:04:21 2022
New Revision: 1901880

URL: http://svn.apache.org/viewvc?rev=1901880=rev
Log:
Add release date for 8.5.79

Modified:
tomcat/site/trunk/docs/security-8.html
tomcat/site/trunk/xdocs/security-8.xml

Modified: tomcat/site/trunk/docs/security-8.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-8.html?rev=1901880=1901879=1901880=diff
==
--- tomcat/site/trunk/docs/security-8.html (original)
+++ tomcat/site/trunk/docs/security-8.html Mon Jun 13 14:04:21 2022
@@ -43,7 +43,7 @@
 
   Table of Contents
 Fixed in Apache Tomcat 
8.5.79Fixed in Apache 
Tomcat 8.5.76Fixed in 
Apache Tomcat 8.5.75Fixed 
in Apache Tomcat 8.5.72Fixed in Apache Tomcat 
8.5.68Fixed in Apache 
Tomcat 8.5.66Fixed in 
Apache Tomcat 8.5.65Fixed 
in Apache Tomcat 8.5.64Fixed in Apache Tomcat 
8.5.63Fixed in Apache 
Tomcat 8.5.60Fixed in 
Apache Tomcat 8.5.58Fixed 
in Apache Tomcat 8.5.57Fixed in Apache Tomcat 
8.5.56Fixed in Apache 
Tomcat 8.5.55Fixed in 
Apache Tomcat 8.5.51Fixed 
in Apache Tomcat 8.5.50Fixed in Apache Tomcat 
8.5.49Fixed in Apache 
Tomcat 8.5.41Fixed in 
Apache Tomcat 8.5.40Fixed 
in Apache Tomcat 8.5.38Fixed in Apache Tomcat 
8.5.34Fixed in Apache 
Tomcat 8.0.53Fixed in 
Apache Tomcat 8.5.32Fixed 
in Apache Tomcat 8.0.52Fixed in Apache Tomcat 
 >8.5.31Fixed in Apache 
 >Tomcat 8.0.50Fixed in 
 >Apache Tomcat 8.5.28href="#Fixed_in_Apache_Tomcat_8.0.48">Fixed in Apache Tomcat 
 >8.0.48Fixed in Apache 
 >Tomcat 8.5.24Fixed in 
 >Apache Tomcat 8.0.47href="#Fixed_in_Apache_Tomcat_8.5.23">Fixed in Apache Tomcat 
 >8.5.23Fixed in Apache 
 >Tomcat 8.0.45Fixed in 
 >Apache Tomcat 8.5.16href="#Fixed_in_Apache_Tomcat_8.0.44">Fixed in Apache Tomcat 
 >8.0.44Fixed in Apache 
 >Tomcat 8.5.15Fixed in 
 >Apache Tomcat 8.0.43
 Fixed in Apache Tomcat 
8.5.13Fixed in Apache 
Tomcat 8.0.42Fixed in 
Apache Tomcat 8.5.12Fixed 
in Apache Tomcat 8.0.41Fixed in Apache Tomcat 
8.5.11Fixed in Apache 
Tomcat 8.5.9Fixed in 
Apache Tomcat 8.0.39Fixed 
in Apache Tomcat 8.5.8Fixed in Apache Tomcat 8.5.5 
and 8.0.37Fixed 
in Apache Tomcat 8.5.3 and 8.0.36Fixed in Apache Tomcat 
8.0.32Fixed in Apache Tomcat 8.0.30Fixed in Apache Tomcat 
8.0.27Fixed in Apache 
Tomcat 8.0.17Fixed in 
Apache Tomcat 8.0.9Fixed 
in Apache Tomcat 8.0.8Fixed in Apache Tomcat 
8.0.5Fixed in Apache 
Tomcat 8.0.3Fixed in 
Apache Tomcat 8.0.0-RC10Fixed in Apache Tomcat 
8.0.0-RC3Not a 
vulnerability in TomcatNot a vulnerability in 
Tomcat
-  not 
yet released Fixed in Apache Tomcat 8.5.79
+  2022-05-23 Fixed in Apache Tomcat 8.5.79
   
 Low: Apache Tomcat EncryptInterceptor DoS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29885; 
rel="nofollow">CVE-2022-29885

Modified: tomcat/site/trunk/xdocs/security-8.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-8.xml?rev=1901880=1901879=1901880=diff
==
--- tomcat/site/trunk/xdocs/security-8.xml (original)
+++ tomcat/site/trunk/xdocs/security-8.xml Mon Jun 13 14:04:21 2022
@@ -56,7 +56,7 @@
 
   
 
-  
+  
   
 Low: Apache Tomcat EncryptInterceptor DoS
CVE-2022-29885



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

JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1

[David Delabassee]

Greetings!

JDK 19 has now entered Rampdown Phase One (RDP1) [1], which means that 
the main-line has been forked into a dedicated JDK 19 stabilization 
repository. At this point, the overall JDK 19 feature set is frozen and 
no additional JEPs will be targeted to JDK 19. The stabilization 
repository is open for select bug fixes and, with approval, late 
low-risk enhancements per the JDK Release Process [2]. Any change pushed 
to the main line is now bound for JDK 20, unless it is explicitly 
back-ported to JDK 19.


The next few weeks should be leveraged to try to identify and resolve as 
many issues as possible, i.e. before JDK 19 enters the Release 
Candidates phase. Moreover, we encourage you to test your project with 
the `enable-preview` flag as described in this Quality Outreach Heads-up 
[3], and even if you don't intend to use Virtual Threads in the near future.


[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-June/006735.html
[2] https://openjdk.java.net/jeps/3
[3] https://inside.java/2022/05/16/quality-heads-up/


## Heads-up - openjdk.java.net ➜ openjdk.org DNS transition

The OpenJDK infrastructure is moving from the old openjdk.java.net 
subdomain to the openjdk.org top-level domain. This will affect all 
active subdomains (i.e., bugs, cr, db, git, hg, mail, and wiki) and the 
old hostnames (*.openjdk.java.net) will now act as aliases for the new 
names. No actions are required as this transition should be transparent 
and is mostly done. It should be mentioned that https://jdk.java.net/ is 
not changing.


More infirmation can be found in the original proposal 
https://mail.openjdk.java.net/pipermail/discuss/2022-May/006089.html



## JDK 19 Early-Access builds

JDK 19 Early-Access builds 26 are now available [4], and are provided 
under the GNU General Public License v2, with the Classpath Exception. 
The Release Notes are available here [5]. Given that JDK 19 is now in 
RDP1, the initial JDK 20 Early-Access builds are now also available [6].


[4] https://jdk.java.net/19/
[5] https://jdk.java.net/19/release-notes
[6] https://jdk.java.net/20/


### JEPs integrated to JDK 19:
- JEP 405: Record Patterns (Preview)
- JEP 422: Linux/RISC-V Port
- JEP 424: Foreign Function & Memory API (Preview)
- JEP 425: Virtual Threads (Preview)
- JEP 426: Vector API (Fourth Incubator)
- JEP 427: Pattern Matching for switch (Third Preview)
- JEP 428: Structured Concurrency (Incubator)

### Recent changes that may be of interest:

Build 26:
- JDK-8284199: Implementation of Structured Concurrency (Incubator)
- JDK-8282662: Use List.of() factory method to reduce memory consumption
- JDK-8284780: Need methods to create pre-sized HashSet and LinkedHashSet
- JDK-8250950: Allow per-user and system wide configuration of a 
jpackaged app
- JDK-8236569: -Xss not multiple of 4K does not work for the main thread 
on macOS

- JDK-4511638: Double.toString(double) sometimes produces incorrect results
- JDK-8287714: Improve handling of JAVA_ARGS
- JDK-8286850: [macos] Add support for signing user provided app image
- JDK-8287425: Remove unnecessary register push for MacroAssembler::check_k…
- JDK-8283694: Improve bit manipulation and boolean to integer conversion o…
- JDK-8287522: StringConcatFactory: Add in prependers and mixers in batches

Build 25:
- JDK-8284960: Integration of JEP 426: Vector API (Fourth Incubator)
- JDK-8287244: Add bound check in indexed memory access var handle
- JDK-8287292: Improve TransformKey to pack more kinds of transforms effici…
- JDK-8287003: InputStreamReader::read() can return zero despite writing a …
- JDK-8287064: Modernize ProxyGenerator.PrimitiveTypeInfo

Build 24:
- JDK-8286908: ECDSA signature should not return parameters
- JDK-8261768: SelfDestructTimer should accept seconds
- JDK-8286304: Removal of diagnostic flag GCParallelVerificationEnabled
- JDK-8267038: Update IANA Language Subtag Registry to Version 2022-03-02
- JDK-8285517: System.getenv() returns unexpected value if environment vari…
- JDK-8285513: JFR: Add more static support for event classes
- JDK-8287024: G1: Improve the API boundary between HeapRegionRemSet and G1…
- JDK-8287139: aarch64 intrinsic for unsignedMultiplyHigh

Build 23:
- JDK-8282191: Implementation of Foreign Function & Memory API (Preview)
- JDK-8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms
- JDK-8282080: Lambda deserialization fails for Object method references 
on interfaces
- JDK-6782021: It is not possible to read local computer certificates 
with the SunMSCAPI provider

- JDK-8282191: Implementation of Foreign Function & Memory API (Preview)
- JDK-8284194: Allow empty subject fields in keytool
- JDK-8209137: Add ability to bind to specific local address to HTTP client
- JDK-8286841: Add BigDecimal.TWO
- JDK-8287139: aarch64 intrinsic for unsignedMultiplyHigh
- JDK-8282160: JShell circularly-required classes cannot be defined
- JDK-8282280: Update Xerces to Version 2.12.2


## Topics of Interest

* Replacing Finalizers with 

Re: [ANN] Apache Tomcat 8.5.81 available

[Han Li]

> 2022年6月13日 01:44，Christopher Schultz  写道：
> 
> The Apache Tomcat team announces the immediate availability of Apache
> Tomcat 8.5.81.
> 
> Apache Tomcat 8 is an open source software implementation of the Java
> Servlet, JavaServer Pages, Java Unified Expression Language, Java
> WebSocket and JASPIC technologies.
> 
> Apache Tomcat 8.5.81 is a bugfix and feature release. The notable
> changes compared to 8.5.79 include:
> 
> - Ensure that changes made to a request by the RemoteIPValve persist
>  after the request is put into asynchronous mode.
> 
> - Correct a regression in the support added for encrypted PKCS#1
>  formatted private keys in the previous release that broke support
>  for unencrypted PKCS#1 formatted private keys.
> 
> - Increase the default buffer size for cluster messages from 43800
>  to 65536 bytes. This is expected to improve performance for large
>  messages when running on Linux based systems.
> 
> - When using TLS with non-blocking writes and the NIO connector,
>  ensure that flushing the buffers attempts to empty all of the
>  output buffers.
> 
> Along with lots of other bug fixes and improvements.
> 
> Please refer to the change log for the complete list of changes:
> https://tomcat.apache.org/tomcat-8.5-doc/changelog.html
> 
> 
> Downloads:
> https://tomcat.apache.org/download-80.cgi
> 
> Migration guides from Apache Tomcat 7.x and 8.0:
> https://tomcat.apache.org/migration.html
> 
> Enjoy!
> 
> - The Apache Tomcat team
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Hi, Christopher.

I think you may have forgotten to update changelog, which is still  8.5.79.
：）

Han Li


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

Re: log4j-appserver module migration

[Piotr P. Karwasz]

Hi Mark,

On Sat, 11 Jun 2022 at 09:48, Mark Thomas  wrote:
>
> Why can't web applications just use:
>
> https://logging.apache.org/log4j/2.x/log4j-jul/index.html
>
> ?

Web applications usually contain libraries that use a variety of
logging APIs (Spring uses JCL, Hibernate JBoss Logging, others use
SLF4J API or Log4j2); `java.util.logging` is almost never used. The
jars for these APIs are distributed in the WAR archive, allowing the
application to work on several servlet containers. Frameworks such as
Spring Boot or the developers of the app themselves take care of
bridging all these APIs to a single one.

Using the `LogManager` implementation in `log4j-jul` would accomplish
the job of forwarding Tomcat server's logs to Log4j2, but it will also
hijack the logs from webapp libraries that use `java.util.logging`. So
one would end up with several mixed up logging contexts: one with
Tomcat server's logs + JUL logs from the webapps and one context for
each web application.

The purpose of `log4j-appserver` is to forward Tomcat server's logs
directly to Log4j2, without messing up with the default
`ClassLoaderLogManager`. The `ClassLoaderLogManager` allows every web
application to forward JUL logs to its own copy of the Log4j2 API.
This provides an order, yet not ideal situation, where all logs from
the server itself uses a copy of `log4j-api` in the common/server
classloader, while each application uses its own copy of `log4j-api`.

> There seem to be more logging frameworks than application servers these
> days. I don't really want to start down the road of adding a JUL
> implementation for every one of them.

There aren't so many logging frameworks if you count the
implementations (not the APIs). Basically there is Logback and Log4j2
Core, while JBoss LogManager is used in full Java EE servers. The APIs
are strongly connected (there is a bridge between any major API and
Log4j2 Core or Logback), so adding a single JULI implementation would
be enough to use any logging backend. This sums up to about 200 lines
of code:

https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-appserver/src/main/java/org/apache/logging/log4j/appserver/tomcat/TomcatLogger.java

The SLF4J implementation is similar (https://github.com/tomcat-slf4j-logback).

I think it would be nice to see these two in the Tomcat project
instead of Log4j2 and a Github repository. The main advantage I see is
that I could enhance them with the features present in the standard
Tomcat JULI implementation (basically the `${classloader.*}` variable
substitution).

Piotr

PS: Contrary to what I wrote in my first mail, if a web application
contains the `log4j-api.jar` it is overly complicated to forward its
logging to another copy of `log4j-api.jar` in the common classloader,
without inverting the delegation model.

Having a single `log4j-api/log4j-core` driving the logging of several
web applications is beneficial: each web app can have a different
logging configuration, but due to the architecture of Log4j2 Core,
each log file will be opened at most once.

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