(tomcat) branch 10.1.x updated (ed83bb9fbf -> ccb68ff474)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch 10.1.x in repository https://gitbox.apache.org/repos/asf/tomcat.git from ed83bb9fbf Explain the Java 22 check new e02be5c7d5 Add support for JSP compilation using Java 22 new ccb68ff474 Add release date for 10.1.19 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: java/org/apache/jasper/compiler/JDTCompiler.java | 27 +--- webapps/docs/changelog.xml | 13 +++- 2 files changed, 31 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) 02/02: Add release date for 10.1.19
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 10.1.x in repository https://gitbox.apache.org/repos/asf/tomcat.git commit ccb68ff4742caa30b531021039df3bf45e13a4eb Author: Mark Thomas AuthorDate: Tue Feb 27 08:55:41 2024 + Add release date for 10.1.19 --- webapps/docs/changelog.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index d9e39d5d32..8ebde7195b 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -124,7 +124,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) 01/02: Add support for JSP compilation using Java 22
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit e02be5c7d5438ee63f66bc0614875f732f25c4df
Author: Mark Thomas
AuthorDate: Tue Feb 27 08:55:13 2024 +
Add support for JSP compilation using Java 22
---
java/org/apache/jasper/compiler/JDTCompiler.java | 27 +---
webapps/docs/changelog.xml | 11 ++
2 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/java/org/apache/jasper/compiler/JDTCompiler.java
b/java/org/apache/jasper/compiler/JDTCompiler.java
index 2a19f14794..283738d319 100644
--- a/java/org/apache/jasper/compiler/JDTCompiler.java
+++ b/java/org/apache/jasper/compiler/JDTCompiler.java
@@ -318,15 +318,20 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
} else if (opt.equals("19")) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_19);
} else if (opt.equals("20")) {
-// Constant not available in latest ECJ version shipped with
-// Tomcat. May be supported in a snapshot build.
+// Constant not available in ECJ version shipped with
+// Tomcat. May be supported in a later or snapshot build.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_Source, "20");
} else if (opt.equals("21")) {
-// Constant not available in latest ECJ version shipped with
-// Tomcat. May be supported in a snapshot build.
+// Constant not available in ECJ version shipped with
+// Tomcat. May be supported in a later or snapshot build.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_Source, "21");
+} else if (opt.equals("22")) {
+// Constant not available in ECJ version shipped with
+// Tomcat. May be supported in a later or snapshot build.
+// This is checked against the actual version below.
+settings.put(CompilerOptions.OPTION_Source, "22");
} else {
log.warn(Localizer.getMessage("jsp.warning.unknown.sourceVM",
opt));
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_11);
@@ -395,17 +400,23 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_19);
settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_19);
} else if (opt.equals("20")) {
-// Constant not available in latest ECJ version shipped with
-// Tomcat. May be supported in a snapshot build.
+// Constant not available in ECJ version shipped with
+// Tomcat. May be supported in a later or snapshot build.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_TargetPlatform, "20");
settings.put(CompilerOptions.OPTION_Compliance, "20");
} else if (opt.equals("21")) {
-// Constant not available in latest ECJ version shipped with
-// Tomcat. May be supported in a snapshot build.
+// Constant not available in ECJ version shipped with
+// Tomcat. May be supported in a later or snapshot build.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_TargetPlatform, "21");
settings.put(CompilerOptions.OPTION_Compliance, "21");
+} else if (opt.equals("22")) {
+// Constant not available in ECJ version shipped with
+// Tomcat. May be supported in a later or snapshot build.
+// This is checked against the actual version below.
+settings.put(CompilerOptions.OPTION_TargetPlatform, "22");
+settings.put(CompilerOptions.OPTION_Compliance, "22");
} else {
log.warn(Localizer.getMessage("jsp.warning.unknown.targetVM",
opt));
settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_11);
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 3cc6d582fe..d9e39d5d32 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,17 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+Add support for specifying Java 21 (with the value 21) as
+the compiler source and/or compiler target for JSP compilation. If used
+with an Eclipse JDT compiler version that does not support these
values,
+
(tomcat) branch 10.1.x updated: Better comment - aligns with 9.0.x
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new c5bbf38efe Better comment - aligns with 9.0.x
c5bbf38efe is described below
commit c5bbf38efe7b19b4ce35407a3e6d153144090aba
Author: Mark Thomas
AuthorDate: Tue Feb 27 08:59:42 2024 +
Better comment - aligns with 9.0.x
---
java/org/apache/jasper/compiler/JDTCompiler.java | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/java/org/apache/jasper/compiler/JDTCompiler.java
b/java/org/apache/jasper/compiler/JDTCompiler.java
index 283738d319..2179f3a7e7 100644
--- a/java/org/apache/jasper/compiler/JDTCompiler.java
+++ b/java/org/apache/jasper/compiler/JDTCompiler.java
@@ -318,18 +318,18 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
} else if (opt.equals("19")) {
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_19);
} else if (opt.equals("20")) {
-// Constant not available in ECJ version shipped with
-// Tomcat. May be supported in a later or snapshot build.
+// Constant not available in latest ECJ version that runs on
+// Java 11.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_Source, "20");
} else if (opt.equals("21")) {
-// Constant not available in ECJ version shipped with
-// Tomcat. May be supported in a later or snapshot build.
+// Constant not available in latest ECJ version that runs on
+// Java 11.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_Source, "21");
} else if (opt.equals("22")) {
-// Constant not available in ECJ version shipped with
-// Tomcat. May be supported in a later or snapshot build.
+// Constant not available in latest ECJ version that runs on
+// Java 11.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_Source, "22");
} else {
@@ -400,20 +400,20 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_19);
settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_19);
} else if (opt.equals("20")) {
-// Constant not available in ECJ version shipped with
-// Tomcat. May be supported in a later or snapshot build.
+// Constant not available in latest ECJ version that runs on
+// Java 11.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_TargetPlatform, "20");
settings.put(CompilerOptions.OPTION_Compliance, "20");
} else if (opt.equals("21")) {
-// Constant not available in ECJ version shipped with
-// Tomcat. May be supported in a later or snapshot build.
+// Constant not available in latest ECJ version that runs on
+// Java 11.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_TargetPlatform, "21");
settings.put(CompilerOptions.OPTION_Compliance, "21");
} else if (opt.equals("22")) {
-// Constant not available in ECJ version shipped with
-// Tomcat. May be supported in a later or snapshot build.
+// Constant not available in latest ECJ version that runs on
+// Java 11.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_TargetPlatform, "22");
settings.put(CompilerOptions.OPTION_Compliance, "22");
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 10.1.x updated: Fix copy/paste error
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 10.1.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/10.1.x by this push: new 73ae83a602 Fix copy/paste error 73ae83a602 is described below commit 73ae83a602d10257a21134bd5c32a719aa0b49e9 Author: Mark Thomas AuthorDate: Tue Feb 27 09:01:15 2024 + Fix copy/paste error --- webapps/docs/changelog.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 8ebde7195b..0d11f722ed 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -108,7 +108,7 @@ -Add support for specifying Java 21 (with the value 21) as +Add support for specifying Java 22 (with the value 22) as the compiler source and/or compiler target for JSP compilation. If used with an Eclipse JDT compiler version that does not support these values, a warning will be logged and the default will used. - 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 (4e288be9c9 -> 42440c8e69)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch 8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git from 4e288be9c9 Remove old javadoc new 87e34bed3d Add support for JSP compilation with Java 22 new 42440c8e69 Add release date for 8.5.99 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: java/org/apache/jasper/compiler/JDTCompiler.java | 11 +++ webapps/docs/changelog.xml | 13 - 2 files changed, 23 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) 01/02: Add support for JSP compilation with Java 22
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
commit 87e34bed3d21377bedf830d9d03f2ae44e0dcc2f
Author: Mark Thomas
AuthorDate: Tue Feb 27 09:01:47 2024 +
Add support for JSP compilation with Java 22
---
java/org/apache/jasper/compiler/JDTCompiler.java | 11 +++
webapps/docs/changelog.xml | 11 +++
2 files changed, 22 insertions(+)
diff --git a/java/org/apache/jasper/compiler/JDTCompiler.java
b/java/org/apache/jasper/compiler/JDTCompiler.java
index 8ab753b541..487499b7ba 100644
--- a/java/org/apache/jasper/compiler/JDTCompiler.java
+++ b/java/org/apache/jasper/compiler/JDTCompiler.java
@@ -384,6 +384,11 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
// Java 7.
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_Source, "21");
+} else if (opt.equals("22")) {
+// Constant not available in latest ECJ version that runs on
+// Java 7.
+// This is checked against the actual version below.
+settings.put(CompilerOptions.OPTION_Source, "22");
} else {
log.warn(Localizer.getMessage("jsp.warning.unknown.sourceVM",
opt));
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_7);
@@ -493,6 +498,12 @@ public class JDTCompiler extends
org.apache.jasper.compiler.Compiler {
// This is checked against the actual version below.
settings.put(CompilerOptions.OPTION_TargetPlatform, "21");
settings.put(CompilerOptions.OPTION_Compliance, "21");
+} else if (opt.equals("22")) {
+// Constant not available in latest ECJ version that runs on
+// Java 7.
+// This is checked against the actual version below.
+settings.put(CompilerOptions.OPTION_TargetPlatform, "22");
+settings.put(CompilerOptions.OPTION_Compliance, "22");
} else {
log.warn(Localizer.getMessage("jsp.warning.unknown.targetVM",
opt));
settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_7);
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index cfa29db518..37737186fb 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,17 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+Add support for specifying Java 22 (with the value 22) as
+the compiler source and/or compiler target for JSP compilation. If used
+with an Eclipse JDT compiler version that does not support these
values,
+a warning will be logged and the default will used.
+(markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) 02/02: Add release date for 8.5.99
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 commit 42440c8e69e127e7a17cfcc3922d1f8407d4f698 Author: Mark Thomas AuthorDate: Tue Feb 27 09:04:26 2024 + Add release date for 8.5.99 --- webapps/docs/changelog.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 37737186fb..78cd4aa7ce 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -127,7 +127,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
March releases
All, When I look at the current change logs there isn't much there to justify a March release. There are a couple of open bugs of which one looks likely that there is an actual issue to be fixed. That said, I'm unlikely to be in a position to tag 11.0.x until w/c 11 March. The change log may look different at that point. It is probably too early to make a decision but I wanted to float the possibility of skipping the March release. That would mean we'd probably need to make the final 8.5.x release in April. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: March releases
On Tue, Feb 27, 2024 at 10:12 AM Mark Thomas wrote: > > All, > > When I look at the current change logs there isn't much there to justify > a March release. There are a couple of open bugs of which one looks > likely that there is an actual issue to be fixed. > > That said, I'm unlikely to be in a position to tag 11.0.x until w/c 11 > March. The change log may look different at that point. > > It is probably too early to make a decision but I wanted to float the > possibility of skipping the March release. That would mean we'd probably > need to make the final 8.5.x release in April. We don't need to always release all branches every time. For example, 11 already has two useful fixes right now: support for Java 17 (one could want to verify it), then the FFM fix I made (using the wrong loader in one location means it simply breaks depending on how OpenSSL is loaded, so that's bad). But these two are not in the other branches. As for a final 8.5, I would say it is not mandatory if there's nothing useful in the changelog by the end of March. There's always going to be a final final fix needed anyway. I started skipping some backports to 8.5 since "regressions, who knows". Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: March releases
On 27/02/2024 10:57, Rémy Maucherat wrote: On Tue, Feb 27, 2024 at 10:12 AM Mark Thomas wrote: All, When I look at the current change logs there isn't much there to justify a March release. There are a couple of open bugs of which one looks likely that there is an actual issue to be fixed. That said, I'm unlikely to be in a position to tag 11.0.x until w/c 11 March. The change log may look different at that point. It is probably too early to make a decision but I wanted to float the possibility of skipping the March release. That would mean we'd probably need to make the final 8.5.x release in April. We don't need to always release all branches every time. Good point. For example, 11 already has two useful fixes right now: support for Java 17 (one could want to verify it), then the FFM fix I made (using the wrong loader in one location means it simply breaks depending on how OpenSSL is loaded, so that's bad). But these two are not in the other branches. Ack. Those are good reasons for an 11.0.x release. I just checked the dependencies - there are no updates at the moment. As for a final 8.5, I would say it is not mandatory if there's nothing useful in the changelog by the end of March. There's always going to be a final final fix needed anyway. I started skipping some backports to 8.5 since "regressions, who knows". I was just thinking .100 was a nice point release to end on ;) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: TestSsl.testClientInitiatedRenegotiation fails for TC 9 and 8.5
Hi Mark, hi all,
coming back to this: the reason, why you could not reproduce is, that I
explicitly set
test.sslImplementation=org.apache.tomcat.util.net.jsse.JSSEImplementation
when testing JSSE. It is not necessary but IMHO it should be supported.
The failure was probably triggered by
1064d250c9463d3604d14de6229cf9edd4f04710 changing class
test/org/apache/tomcat/util/net/TestSsl.java in combination with a
difference in TesterSupport between 9.0.x and 10.1.x.
In 9.0.x (and probably 8.5.x) in
test/org/apache/tomcat/util/net/TesterSupport.java method
isClientRenegotiationSupported contains:
...
240 String sslImplementation =
System.getProperty("tomcat.test.sslImplementation");
241 if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)) {
242 // Assume custom SSL is not supporting this
243 return false;
244 }
...
In 10.1.x:
...
// Disabled for Tomcat Native (part of response to CVE-2009-3555)
// Only JRE provided JSSE implementation supports this
String sslImplementation = (String)
tomcat.getConnector().getProperty("sslImplementationName");
if
(!JSSEImplementation.class.getName().equals(sslImplementation)) {
return false;
}
...
So for 9.x setting JSSE explicitly result in returning false. In 10.1.x
the check !JSSEImplementation.class.getName().equals(sslImplementation)
makes sure it is not returning false.
Unfortunately taking over the code from 10.1.x to 9.x does not work,
because at this point
tomcat.getConnector().getProperty("sslImplementationName") returns null.
Possible fix:
--- a/test/org/apache/tomcat/util/net/TesterSupport.java
+++ b/test/org/apache/tomcat/util/net/TesterSupport.java
@@ -64,6 +64,7 @@ import org.apache.tomcat.util.descriptor.web.LoginConfig;
import org.apache.tomcat.util.descriptor.web.SecurityCollection;
import org.apache.tomcat.util.descriptor.web.SecurityConstraint;
import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
+import org.apache.tomcat.util.net.jsse.JSSEImplementation;
public final class TesterSupport {
@@ -238,7 +239,8 @@ public final class TesterSupport {
return false;
}
String sslImplementation =
System.getProperty("tomcat.test.sslImplementation");
-if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)) {
+if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation) &&
+
!JSSEImplementation.class.getName().equals(sslImplementation)) {
// Assume custom SSL is not supporting this
return false;
}
Not sure this is the right fix, or it would be better to use a change
that is closer to 10.1.x and find out, why
tomcat.getConnector().getProperty("sslImplementationName") is null
inside isClientRenegotiationSupported.
Best regards,
Rainer
Am 18.01.24 um 21:48 schrieb Mark Thomas:
On 18/01/2024 12:33, Rainer Jung wrote:
Hi all,
after the refactorings for the testing of the forbidden client
initiated renegotiations, these unit tests fail for me for the last
tags of TC 8.5 and 9, but not for 10.1 and 11. I am using JSSE and the
tests fail consistently for all four JDK vendors I am testing against
on all linux distributions I am testing on. I saw it for Java 8 and
11. No info yet about 17 and 21, the test runs will arrive at Java 17
later today.
Very odd. I just ran the 9.0.x test with Java 8 / JSSE and it passed.
Example output (no indication for a reason):
Testcase: testClientInitiatedRenegotiation took 0.383 sec
FAILED
Renegotiation started when it should have failed
junit.framework.AssertionFailedError: Renegotiation started when it
should have failed
at
org.apache.tomcat.util.net.TestSsl.testClientInitiatedRenegotiation(TestSsl.java:250)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Odd. With JSSE and NIO, client initiated renegotiation should work.
I can't recreate this. If you can recreate this in a debugger then I'd
look at TesterSupport.isClientRenegotiationSupported()
Mark
I expect it is a new problem in the test after the refactoring, not a
real TLS issue.
Best regards,
Rainer
-
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 unsubscri
(tomcat) branch main updated: Code cleanups
This is an automated email from the ASF dual-hosted git repository.
remm 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 c17f627dd8 Code cleanups
c17f627dd8 is described below
commit c17f627dd82b732a132e8d008900ce344cc48c0b
Author: remm
AuthorDate: Tue Feb 27 14:33:10 2024 +0100
Code cleanups
These classes are only compiled with Java 22.
---
.../tomcat/util/net/openssl/panama/OpenSSLContext.java | 17 +++--
.../tomcat/util/net/openssl/panama/OpenSSLEngine.java | 13 ++---
2 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
index a2ce690c88..f72606ba05 100644
--- a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++ b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -35,7 +35,6 @@ import java.util.Arrays;
import java.util.Base64;
import java.util.Iterator;
import java.util.List;
-import java.util.function.Consumer;
import javax.net.ssl.KeyManager;
import javax.net.ssl.SSLEngine;
@@ -67,7 +66,6 @@ import
org.apache.tomcat.util.openssl.SSL_CTX_set_alpn_select_cb$cb;
import org.apache.tomcat.util.openssl.SSL_CTX_set_cert_verify_callback$cb;
import org.apache.tomcat.util.openssl.SSL_CTX_set_tmp_dh_callback$dh;
import org.apache.tomcat.util.openssl.SSL_CTX_set_verify$callback;
-import org.apache.tomcat.util.openssl.openssl_h_Macros;
import org.apache.tomcat.util.openssl.pem_password_cb;
import org.apache.tomcat.util.res.StringManager;
@@ -1081,8 +1079,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
// Set callback for DH parameters
SSL_CTX_set_tmp_dh_callback(state.sslCtx,
SSL_CTX_set_tmp_dh_callback$dh.allocate(new TmpDHCallback(), contextArena));
} else {
-var d2i_ECPKParameters =
openssl_h_Macros.d2i_ECPKParameters$SYMBOL();
-var ecparams = PEM_ASN1_read_bio(d2i_ECPKParameters,
+var ecparams =
PEM_ASN1_read_bio(d2i_ECPKParameters$SYMBOL(),
PEM_STRING_ECPARAMETERS(), certificateBIO,
MemorySegment.NULL, MemorySegment.NULL, MemorySegment.NULL);
if (!MemorySegment.NULL.equals(ecparams)) {
int curveNid = EC_GROUP_get_curve_name(ecparams);
@@ -1407,18 +1404,10 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
// Use another arena to avoid keeping a reference through segments
// This also allows making further accesses to the main pointers
safer
this.sslCtx = sslCtx.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena,
-new Consumer() {
-@Override
-public void accept(MemorySegment t) {
-SSL_CTX_free(t);
-}});
+(MemorySegment t) -> SSL_CTX_free(t));
if (!MemorySegment.NULL.equals(confCtx)) {
this.confCtx =
confCtx.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena,
-new Consumer() {
-@Override
-public void accept(MemorySegment t) {
-SSL_CONF_CTX_free(t);
-}});
+(MemorySegment t) -> SSL_CONF_CTX_free(t));
} else {
this.confCtx = null;
}
diff --git a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
index 6099620f72..d80b48d2c4 100644
--- a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
+++ b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
@@ -42,7 +42,6 @@ import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
-import java.util.function.Consumer;
import javax.net.ssl.SSLEngine;
import javax.net.ssl.SSLEngineResult;
@@ -1684,17 +1683,9 @@ public final class OpenSSLEngine extends SSLEngine
implements SSLUtil.ProtocolIn
// Use another arena to avoid keeping a reference through segments
// This also allows making further accesses to the main pointers
safer
this.ssl = ssl.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena,
-new Consumer() {
-@Override
-public void accept(MemorySegment t) {
-SSL_free(t);
-}});
+(MemorySegment t) -> SSL_free(t));
this.networkBIO =
networkBIO.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena,
-
Re: March releases
On Tue, Feb 27, 2024 at 12:20 PM Mark Thomas wrote: > > On 27/02/2024 10:57, Rémy Maucherat wrote: > > On Tue, Feb 27, 2024 at 10:12 AM Mark Thomas wrote: > >> > >> All, > >> > >> When I look at the current change logs there isn't much there to justify > >> a March release. There are a couple of open bugs of which one looks > >> likely that there is an actual issue to be fixed. > >> > >> That said, I'm unlikely to be in a position to tag 11.0.x until w/c 11 > >> March. The change log may look different at that point. > >> > >> It is probably too early to make a decision but I wanted to float the > >> possibility of skipping the March release. That would mean we'd probably > >> need to make the final 8.5.x release in April. > > > > We don't need to always release all branches every time. > > Good point. > > > For example, 11 already has two useful fixes right now: support for > > Java 17 (one could want to verify it), then the FFM fix I made (using > > the wrong loader in one location means it simply breaks depending on > > how OpenSSL is loaded, so that's bad). But these two are not in the > > other branches. > > Ack. Those are good reasons for an 11.0.x release. > > I just checked the dependencies - there are no updates at the moment. > > > As for a final 8.5, I would say it is not mandatory if there's nothing > > useful in the changelog by the end of March. There's always going to > > be a final final fix needed anyway. I started skipping some backports > > to 8.5 since "regressions, who knows". > > I was just thinking .100 was a nice point release to end on ;) +1 :D Rémy > > Mark > > - > 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 9.0.x updated: Fix test
This is an automated email from the ASF dual-hosted git repository.
remm 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 574a848168 Fix test
574a848168 is described below
commit 574a848168261e714d19e94a14cac329b7005132
Author: remm
AuthorDate: Tue Feb 27 15:14:45 2024 +0100
Fix test
As posted by Rainer Jung
---
test/org/apache/tomcat/util/net/TesterSupport.java | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/test/org/apache/tomcat/util/net/TesterSupport.java
b/test/org/apache/tomcat/util/net/TesterSupport.java
index afbae25dc9..01e003a174 100644
--- a/test/org/apache/tomcat/util/net/TesterSupport.java
+++ b/test/org/apache/tomcat/util/net/TesterSupport.java
@@ -64,6 +64,7 @@ import org.apache.tomcat.util.descriptor.web.LoginConfig;
import org.apache.tomcat.util.descriptor.web.SecurityCollection;
import org.apache.tomcat.util.descriptor.web.SecurityConstraint;
import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
+import org.apache.tomcat.util.net.jsse.JSSEImplementation;
public final class TesterSupport {
@@ -238,7 +239,8 @@ public final class TesterSupport {
return false;
}
String sslImplementation =
System.getProperty("tomcat.test.sslImplementation");
-if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)) {
+if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)
+&&
!JSSEImplementation.class.getName().equals(sslImplementation)) {
// Assume custom SSL is not supporting this
return false;
}
-
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: Fix test
This is an automated email from the ASF dual-hosted git repository.
remm 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 fbc6e5bdbb Fix test
fbc6e5bdbb is described below
commit fbc6e5bdbb5769fa3cc813e08ccb654868f4db50
Author: remm
AuthorDate: Tue Feb 27 15:14:45 2024 +0100
Fix test
As posted by Rainer Jung
---
test/org/apache/tomcat/util/net/TesterSupport.java | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/test/org/apache/tomcat/util/net/TesterSupport.java
b/test/org/apache/tomcat/util/net/TesterSupport.java
index 568ea1ece8..873310f7c2 100644
--- a/test/org/apache/tomcat/util/net/TesterSupport.java
+++ b/test/org/apache/tomcat/util/net/TesterSupport.java
@@ -64,6 +64,7 @@ import org.apache.tomcat.util.descriptor.web.LoginConfig;
import org.apache.tomcat.util.descriptor.web.SecurityCollection;
import org.apache.tomcat.util.descriptor.web.SecurityConstraint;
import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
+import org.apache.tomcat.util.net.jsse.JSSEImplementation;
public final class TesterSupport {
@@ -236,7 +237,8 @@ public final class TesterSupport {
}
String sslImplementation =
System.getProperty("tomcat.test.sslImplementation");
-if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)) {
+if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)
+&&
!JSSEImplementation.class.getName().equals(sslImplementation)) {
// Assume custom SSL is not supporting this
return false;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: March releases
Mark, On 2/27/24 06:20, Mark Thomas wrote: On 27/02/2024 10:57, Rémy Maucherat wrote: On Tue, Feb 27, 2024 at 10:12 AM Mark Thomas wrote: All, When I look at the current change logs there isn't much there to justify a March release. There are a couple of open bugs of which one looks likely that there is an actual issue to be fixed. That said, I'm unlikely to be in a position to tag 11.0.x until w/c 11 March. The change log may look different at that point. It is probably too early to make a decision but I wanted to float the possibility of skipping the March release. That would mean we'd probably need to make the final 8.5.x release in April. We don't need to always release all branches every time. Good point. For example, 11 already has two useful fixes right now: support for Java 17 (one could want to verify it), then the FFM fix I made (using the wrong loader in one location means it simply breaks depending on how OpenSSL is loaded, so that's bad). But these two are not in the other branches. Ack. Those are good reasons for an 11.0.x release. I just checked the dependencies - there are no updates at the moment. As for a final 8.5, I would say it is not mandatory if there's nothing useful in the changelog by the end of March. There's always going to be a final final fix needed anyway. I started skipping some backports to 8.5 since "regressions, who knows". I was just thinking .100 was a nice point release to end on ;) Yeah, me too ;) I think we should release 8.5.100 in March, if only to meet our own goal of "ending support at the end of March". There isn't likely to be anything so important that it needs to be added after that. We made a few exceptions for Tomcats 6, 7, and 8.0 for security issues, but I think there's no reason not to release 8.5.100 during March. I don't mind waiting until later in the month just in case anything comes up. Plus we can always change our minds and release again if there is something vital. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: TestSsl.testClientInitiatedRenegotiation fails for TC 9 and 8.5
On Tue, Feb 27, 2024 at 1:32 PM Rainer Jung wrote:
>
> Hi Mark, hi all,
>
> coming back to this: the reason, why you could not reproduce is, that I
> explicitly set
>
> test.sslImplementation=org.apache.tomcat.util.net.jsse.JSSEImplementation
>
> when testing JSSE. It is not necessary but IMHO it should be supported.
>
> The failure was probably triggered by
> 1064d250c9463d3604d14de6229cf9edd4f04710 changing class
> test/org/apache/tomcat/util/net/TestSsl.java in combination with a
> difference in TesterSupport between 9.0.x and 10.1.x.
>
> In 9.0.x (and probably 8.5.x) in
> test/org/apache/tomcat/util/net/TesterSupport.java method
> isClientRenegotiationSupported contains:
>
> ...
> 240 String sslImplementation =
> System.getProperty("tomcat.test.sslImplementation");
> 241 if (sslImplementation != null &&
> !"${test.sslImplementation}".equals(sslImplementation)) {
> 242 // Assume custom SSL is not supporting this
> 243 return false;
> 244 }
> ...
>
> In 10.1.x:
>
> ...
> // Disabled for Tomcat Native (part of response to CVE-2009-3555)
> // Only JRE provided JSSE implementation supports this
> String sslImplementation = (String)
> tomcat.getConnector().getProperty("sslImplementationName");
> if
> (!JSSEImplementation.class.getName().equals(sslImplementation)) {
> return false;
> }
> ...
>
> So for 9.x setting JSSE explicitly result in returning false. In 10.1.x
> the check !JSSEImplementation.class.getName().equals(sslImplementation)
> makes sure it is not returning false.
>
> Unfortunately taking over the code from 10.1.x to 9.x does not work,
> because at this point
> tomcat.getConnector().getProperty("sslImplementationName") returns null.
>
> Possible fix:
>
> --- a/test/org/apache/tomcat/util/net/TesterSupport.java
> +++ b/test/org/apache/tomcat/util/net/TesterSupport.java
> @@ -64,6 +64,7 @@ import org.apache.tomcat.util.descriptor.web.LoginConfig;
> import org.apache.tomcat.util.descriptor.web.SecurityCollection;
> import org.apache.tomcat.util.descriptor.web.SecurityConstraint;
> import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
> +import org.apache.tomcat.util.net.jsse.JSSEImplementation;
>
> public final class TesterSupport {
>
> @@ -238,7 +239,8 @@ public final class TesterSupport {
> return false;
> }
> String sslImplementation =
> System.getProperty("tomcat.test.sslImplementation");
> -if (sslImplementation != null &&
> !"${test.sslImplementation}".equals(sslImplementation)) {
> +if (sslImplementation != null &&
> !"${test.sslImplementation}".equals(sslImplementation) &&
> +
> !JSSEImplementation.class.getName().equals(sslImplementation)) {
> // Assume custom SSL is not supporting this
> return false;
> }
>
>
> Not sure this is the right fix, or it would be better to use a change
> that is closer to 10.1.x and find out, why
> tomcat.getConnector().getProperty("sslImplementationName") is null
> inside isClientRenegotiationSupported.
Ok so I picked up your change.
Things are different in 10.1 because the tests are parametrized.
Actually when you run the test, for example TestSsl, it always does
the same tests regardless of what you configure (so JSSE, OpenSSL,
OpenSSL-FFM). This is mostly due to the APR connector being removed.
Rémy
> Best regards,
>
> Rainer
>
> Am 18.01.24 um 21:48 schrieb Mark Thomas:
> > On 18/01/2024 12:33, Rainer Jung wrote:
> >> Hi all,
> >>
> >> after the refactorings for the testing of the forbidden client
> >> initiated renegotiations, these unit tests fail for me for the last
> >> tags of TC 8.5 and 9, but not for 10.1 and 11. I am using JSSE and the
> >> tests fail consistently for all four JDK vendors I am testing against
> >> on all linux distributions I am testing on. I saw it for Java 8 and
> >> 11. No info yet about 17 and 21, the test runs will arrive at Java 17
> >> later today.
> >
> > Very odd. I just ran the 9.0.x test with Java 8 / JSSE and it passed.
> >
> >> Example output (no indication for a reason):
> >
> >
> >
> >
> >> Testcase: testClientInitiatedRenegotiation took 0.383 sec
> >> FAILED
> >> Renegotiation started when it should have failed
> >> junit.framework.AssertionFailedError: Renegotiation started when it
> >> should have failed
> >> at
> >> org.apache.tomcat.util.net.TestSsl.testClientInitiatedRenegotiation(TestSsl.java:250)
> >> at
> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> >> Method)
> >> at
> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >> at
> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >
> > Odd. With JSSE and NIO, client initiated renegotiation should work.
> >
> > I can't recreate this. If you can recreate this in a debugger then I'd
> >
[Bug 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677 --- Comment #2 from Christopher Schultz --- Does IIS have the ability to add request headers to proxied requests? For example, if you were using client -> [HTTP] -> IIS -> [HTTP] -> Tomcat, would you be able to set arbitrary HTTP headers into the request between IIS -> Tomcat? I'm asking because AJP is really a protocol that should be retired and replaced with HTTP(S). If you can switch to HTTP and the tools you need exist when using it, all the better. -- 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: TestSsl.testClientInitiatedRenegotiation fails for TC 9 and 8.5
Thank you Remy for fixing it and the explanation.
Am 27.02.24 um 15:33 schrieb Rémy Maucherat:
On Tue, Feb 27, 2024 at 1:32 PM Rainer Jung wrote:
Hi Mark, hi all,
coming back to this: the reason, why you could not reproduce is, that I
explicitly set
test.sslImplementation=org.apache.tomcat.util.net.jsse.JSSEImplementation
when testing JSSE. It is not necessary but IMHO it should be supported.
The failure was probably triggered by
1064d250c9463d3604d14de6229cf9edd4f04710 changing class
test/org/apache/tomcat/util/net/TestSsl.java in combination with a
difference in TesterSupport between 9.0.x and 10.1.x.
In 9.0.x (and probably 8.5.x) in
test/org/apache/tomcat/util/net/TesterSupport.java method
isClientRenegotiationSupported contains:
...
240 String sslImplementation =
System.getProperty("tomcat.test.sslImplementation");
241 if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)) {
242 // Assume custom SSL is not supporting this
243 return false;
244 }
...
In 10.1.x:
...
// Disabled for Tomcat Native (part of response to CVE-2009-3555)
// Only JRE provided JSSE implementation supports this
String sslImplementation = (String)
tomcat.getConnector().getProperty("sslImplementationName");
if
(!JSSEImplementation.class.getName().equals(sslImplementation)) {
return false;
}
...
So for 9.x setting JSSE explicitly result in returning false. In 10.1.x
the check !JSSEImplementation.class.getName().equals(sslImplementation)
makes sure it is not returning false.
Unfortunately taking over the code from 10.1.x to 9.x does not work,
because at this point
tomcat.getConnector().getProperty("sslImplementationName") returns null.
Possible fix:
--- a/test/org/apache/tomcat/util/net/TesterSupport.java
+++ b/test/org/apache/tomcat/util/net/TesterSupport.java
@@ -64,6 +64,7 @@ import org.apache.tomcat.util.descriptor.web.LoginConfig;
import org.apache.tomcat.util.descriptor.web.SecurityCollection;
import org.apache.tomcat.util.descriptor.web.SecurityConstraint;
import org.apache.tomcat.util.net.SSLHostConfigCertificate.Type;
+import org.apache.tomcat.util.net.jsse.JSSEImplementation;
public final class TesterSupport {
@@ -238,7 +239,8 @@ public final class TesterSupport {
return false;
}
String sslImplementation =
System.getProperty("tomcat.test.sslImplementation");
-if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation)) {
+if (sslImplementation != null &&
!"${test.sslImplementation}".equals(sslImplementation) &&
+
!JSSEImplementation.class.getName().equals(sslImplementation)) {
// Assume custom SSL is not supporting this
return false;
}
Not sure this is the right fix, or it would be better to use a change
that is closer to 10.1.x and find out, why
tomcat.getConnector().getProperty("sslImplementationName") is null
inside isClientRenegotiationSupported.
Ok so I picked up your change.
Things are different in 10.1 because the tests are parametrized.
Actually when you run the test, for example TestSsl, it always does
the same tests regardless of what you configure (so JSSE, OpenSSL,
OpenSSL-FFM). This is mostly due to the APR connector being removed.
Rémy
Best regards,
Rainer
Am 18.01.24 um 21:48 schrieb Mark Thomas:
On 18/01/2024 12:33, Rainer Jung wrote:
Hi all,
after the refactorings for the testing of the forbidden client
initiated renegotiations, these unit tests fail for me for the last
tags of TC 8.5 and 9, but not for 10.1 and 11. I am using JSSE and the
tests fail consistently for all four JDK vendors I am testing against
on all linux distributions I am testing on. I saw it for Java 8 and
11. No info yet about 17 and 21, the test runs will arrive at Java 17
later today.
Very odd. I just ran the 9.0.x test with Java 8 / JSSE and it passed.
Example output (no indication for a reason):
Testcase: testClientInitiatedRenegotiation took 0.383 sec
FAILED
Renegotiation started when it should have failed
junit.framework.AssertionFailedError: Renegotiation started when it
should have failed
at
org.apache.tomcat.util.net.TestSsl.testClientInitiatedRenegotiation(TestSsl.java:250)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Odd. With JSSE and NIO, client initiated renegotiation should work.
I can't recreate this. If you can recreate this in a debugger then I'd
look at TesterSupport.isClientRenegotiationSupported()
Mark
I expect it is a new problem in the test after the refactoring, not a
real TLS issue.
Best regards,
Rainer
[Bug 68677] no support for enviroment variables/request attributes
https://bz.apache.org/bugzilla/show_bug.cgi?id=68677 --- Comment #3 from dub...@gmail.com --- I'm not entirely sure, but the point here is that I dont want to use on HTTP headers. The current ISAPI filter already passes on those. The problem is that they can be spoofed by the client so I'm hoping for a solution that would be able to supply request attributes to Tomcat like what the mod_jk JkEnvVar directive does. A reverse proxy setup like what you are describing isn't going to be able to do what I'm asking for because I need something that is integrated w/ Tomcat and can supply attributes to the backend HttpServletRequest. Thats exactly what the Tomcat AJP connectors do. However, only the Apache one (mod_jk) does this with user-defined attributes. -- 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
