(tomcat) branch main updated: jextract fixes
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 0718605647 jextract fixes
0718605647 is described below
commit 0718605647d0843e80fe0b2c957834d8db3c5a7f
Author: remm
AuthorDate: Wed Dec 13 10:32:55 2023 +0100
jextract fixes
---
.../openssl/SSL_CTX_set_alpn_select_cb$cb.java | 13 +-
.../SSL_CTX_set_cert_verify_callback$cb.java | 13 +-
.../openssl/SSL_CTX_set_default_passwd_cb$cb.java | 21 +-
.../openssl/SSL_CTX_set_tmp_dh_callback$dh.java| 14 +-
.../util/openssl/SSL_CTX_set_verify$callback.java | 11 +-
.../util/openssl/SSL_set_info_callback$cb.java | 13 +-
.../util/openssl/SSL_set_verify$callback.java | 11 +-
java/org/apache/tomcat/util/openssl/openssl_h.java | 781 -
.../tomcat/util/openssl/openssl_h_Macros.java | 288
9 files changed, 657 insertions(+), 508 deletions(-)
diff --git
a/java/org/apache/tomcat/util/openssl/SSL_CTX_set_alpn_select_cb$cb.java
b/java/org/apache/tomcat/util/openssl/SSL_CTX_set_alpn_select_cb$cb.java
index 1ace09bee7..b871ecf568 100644
--- a/java/org/apache/tomcat/util/openssl/SSL_CTX_set_alpn_select_cb$cb.java
+++ b/java/org/apache/tomcat/util/openssl/SSL_CTX_set_alpn_select_cb$cb.java
@@ -19,9 +19,11 @@
package org.apache.tomcat.util.openssl;
+import java.lang.foreign.Arena;
+import java.lang.foreign.FunctionDescriptor;
+import java.lang.foreign.Linker;
+import java.lang.foreign.MemorySegment;
import java.lang.invoke.MethodHandle;
-import java.lang.foreign.*;
-import static java.lang.foreign.ValueLayout.*;
/**
* {@snippet lang = c
@@ -30,8 +32,8 @@ import static java.lang.foreign.ValueLayout.*;
*/
public interface SSL_CTX_set_alpn_select_cb$cb {
-FunctionDescriptor $DESC = FunctionDescriptor.of(JAVA_INT,
openssl_h.C_POINTER, openssl_h.C_POINTER,
-openssl_h.C_POINTER, openssl_h.C_POINTER, JAVA_INT,
openssl_h.C_POINTER);
+FunctionDescriptor $DESC = FunctionDescriptor.of(openssl_h.C_INT,
openssl_h.C_POINTER, openssl_h.C_POINTER,
+openssl_h.C_POINTER, openssl_h.C_POINTER, openssl_h.C_INT,
openssl_h.C_POINTER);
int apply(MemorySegment _x0, MemorySegment _x1, MemorySegment _x2,
MemorySegment _x3, int _x4, MemorySegment _x5);
@@ -54,4 +56,5 @@ public interface SSL_CTX_set_alpn_select_cb$cb {
}
};
}
-}
\ No newline at end of file
+}
+
diff --git
a/java/org/apache/tomcat/util/openssl/SSL_CTX_set_cert_verify_callback$cb.java
b/java/org/apache/tomcat/util/openssl/SSL_CTX_set_cert_verify_callback$cb.java
index 40f20e3c34..9c5d69e264 100644
---
a/java/org/apache/tomcat/util/openssl/SSL_CTX_set_cert_verify_callback$cb.java
+++
b/java/org/apache/tomcat/util/openssl/SSL_CTX_set_cert_verify_callback$cb.java
@@ -19,17 +19,19 @@
package org.apache.tomcat.util.openssl;
+import java.lang.foreign.Arena;
+import java.lang.foreign.FunctionDescriptor;
+import java.lang.foreign.Linker;
+import java.lang.foreign.MemorySegment;
import java.lang.invoke.MethodHandle;
-import java.lang.foreign.*;
-import static java.lang.foreign.ValueLayout.*;
/**
- * {@snippet lang = c : * int (*SSL_CTX_set_cert_verify_callback$cb)(struct
x509_store_ctx_st*,void*);
+ * {@snippet lang = c : * int
(*SSL_CTX_set_cert_verify_callback$cb)(X509_STORE_CTX*,void*);
* }
*/
public interface SSL_CTX_set_cert_verify_callback$cb {
-FunctionDescriptor $DESC = FunctionDescriptor.of(JAVA_INT,
openssl_h.C_POINTER, openssl_h.C_POINTER);
+FunctionDescriptor $DESC = FunctionDescriptor.of(openssl_h.C_INT,
openssl_h.C_POINTER, openssl_h.C_POINTER);
int apply(MemorySegment _x0, MemorySegment _x1);
@@ -51,4 +53,5 @@ public interface SSL_CTX_set_cert_verify_callback$cb {
}
};
}
-}
\ No newline at end of file
+}
+
diff --git
a/java/org/apache/tomcat/util/openssl/SSL_CTX_set_default_passwd_cb$cb.java
b/java/org/apache/tomcat/util/openssl/SSL_CTX_set_default_passwd_cb$cb.java
index 2d12398c98..c286929484 100644
--- a/java/org/apache/tomcat/util/openssl/SSL_CTX_set_default_passwd_cb$cb.java
+++ b/java/org/apache/tomcat/util/openssl/SSL_CTX_set_default_passwd_cb$cb.java
@@ -19,20 +19,22 @@
package org.apache.tomcat.util.openssl;
+import java.lang.foreign.Arena;
+import java.lang.foreign.FunctionDescriptor;
+import java.lang.foreign.Linker;
+import java.lang.foreign.MemorySegment;
import java.lang.invoke.MethodHandle;
-import java.lang.foreign.*;
-import static java.lang.foreign.ValueLayout.*;
/**
- * {@snippet lang = c : * int
(*SSL_CTX_set_default_passwd_cb$cb)(char*,int,int,void*);
+ * {@snippet lang = c : * int (*SSL_CTX_set_default_passwd_cb$cb)(char*
buf,int size,int rwflag,void* userdata);
* }
*/
public interface SSL_CTX_set_default_passwd_cb$cb {
-FunctionDescriptor $DESC = FunctionDescriptor.of(
(tomcat) branch main updated: 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 4648db89a2 Cleanups
4648db89a2 is described below
commit 4648db89a26805ef1ad5212214b7c50d3165c93c
Author: remm
AuthorDate: Wed Dec 13 11:52:53 2023 +0100
Cleanups
Use the log loop when logging errors in the context.
Make some methods private.
Remove duplicate code.
renegotiate does not need sync since it is private and the only caller
is synced.
---
.../util/net/openssl/panama/OpenSSLContext.java| 43 +++---
.../util/net/openssl/panama/OpenSSLEngine.java | 164 ++---
.../tomcat/util/openssl/openssl_h_Macros.java | 5 -
3 files changed, 102 insertions(+), 110 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 729635a942..a5aa2ea8a0 100644
--- a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++ b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -100,6 +100,8 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
public static final int SSL_PROTOCOL_ALL = (SSL_PROTOCOL_TLSV1 |
SSL_PROTOCOL_TLSV1_1 | SSL_PROTOCOL_TLSV1_2 |
SSL_PROTOCOL_TLSV1_3);
+static final int OPTIONAL_NO_CA = 3;
+
private static final String BEGIN_KEY = "-BEGIN PRIVATE KEY-\n";
private static final Object END_KEY = "\n-END PRIVATE KEY-";
@@ -136,8 +138,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
private final MemorySegment openSSLCallbackPassword;
private static final ConcurrentHashMap states = new
ConcurrentHashMap<>();
-
-static ContextState getState(MemorySegment ctx) {
+private static ContextState getState(MemorySegment ctx) {
return states.get(Long.valueOf(ctx.address()));
}
@@ -477,8 +478,6 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
return result;
}
-private static final int OPTIONAL_NO_CA = 3;
-
/**
* Setup the SSL_CTX.
*
@@ -564,9 +563,8 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
}
// Set int verify_callback(int preverify_ok, X509_STORE_CTX
*x509_ctx) callback
-// Leave this just in case but in Tomcat this is always set again
by the engine
SSL_CTX_set_verify(state.sslCtx, value,
-SSL_CTX_set_verify$callback.allocate(new VerifyCallback(),
contextArena));
+SSL_CTX_set_verify$callback.allocate(new
OpenSSLEngine.VerifyCallback(), contextArena));
// Trust and certificate verification
if (tms != null) {
@@ -778,14 +776,6 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
}
-private static class VerifyCallback implements SSL_CTX_set_verify$callback
{
-@Override
-public int apply(int preverify_ok, MemorySegment /*X509_STORE_CTX*/
x509ctx) {
-return OpenSSLEngine.openSSLCallbackVerify(preverify_ok, x509ctx);
-}
-}
-
-
private static class CertVerifyCallback implements
SSL_CTX_set_cert_verify_callback$cb {
@Override
public int apply(MemorySegment /*X509_STORE_CTX*/ x509_ctx,
MemorySegment param) {
@@ -942,7 +932,6 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
}
-@SuppressWarnings("deprecation")
private boolean addCertificate(SSLHostConfigCertificate certificate, Arena
localArena) throws Exception {
int index = getCertificateIndex(certificate);
// Load Server key and certificate
@@ -1375,10 +1364,26 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
private static void logLastError(SegmentAllocator allocator, String
string) {
-var buf = allocator.allocate(ValueLayout.JAVA_BYTE, 128);
-ERR_error_string(ERR_get_error(), buf);
-String err = buf.getString(0);
-log.error(sm.getString(string, err));
+String sslError = null;
+long error = ERR_get_error();
+if (error != SSL_ERROR_NONE()) {
+do {
+// Loop until getLastErrorNumber() returns SSL_ERROR_NONE
+var buf = allocator.allocate(ValueLayout.JAVA_BYTE, 128);
+ERR_error_string(error, buf);
+String err = buf.getString(0);
+if (sslError == null) {
+sslError = err;
+}
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("engine.openSSLError",
Long.toString(error), err));
+}
+} w
JDK 22 Feature Freeze!
Welcome to the final OpenJDK Quality Outreach update of 2023!
JDK 22, scheduled for General Availability on March 19, 2024, is now in
Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 22 feature set is
frozen (see the final list of JEPs integrated into JDK 22 below) and only
low-risk enhancements might still be considered. The coming weeks should be
leveraged to identify and resolve as many issues as possible, i.e. before JDK
22 enters the Release Candidates phase in early February 2024. So, we count on
you to test your projects and help us make JDK 22 another solid release!
[1] https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008535.html
## JDK 22 Early-Access Builds
JDK 22 Early-Access builds 27 are now available [2] with the Release Notes here
[3]. Those builds are provided under the GNU GPL v2, with the Classpath
Exception.
### JEPs integrated into JDK 22:
- JEP 423: Region Pinning for G1
- JEP 447: Statements before super(…) (Preview)
- JEP 454: Foreign Function & Memory API
- JEP 456: Unnamed Variables & Patterns
- JEP 457: Class-File API (Preview)
- JEP 458: Launch Multi-File Source-Code Programs
- JEP 459: String Templates (2nd Preview)
- JEP 460: Vector API (7th Incubator)
- JEP 461: Stream Gatherers (Preview)
- JEP 462: Structured Concurrency (2nd Preview)
- JEP 463: Implicitly Declared Classes and Instance Main Methods (2nd Preview)
- JEP 464: Scoped Values (2nd Preview)
### Changes in recent JDK 22 builds that may be of interest:
- JDK-8318646: Integer#parseInt("") throws empty NumberFormatException message
[Reported by Apache Lucene]
- JDK-8318082: ConcurrentModificationException from IndexWriter [Reported by
JOOQ]
- JDK-8319450: New methods java.net.InetXAddress.ofLiteral() miss @since tag
[Reported by JaCoCo]
- JDK-8321164: javac w/ annotation processor throws AssertionError: Filling
jrt:/… during … [Reported by Hibernate]
- JDK-8310644: Make panama memory segment close use async handshakes
- JDK-8302233: HSS/LMS: keytool and jarsigner changes
- JDK-8211238: New @Deprecated JFR event
- JDK-8319124: Update XML Security for Java to 3.0.3
- JDK-8306055: Add a built-in Catalog to JDK XML module
- JDK-8319244: implement JVMTI handshakes support for virtual threads
- JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types
for methods loaded from bytecode
- JDK-8318759: Add four DigiCert root certificates
- JDK-8317374: Add Let's Encrypt ISRG Root X2
- JDK-8306116: Update CLDR to Version 44.0
- JDK-8287843: File::getCanonicalFile doesn't work for \\?\C:\ style
paths DOS device paths
- JDK-8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with
"InterruptedException: sleep interrupted"
- JDK-8311596: Add separate system properties for TLS server and client for
maximum chain length
- JDK-8318160: javac does not reject private method reference with
type-variable receiver
- JDK-8305753: Allow JIT compilation for -Xshare:dump
- JDK-8187591: -Werror turns incubator module warning to an error
- JDK-8318096: Introduce AsymmetricKey interface with a getParams method
- JDK-8319174: Enhance robustness of some j.m.BigInteger constructors
- JDK-8288899: Changes to java.util.concurrent.ForkJoinPool and ForkJoinTask
- JDK-8272215: Add InetAddress methods for parsing IP address literals
- JDK-8316996: Catalog API Enhancement: add a factory method
- JDK-8305814: Update Xalan Java to 2.7.3
- JDK-8313643: Update HarfBuzz to 8.2.2
- JDK-8316030: Update Libpng to 1.6.40
Note: A more comprehensive list of changes can be found here [4].
[2] https://jdk.java.net/22/
[3] https://jdk.java.net/22/release-notes
[4] https://github.com/openjdk/jdk/compare/jdk-22+20...jdk-22+27
## JDK 23 Early-Access Builds
Given that JDK 22 is in Rampdown Phase, the initial JDK 23 EA builds are now
also available [5]. These EA builds are provided under the GNU General Public
License v2, with the Classpath Exception.
[5] https://jdk.java.net/23/
## JavaFX 22 Early-Access Builds
These are early-access builds of the JavaFX 22 [8] Runtime built from
openjdk/jfx [9]. This allows JavaFX application developers to build and test
their applications with JavaFX 22 on JDK 22. The JavaFX 22 API Javadocs are
also available [10].
The JavaFX runtime is delivered as an SDK and as a set of jmods for each
platform. You can use the SDK to compile and run JavaFX applications. You can
use the jmods with jlink to create a JDK that includes the JavaFX modules, and
optionally, your modular application. JavaFX 22 is designed to work with JDK
22,but it is known to work with JDK 17 and later versions.
[8] https://jdk.java.net/javafx22/
[9] https://github.com/openjdk/jfx
[10]
https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html
## Topics of Interest:
- Java 22 Unpacking - Inside Java Newscast
https://inside.java/2023/12/07/newscast-59/
- Java On The GPU - Inside Java Newscast
https://inside.java/2023/11/16/newscast-58/
- Better Java
[Bug 67675] Tomcat and/or Java do not read encrypted private keys with DES-EDE3-CBC generated by openssl-req(1)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67675 --- Comment #18 from ggar --- Is it expected for PEM cert/key created with OpenSSL 1.0.2zh (or any 1.0.2) to stop working after this change? It seems to work fine with items generated through OpenSSL 1.1.1. Here's an example of the command we use: openssl req -new -sha256 -x509 -out servercert.pem -keyout serverkey.pem -subj /"/CN=localhost" -days 90 -passout pass:test I'm seeing the following error after upgrading to 9.0.83: 13-Dec-2023 02:04:34.337 SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to initialize component [Connector["https-openssl-apr-443"]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:1011) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:554) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1039) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127) at org.apache.catalina.startup.Catalina.load(Catalina.java:724) at org.apache.catalina.startup.Catalina.load(Catalina.java:746) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477) Caused by: java.lang.IllegalArgumentException: The pseudo random function with DER encoded OID of [2a864886f70d0307] was not recognised at org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:467) at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:433) at org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1332) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1345) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:654) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:75) at org.apache.catalina.connector.Connector.initInternal(Connector.java:1009) ... 13 more Caused by: java.security.NoSuchAlgorithmException: The pseudo random function with DER encoded OID of [2a864886f70d0307] was not recognised at org.apache.tomcat.util.net.jsse.PEMFile$Part.toPrivateKey(PEMFile.java:411) at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:213) at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:141) at org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:355) at org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.java:108) at org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:268) at org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:465) ... 19 more 13-Dec-2023 02:04:34.352 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [2478] milliseconds The thrown error seems to have been added with this fix and that's why I'm writing here. That's my first post so I'm sorry if I should be opening a new report instead (couldn't find anything specific in the guidelines). -- 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
[Bug 67675] Tomcat and/or Java do not read encrypted private keys with DES-EDE3-CBC generated by openssl-req(1)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67675 --- Comment #19 from Michael Osipov --- (In reply to ggar from comment #18) > Is it expected for PEM cert/key created with OpenSSL 1.0.2zh (or any 1.0.2) > to stop working after this change? It seems to work fine with items > generated through OpenSSL 1.1.1. Here's an example of the command we use: > openssl req -new -sha256 -x509 -out servercert.pem -keyout serverkey.pem > -subj /"/CN=localhost" -days 90 -passout pass:test > > > I'm seeing the following error after upgrading to 9.0.83: > 13-Dec-2023 02:04:34.337 SEVERE [main] > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to > initialize component [Connector["https-openssl-apr-443"]] > org.apache.catalina.LifecycleException: Protocol handler initialization > failed > at > org.apache.catalina.connector.Connector.initInternal(Connector.java:1011) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127) > at > org.apache.catalina.core.StandardService.initInternal(StandardService.java: > 554) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127) > at > org.apache.catalina.core.StandardServer.initInternal(StandardServer.java: > 1039) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127) > at org.apache.catalina.startup.Catalina.load(Catalina.java:724) > at org.apache.catalina.startup.Catalina.load(Catalina.java:746) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown > Source) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > Source) > at java.base/java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307) > at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477) > Caused by: java.lang.IllegalArgumentException: The pseudo random > function > with DER encoded OID of [2a864886f70d0307] was not recognised > at > org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:467) > at > org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:433) > at > org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint. > java:1332) > at > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1345) > at > org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:654) > at > org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol. > java:75) > at > org.apache.catalina.connector.Connector.initInternal(Connector.java:1009) > ... 13 more > Caused by: java.security.NoSuchAlgorithmException: The pseudo random > function with DER encoded OID of [2a864886f70d0307] was not recognised > at > org.apache.tomcat.util.net.jsse.PEMFile$Part.toPrivateKey(PEMFile.java:411) > at > org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:213) > at > org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:141) > at > org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:355) > at > org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil. > java:108) > at > org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:268) > at > org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:465) > ... 19 more > 13-Dec-2023 02:04:34.352 INFO [main] > org.apache.catalina.startup.Catalina.load Server initialization in [2478] > milliseconds > > The thrown error seems to have been added with this fix and that's why I'm > writing here. That's my first post so I'm sorry if I should be opening a new > report instead (couldn't find anything specific in the guidelines). Likely a regression, but I wonder whether we should care about keys from OpenSSL 1.0.2 at all. It has been dead for a long time now. For the sake of completeness, please file an new issue and upload the faulty material. One needs to look at the ASN.1 dump compared to 1.1.1. -- 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
[Bug 67675] Tomcat and/or Java do not read encrypted private keys with DES-EDE3-CBC generated by openssl-req(1)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67675 Mark Thomas changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #20 from Mark Thomas --- If I have decoded it correctly, the OID is 1.2.840.113549.3.7 http://oid-info.com/get/1.2.840.113549.3.7 I need to look into why Tomcat isn't able to handle this. -- 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
[Bug 67675] Tomcat and/or Java do not read encrypted private keys with DES-EDE3-CBC generated by openssl-req(1)
https://bz.apache.org/bugzilla/show_bug.cgi?id=67675 --- Comment #21 from Mark Thomas --- The algorithm is being read as the pseudo random function and failing. I need to see if I can find (or build) an OpenSSL 1.0.2 binary. -- 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
[Bug 68295] Connection has already been closed - Tomcat connection pool
https://bz.apache.org/bugzilla/show_bug.cgi?id=68295 Mark Thomas changed: What|Removed |Added Target Milestone|- |--- Component|Documentation |jdbc-pool Product|Tomcat 9|Tomcat Modules -- 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
Practical use of CsrfPreventionFilter
All,
I've been playing with this Filter recently, and I have some concerns
for its practical use. I'm considering adding some features to it in
order to make it more practical to use, and I'm interested to see what
others think about these "problems" and whether my potential additions
have merit.
These are in no particular order (e.g. importance).
1. Killing caching
If used as prescribed, all URLs will have CSRF tokens added to them even
when they are unnecessary. Specifically, I'm thinking about static
resources such as images, scripts, and CSS.
A sample page I'm using for testing uses a standard template for the web
application I'm working with, and it normally requests 3 CSS files, 6
Javascript files, and a site-logo. The browser very much likes to use
the "favicons" that are defined in the page, and so it (Firefox) will
load 2 different sizes of favicon for various purposes.
Simply clicking into the title bar and pressing ENTER shows that /all of
those resources are re-fetched from the server for every request/. The
browser cache has been defeated.
Each of these resources has been configured to return the following HTTP
response headers to encourage caching:
Cache-Control: public
ETag: [the etag, which is constant]
The same of course happens if you perform a "quick" page reload (i.e.
CTRL-R/CMD-R/click-reload-button) rather than performing a FULL page
reload (i.e. SHITF-CTRL-R/SHIFT-CMD-R/SHIFT-click-reload-button).
This happens because every page-access generates a new CSRF token for
that request which is used for all the URL references on that page.
Intermediate caches such as true caching HTTP servers will likely have
the same problem. For caching HTTP servers, this represents a mild DOS
attack since those caches will be wasting their cache space on one-time
URLs. They could surely be tuned to ignore query-strings for certain URL
patterns, but then cache performance (i.e. speed) will be decreased due
to that URL-processing being added to the pipeline.
I think it might have some sense to add some filtering to the
CsrfResponseWrapper (which is where HttpServletResponse.encodeURL and
HttpServetRequest.encoreRedirectURL are hooked to add these token
parameters to the URLs) to allow it to STOP adding tokens to certain URL
patterns. Prefix (/images/*) or suffix (*.css) matching seems to make
sense to me for inexpensive checks to get caching working again.
2. s with either GET or POST. Or, really... "Forms"
When using , different
browsers do different things with the query string. I'm mostly testing
on Firefox and I don't have time to check this on every browser. It's
enough that Firefox behaves in this way.
Submitting this form causes a 403 response. The browser shows that the
URL requested from the server is /foo?btn=Go! and the CSRF token has
been removed from the action. (Surprise!) I don't see anything in
WHATWG's description of how form-submission is supposed to work that
indicates that GET versus POST should behave differently with respect to
the 'action' attribute, but this is what the current version of Firefox
actually does.
There are three options I can think of to get around this:
a. Switch to POST:
You get HTTP POST /foo?csrf=blahblah with an
application/x-www-urlencoded entity containing the form element(s).
b. Manually add the CSRF token to the form:
[ if
request.getAttribute("org.apache.catalina.filters.CSRF_NONCE_PARAM_NAME") ]
]" />
[ end-if]
In this case, you get a GET request with the csrf parameter in there
because, well, you asked for it.
c. Hack the CsrfPreventionFilter to allow all POST methods. This is one
of my proposals: allow users to configure the CSRF prevention filter to
always-allow HTTP POSTs. This cannot be done in web.xml using e.g.
GET for the because Filters cannot
be configured in this way. And if they could be, the Filter would not be
invoked and all the URLs on your page would lack the required CSRF
tokens to make /those/ links work.
3. Default token-cache size
The default token cache size is 5. If you use applications like I do,
you often open multiple links into separate tabs for various reasons. Do
a search of products in your application, and there are several of them
you'd like to get details for. So you middle-click (or whatever does it
in your environment) on each of those links to open separate tabs,
leaving the search-results page visible in the current tab.
Then you want to click the "next" button to view the next page of the
results. An HTTP 403 response is returned because, if you opened more
than 4 extra tabs, the tokens used on the search-results page have
already expired, and you can't use your page anymore.
I'm not sure what the best token cache size is. It might depend upon the
behavior of your users. If I use your site, you might want a very large
token cache size. But I think maybe 5 isn't quite big enough. At least
it's trivially
