[Bug 67927] TLSCertificateReloadListener triggers race condition (?) in OpenSSL code which causes the JVM to die
https://bz.apache.org/bugzilla/show_bug.cgi?id=67927 --- Comment #6 from Remy Maucherat --- Since deallocating the ssl context should be tied to GC when using NIO, I don't understand how it happens. OTOH, actually doing it is quite risky, so maybe it could be better to leak it ... It would be a good idea to try the FFM code to debug this kind of issue (shameless ad). It would produce cleaner traces and would be easier to experiment with, although I doubt the native code itself would need a fix in that particular case. -- 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 67927] TLSCertificateReloadListener triggers race condition (?) in OpenSSL code which causes the JVM to die
https://bz.apache.org/bugzilla/show_bug.cgi?id=67927 --- Comment #7 from Michael Osipov --- (In reply to Remy Maucherat from comment #6) > Since deallocating the ssl context should be tied to GC when using NIO, I > don't understand how it happens. OTOH, actually doing it is quite risky, so > maybe it could be better to leak it ... > > It would be a good idea to try the FFM code to debug this kind of issue > (shameless ad). It would produce cleaner traces and would be easier to > experiment with, although I doubt the native code itself would need a fix in > that particular case. I will try the FFM code next week. I am still convinced that all requests need to paused and the connector locked during security context reload. -- 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
[tomcat] branch main updated: Add a note about a todo
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 2f7618039f Add a note about a todo
2f7618039f is described below
commit 2f7618039f0f717ea1eea54ad6a85062195184a3
Author: remm
AuthorDate: Thu Oct 26 17:11:06 2023 +0200
Add a note about a todo
Maybe repeated uses of PEM_read_bio_X509 on a memory BIO containing the
whole chain could work, and adding using SSL_CTX_add_extra_chain_cert.
---
java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java | 1 +
1 file changed, 1 insertion(+)
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 3dfdfc1a6b..ac1561639f 100644
--- a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++ b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -1199,6 +1199,7 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
}
// Set certificate chain file
if (certificate.getCertificateChainFile() != null) {
+// FIXME: Ideally this should be loaded in Java but still
processed through OpenSSL
var certificateChainFileNative =
localArena.allocateFrom(SSLHostConfig.adjustRelativePath(certificate.getCertificateChainFile()));
// SSLContext.setCertificateChainFile(state.ctx,
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Buildbot failure in on tomcat-9.0.x
Build status: BUILD FAILED: failed compile (failure) Worker used: bb_worker2_ubuntu URL: https://ci2.apache.org/#builders/37/builds/744 Blamelist: Mark Thomas Build Text: failed compile (failure) Status Detected: new failure Build Source Stamp: [branch 9.0.x] 5462cf0e569d62a9f3949800d14ec343d4766a0a Steps: worker_preparation: 0 git: 0 shell: 0 shell_1: 0 shell_2: 0 shell_3: 0 shell_4: 0 shell_5: 0 compile: 1 shell_6: 0 shell_7: 0 shell_8: 0 shell_9: 0 Rsync docs to nightlies.apache.org: 0 shell_10: 0 Rsync RAT to nightlies.apache.org: 0 compile_1: 2 shell_11: 0 Rsync Logs to nightlies.apache.org: 0 -- ASF Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67927] TLSCertificateReloadListener triggers race condition (?) in OpenSSL code which causes the JVM to die
https://bz.apache.org/bugzilla/show_bug.cgi?id=67927 --- Comment #8 from Christopher Schultz --- Michael, do you know if calling the JMX-based "reload" operation will cause the same crash? I haven't dug-into the code, but it's possible this bug has existed far longer than the TLSCertificateReloadListener has. -- 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 67927] TLSCertificateReloadListener triggers race condition (?) in OpenSSL code which causes the JVM to die
https://bz.apache.org/bugzilla/show_bug.cgi?id=67927 --- Comment #9 from Michael Osipov --- (In reply to Christopher Schultz from comment #8) > Michael, do you know if calling the JMX-based "reload" operation will cause > the same crash? I haven't dug-into the code, but it's possible this bug has > existed far longer than the TLSCertificateReloadListener has. I have never tried the JMX-based approach, but I guess if it uses the same code paths then it is problematic as well. I thinkt hat the listener just surfaces the bug. -- 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 67932] New: module-info re-export other libraries
https://bz.apache.org/bugzilla/show_bug.cgi?id=67932
Bug ID: 67932
Summary: module-info re-export other libraries
Product: Tomcat 10
Version: unspecified
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: normal
Priority: P2
Component: Packaging
Assignee: dev@tomcat.apache.org
Reporter: jjurco...@gmail.com
Target Milestone: --
I have a problem with split packages when I use tomcat libraries. The issue is
that e.g. org.apache.tomcat.embed.core module exports:
open module org.apache.tomcat.embed.core {
…
exports jakarta.servlet;
exports org.apache.catalina;
exports org.apache.coyote;
…
}
I'm also importing a library, that has in it's module info:
module org.example.spring {
…
requires transitive jakarta.servlet;
…
}
Now, if I use those two libraries in my main application, I'm not able to
compile the project. My main module-info.java looks like:
module org.example.main.app {
…
requires org.apache.tomcat.embed.core;
…
}
However I'm not able to compile it, because module 'jakarta.servlet' required
by 'org.example.spring' is not found.
If I try to resolve it by adding a new dependency, that add 'jakarta.servlet'
module, I'm not able to compile it again, because content of package
'jakarta.servlet' is exported from two different modules, what is not allowed.
'org.apache.tomcat.embed.core' should only export those packages, that are new
in this project and do not re-export other libraries content.
Please correct me if I'm mistaken.
--
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 67927] TLSCertificateReloadListener triggers race condition (?) in OpenSSL code which causes the JVM to die
https://bz.apache.org/bugzilla/show_bug.cgi?id=67927 --- Comment #10 from Mark Thomas --- We need to allow in-progress usage of the old SSLContext to continue while new requests get the new SSLContext. We don't want new requests to have to wait for a long running request using the old SSLContext to complete. I agree we need some locking to make sure the 'current' SSLContext is updated in a thread-safe manner but I wouldn't classify that as pausing all requests. That looks to be in place on the Java side. It is rather hacky but I often find, if I can reproduce the issue, a few printf statements in the Native code can be very helpful. -- 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 67926] PEMFile prints unidentifiable string representation of ASN.1 OIDs
https://bz.apache.org/bugzilla/show_bug.cgi?id=67926 --- Comment #4 from Mark Thomas --- +1 - we are already using that class in the SPNEGO authenticator -- 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
Tomcat 9.0.74 change causes not honoring session timeout configured in tomcat web.xml for FORM Authentication
Hi All, Tomcat Version : 9.0.74 Operating System: Windows and Linux Bits: 64 Tomcat 9.0.74 not honoring session timeout configured in tomcat/conf/web.xml for FORM Authentication and it is effecting customers. == 30 // 30 minutes = Verified the Tomcat source code -FormAuthenticator overriding above configured session timeout setting (30 minutes) with value (120 seconds) -As per FormAuthenticator.Java, this change/issue started from Tomcat Version : 9.0.74 for FORM Authentication and it overwrites the original session-timeout value -This issue/behavior not observed in 9.0.73 Verified the Tomcat documentation -Verified the tomcat changelog, there is a fix/change went in Tomcat 9.0.74 below related to FORM Based Authentication Session @ https://tomcat.apache.org/tomcat-9.0-doc/changelog.html, looks which is causing this issue. -- Harden the FORM authentication process against DoS attacks by using a reduced session timeout if the FORM authentication process creates a session. The duration of this timeout is configured by the authenticationSessionTimeout attribute of the FORM authenticator. (markt) - Is it bug ? Could you please help/suggest. Thanks Channa -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. smime.p7s Description: S/MIME Cryptographic Signature
Re: Tomcat 9.0.74 change causes not honoring session timeout configured in tomcat web.xml for FORM Authentication
1. Do not cross-post the same question to multiple lists. 2. This question belongs on the users list. Mark 27 Oct 2023 05:40:09 Channa Puchakayala : Hi All, Tomcat Version : 9.0.74 Operating System: Windows and Linux Bits: 64 Tomcat 9.0.74 not honoring session timeout configured in tomcat/conf/web.xml for FORM Authentication and it is effecting customers. == 30 // 30 minutes = Verified the Tomcat source code - FormAuthenticator overriding above configured session timeout setting (30 minutes) with value (120 seconds) - As per FormAuthenticator.Java, this change/issue started from Tomcat Version : 9.0.74 for FORM Authentication and it overwrites the original session-timeout value - This issue/behavior not observed in 9.0.73 Verified the Tomcat documentation - Verified the tomcat changelog, there is a fix/change went in Tomcat 9.0.74 below related to FORM Based Authentication Session @ https://tomcat.apache.org/tomcat-9.0-doc/changelog.html, looks which is causing this issue. -- Harden the FORM authentication process against DoS attacks by using a reduced session timeout if the FORM authentication process creates a session. The duration of this timeout is configured by the *authenticationSessionTimeout* attribute of the FORM authenticator. (markt) - Is it bug ? Could you please help/suggest. Thanks Channa This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
