[Bug 64862] Improve LibreSSL support
https://bz.apache.org/bugzilla/show_bug.cgi?id=64862 --- Comment #1 from Michael Osipov --- As of libressl-portable: b52dc3d9b292f4f644d7506a2d62df11f2a6e269 tomcat-native: 1.2.32 tomcat-native does not compile anymore: > $ make > /bin/sh /usr/local/share/apr/build-1/libtool --silent --mode=compile cc -O2 > -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing > -DHAVE_CONFIG_H-DLIBICONV_PLUG -g -O2 -DHAVE_OPENSSL > -DHAVE_POLLSET_WAKEUP -I./include -I/usr/local/openjdk8/include > -I/usr/local/openjdk8/include/freebsd -I/tmp/libressl/include > -I/usr/local/include/apr-1 -o src/ssl.lo -c src/ssl.c && touch src/ssl.lo > In file included from src/ssl.c:24: > ./include/ssl_private.h:221:9: warning: 'OPENSSL_VERSION' macro redefined > [-Wmacro-redefined] > #define OPENSSL_VERSION SSLEAY_VERSION > ^ > /tmp/libressl/include/openssl/crypto.h:320:9: note: previous definition is > here > #define OPENSSL_VERSION 0 > ^ > src/ssl.c:221:15: error: incomplete definition of type 'struct dh_st' > BN_free(dh->p); > ~~^ > /tmp/libressl/include/openssl/ossl_typ.h:132:16: note: forward declaration of > 'struct dh_st' > typedef struct dh_st DH; >^ > src/ssl.c:222:15: error: incomplete definition of type 'struct dh_st' > BN_free(dh->q); > ~~^ > /tmp/libressl/include/openssl/ossl_typ.h:132:16: note: forward declaration of > 'struct dh_st' > typedef struct dh_st DH; >^ > src/ssl.c:223:15: error: incomplete definition of type 'struct dh_st' > BN_free(dh->g); > ~~^ > /tmp/libressl/include/openssl/ossl_typ.h:132:16: note: forward declaration of > 'struct dh_st' > typedef struct dh_st DH; >^ > src/ssl.c:224:7: error: incomplete definition of type 'struct dh_st' > dh->p = p; > ~~^ > /tmp/libressl/include/openssl/ossl_typ.h:132:16: note: forward declaration of > 'struct dh_st' > typedef struct dh_st DH; >^ > src/ssl.c:225:7: error: incomplete definition of type 'struct dh_st' > dh->q = q; > ~~^ > /tmp/libressl/include/openssl/ossl_typ.h:132:16: note: forward declaration of > 'struct dh_st' > typedef struct dh_st DH; >^ > src/ssl.c:226:7: error: incomplete definition of type 'struct dh_st' > dh->g = g; > ~~^ > /tmp/libressl/include/openssl/ossl_typ.h:132:16: note: forward declaration of > 'struct dh_st' > typedef struct dh_st DH; >^ > src/ssl.c:229:11: error: incomplete definition of type 'struct dh_st' > dh->length = BN_num_bits(q); > ~~^ > /tmp/libressl/include/openssl/ossl_typ.h:132:16: note: forward declaration of > 'struct dh_st' > typedef struct dh_st DH; >^ > src/ssl.c:989:21: error: incomplete definition of type 'struct bio_st' > j = (BIO_JAVA *)BIO_get_data(bi); > ^~~ > ./include/ssl_private.h:233:44: note: expanded from macro 'BIO_get_data' > #define BIO_get_data(x) (x->ptr) > ~^ > /tmp/libressl/include/openssl/ossl_typ.h:111:16: note: forward declaration of > 'struct bio_st' > typedef struct bio_st BIO; >^ > src/ssl.c:1008:21: error: incomplete definition of type 'struct bio_st' > j = (BIO_JAVA *)BIO_get_data(bi); > ^~~ > ./include/ssl_private.h:233:44: note: expanded from macro 'BIO_get_data' > #define BIO_get_data(x) (x->ptr) > ~^ > /tmp/libressl/include/openssl/ossl_typ.h:111:16: note: forward declaration of > 'struct bio_st' > typedef struct bio_st BIO; >^ > src/ssl.c:1023:5: error: incomplete definition of type 'struct bio_st' > BIO_set_shutdown(bi, 1); > ^~~ > ./include/ssl_private.h:235:44: note: expanded from macro 'BIO_set_shutdown' > #define BIO_set_shutdown(x,v)(x->shutdown=v) > ~^ > /tmp/libressl/include/openssl/ossl_typ.h:111:16: note: forward declaration of > 'struct bio_st' > typedef struct bio_st BIO; >^ > src/ssl.c:1024:5: error: incomplete definition of type 'struct bio_st' > BIO_set_init(bi, 0); > ^~~ > ./include/ssl_private.h:232:44: note: expanded from macro 'BIO_set_init' > #define BIO_set_init(x,v)(x->init=v) > ~^ > /tmp/libressl/include/openssl/ossl_typ.h:111:16: note: forward declaration of > 'struct bio_st' > typedef struct bio_st BIO; >^ > src/ssl.c:1032:5: error: incomplete definition of type 'struct bio_st' > BIO_set_data(bi, (void *)j); > ^~~ > ./include/ssl_private.h:234:44: note: expanded from macro 'BIO_set_data' > #define BIO_set_data(x,v)(x->ptr=v) > ~^ > /tmp/libressl/include/openssl/ossl_typ.h:111:16: note: forward declaration of
[Bug 66005] Apache crashes, if there is a tomcat server, which can not be resolved
https://bz.apache.org/bugzilla/show_bug.cgi?id=66005
--- Comment #1 from Lothar ---
I did some further investigation. with strace
SEGSEGV was raised 0.44 after start up:
0.44 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_USER, si_pid=52811,
si_uid=0} ---
0.116226 +++ killed by SIGSEGV (core dumped) +++
OS: 4.18.0-348.20.1.el8_5.x86_64
on a reference machine with 4.18.0-348.7.1.el8_5.x86_64 it works, even if
there are workers, which could not be resolved.
--
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 66009] M-TLS Fails, no user is found because "OID.2.5.4.5" is used as field name instead of "SERIALNUMBER", in Subject
https://bz.apache.org/bugzilla/show_bug.cgi?id=66009 Remy Maucherat changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Remy Maucherat --- Thanks for the comments. Overall I would need a test certificate to see what each different method does. I don't know why getName(X500Principal.RFC1779) was used in X509UsernameRetriever instead of getName(X500Principal.RFC2253) or simply getName() (which simply uses X500Principal.RFC2253). Alternately, you can try to test by using X509UsernameRetrieverClassName as Konstantin said (thanks, great tip !). -- 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 66009] M-TLS Fails, no user is found because "OID.2.5.4.5" is used as field name instead of "SERIALNUMBER", in Subject
https://bz.apache.org/bugzilla/show_bug.cgi?id=66009 --- Comment #5 from Maikel --- Thanks for the information, I did not know I could use X509UsernameRetrieverClassName to change the behavior. We where using the certificate functionality out of the box with only some changes in the config files. I now use the workaround by adding the "OID.2.5.4.5" version also in the "tomcat-users.xml" file. That works. -- 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 66005] Apache crashes, if there is a tomcat server, which can not be resolved
https://bz.apache.org/bugzilla/show_bug.cgi?id=66005 --- Comment #2 from Christopher Schultz --- You have no provided enough information to investigate this crash. Does the log file end after what you have posted? Please post the full backtrace of the crash, or, if you are comfortable doing so, the core file from the crash. -- 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 66005] Apache crashes, if there is a tomcat server, which can not be resolved
https://bz.apache.org/bugzilla/show_bug.cgi?id=66005 Christopher Schultz changed: What|Removed |Added Status|NEW |NEEDINFO -- 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: Native Compilation, Continuation 2022
Filip, On 4/11/22 18:32, Filip Hanik wrote: Hi folks, I'm jumping in on the bandwagon again. Specifically to talk some more about native compilation. The graal compiler is making headway, and it's becoming better and better at native compilation [1]. I'll put some historical context at the bottom of this post for clarity. I have a few suggestions that I'd like some input on 1. Get rid of tomcat-embed-programmatic Why? Does it interfere with providing GraalVM support? 2. Refactor existing graal JSON instructions [2] 3. Potentially introduce tomcat-embed-graal 4. Add in build feature flags to the code or code optimizations Today The amount of input we can provide to the graal compiler today, lets us work around many of the issues that were the reason for the tomcat-embed-programmatic. For example, graal can apply build time code substitution, like mentioned here [4]. We can also provide multiple JSON files [2], and effectively create profiles. So there can be an NIO profile, an NIO2 profile and an APR profile, if that's desired. Back to Proposal 1. Remove tomcat-embed-programmatic I believe this served its purpose. How would anyone use Tomcat in an embedded way without this? Or are you suggesting that a tomcat-embed-graal could be used in its place, but without actually using GraalVM? Say some product wants to ship with (a) Tomcat embedded (using whatever strategy, where the application orchestrates the launch of the servlet container instead of the container launching the application) and (b) OpenJDK (or pick your JVM). Would that still be possible? Because taking that away would be a Bad Thing IMHO. 2. Refactor existing graal JSON files This can allow us to create profiles with various memory footprints depending on functionality desired. 3. Potentially introduce tomcat-embed-graal This can have various code substitutions that we find beneficial. [4] 4. Add in build feature flags to the code or code optimizations graal can still do static analysis to optimize inclusion of code paths. as demonstrated in this example [5]. As this seems to pollute our codebase with graal specific stuff when it could have been done as a substitution, I'm still presenting it to gather more opinions. Filip Historical Context When we created tomcat-embed-programmatic, we did so to reduce the memory footprint[3] of the simplest tomcat installation. At the time, the graal compiler was indiscriminate and would absorb virtually any class file in a library. So we created an experimental jar, tomcat-embed-programmatic, that was reduced to be embedded, no resource files, no XML support, and removed the reflection property setters for configurable components. Hmm. Perhaps I don't understand exactly what tomcat-embed-programmatic means. I was thinking you were talking about dropping the Tomcat class which is used to launch Tomcat from other Java code. Apologies if I'm speaking from a position of ignorance. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66008] Jasper Documentation is misleading (if not wrong) about the trimSpaces option
https://bz.apache.org/bugzilla/show_bug.cgi?id=66008 --- Comment #1 from Christopher Schultz --- This seems like a matter of opinion over the definition of "useless". The whole point of the option *is* to affect the output. The documentation could be improved for "Production Configuration" to (a) be less forceful about using trimSpaces and (b) encourage the user to read the complete documentation for that configuration item instead of simply recommending the value of "true". Patches are always welcome. -- 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 66009] M-TLS Fails, no user is found because "OID.2.5.4.5" is used as field name instead of "SERIALNUMBER", in Subject
https://bz.apache.org/bugzilla/show_bug.cgi?id=66009 --- Comment #6 from Christopher Schultz --- (In reply to Remy Maucherat from comment #1) > https://github.com/apache/tomcat/commit/ > b21268dcebc3d470430227978caa4f168a3346d4 My guess is that the above patch will fix this issue. Can you please provide a copy of the certificate and we can double-check the behavior of getSubjectDN() vs getX500Principal().getName() vs getX500Principal().getName(X500Principal.RFC1779)? Alternatively, we could provide you with a simple Java utility to look at the cert and print those values. -- 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 66009] M-TLS Fails, no user is found because "OID.2.5.4.5" is used as field name instead of "SERIALNUMBER", in Subject
https://bz.apache.org/bugzilla/show_bug.cgi?id=66009
--- Comment #7 from Christopher Schultz ---
Actually, this ought to do the trick:
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import javax.security.auth.x500.X500Principal;
public class CertInfo {
public static void main(String[] args) throws Exception {
CertificateFactory cf = CertificateFactory.getInstance("X.509");
Certificate cert = cf.generateCertificate(System.in);
if(cert instanceof X509Certificate) {
System.out.println("Certificate is X.509");
X509Certificate xc = (X509Certificate)cert;
System.out.println("getSubjectDN: " + xc.getSubjectDN());
System.out.println("getSubjectX500Principal.getName: " +
xc.getSubjectX500Principal().getName());
System.out.println("getSubjectX500Principal.getName(RFC1779): " +
xc.getSubjectX500Principal().getName(X500Principal.RFC1779));
}
}
}
--
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: Native Compilation, Continuation 2022
On Wed, Apr 13, 2022 at 9:45 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Filip, > > On 4/11/22 18:32, Filip Hanik wrote: > > Hi folks, > > > > I'm jumping in on the bandwagon again. Specifically to talk some more > about > > native compilation. The graal compiler is making headway, and it's > becoming > > better and better at native compilation [1]. > > > > I'll put some historical context at the bottom of this post for clarity. > I > > have a few suggestions that I'd like some input on > > > > 1. Get rid of tomcat-embed-programmatic > > Why? Does it interfere with providing GraalVM support? > tomcat-embed-programmatic.jar is a subset of the existing tomcat-embed-core.jar Moving forward, we'd like to not have to create a secondary artifact, if we can achieve the same optimizations by using the existing artifact tomcat-embed-core.jar > > > 2. Refactor existing graal JSON instructions [2] > > 3. Potentially introduce tomcat-embed-graal > > 4. Add in build feature flags to the code or code optimizations > > > > Today > > The amount of input we can provide to the graal compiler today, lets us > > work around many of the issues that were the reason for the > > tomcat-embed-programmatic. > > > > For example, graal can apply build time code substitution, like mentioned > > here [4]. We can also provide multiple JSON files [2], and effectively > > create profiles. So there can be an NIO profile, an NIO2 profile and an > APR > > profile, if that's desired. > > > > Back to Proposal > > 1. Remove tomcat-embed-programmatic > > I believe this served its purpose. > > How would anyone use Tomcat in an embedded way without this? Or are you > suggesting that a tomcat-embed-graal could be used in its place, but > without actually using GraalVM? Say some product wants to ship with (a) > Tomcat embedded (using whatever strategy, where the application > orchestrates the launch of the servlet container instead of the > container launching the application) and (b) OpenJDK (or pick your JVM). > Would that still be possible? Because taking that away would be a Bad > Thing IMHO. > It may be easier if I illustrate this via the graal native compilation command, where the classpath changes ## Optimized Tomcat today - uses modified programmatic artifact to achieve optimal size native-image \ #compiler -H:Name=my-app-native \ #name of produced binary -cp ../embed/tomcat-embed-programmatic.jar:my-application.jar \ #classpath org.example.MyNativeEmbeddedTomcat #launch class ## Optimized Tomcat tomorrow - achieve the same optimizations native-image \ #compiler -some-flag \ #flags that select an optimized embedded tomcat profile, for example NIO only -H:Name=my-app-native \ #name of produced binary -cp ../embed/tomcat-embed-core.jar:my-application.jar \ #classpath org.example.MyNativeEmbeddedTomcat #launch class > > > 2. Refactor existing graal JSON files > > This can allow us to create profiles with various memory footprints > > depending on functionality desired. > > > > 3. Potentially introduce tomcat-embed-graal > > This can have various code substitutions that we find beneficial. [4] > > > > 4. Add in build feature flags to the code or code optimizations > > graal can still do static analysis to optimize inclusion of code paths. > as > > demonstrated in this example [5]. As this seems to pollute our codebase > > with graal specific stuff when it could have been done as a substitution, > > I'm still presenting it to gather more opinions. > > > > Filip > > > > Historical Context > > When we created tomcat-embed-programmatic, we did so to reduce the memory > > footprint[3] of the simplest tomcat installation. At the time, the graal > > compiler was indiscriminate and would absorb virtually any class file in > a > > library. So we created an experimental jar, tomcat-embed-programmatic, > that > > was reduced to be embedded, no resource files, no XML support, and > removed > > the reflection property setters for configurable components. > > Hmm. Perhaps I don't understand exactly what tomcat-embed-programmatic > means. I was thinking you were talking about dropping the Tomcat class > which is used to launch Tomcat from other Java code. > tomcat-embed-programmatic == tomcat-embed-core NIO2/APR/string resources/other-code-that-isn't-needed Basically, to produce tomcat-embed-programmatic, we took the "core" artifact, and removed files from the .jar file that we knew belonged in code paths that wouldn't get executed. Filip > Apologies if I'm speaking from a position of ignorance. > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[Bug 66013] New: missing class javax.servlet.jsp.tagext.TagExtraInfo used by org.apache.jasper.compiler.TagLibraryInfoImpl
https://bz.apache.org/bugzilla/show_bug.cgi?id=66013 Bug ID: 66013 Summary: missing class javax.servlet.jsp.tagext.TagExtraInfo used by org.apache.jasper.compiler.TagLibraryInfoImpl Product: Tomcat 10 Version: 10.0.20 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: tomas.ju...@gmail.com Target Milestone: -- missing class javax.servlet.jsp.tagext.TagExtraInfo used by org.apache.jasper.compiler.TagLibraryInfoImpl.java. The class TagExtraInfo exist but under package jakarta.servlet.jsp.tagext.TagExtraInfo.class -- 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
[GitHub] [tomcat] k4n5ha0 opened a new pull request, #504: disable jsp and jspx by default
k4n5ha0 opened a new pull request, #504: URL: https://github.com/apache/tomcat/pull/504 jsp and jspx is dangerous. likes spring4shell and others hacker,they use uplaod jsp or write a webshell to disk. If project need jsp or jspx, they pack web.xml in war with jsp mappings by themself. secure by default. thx! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf commented on pull request #504: disable jsp and jspx by default
markt-asf commented on PR #504: URL: https://github.com/apache/tomcat/pull/504#issuecomment-1098727906 This is a bad idea for so many different reasons. To name a few: - "Spring4Shell" allows arbitrary file uploads. All an attacker has to do to bypass this change is to upload a web.xml file that re-enables the mapping - It does nothing to help users that want/need to use JSPs. - Users that had followed the documented security recommendations and set OS file permissions appropriately would have been protected not only against "Spring4Shell"but against any similar vulnerability as well -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf closed pull request #504: disable jsp and jspx by default
markt-asf closed pull request #504: disable jsp and jspx by default URL: https://github.com/apache/tomcat/pull/504 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
