Re: Native Compilation, Continuation 2022
On 11/04/2022 23: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 Keep in mind I have not been as involved in these changes as other folks have so while I am expressing my current opinions below, I am likely to defer to the folks that have been more involved if their opinion differs from mine. Back to Proposal 1. Remove tomcat-embed-programmatic I believe this served its purpose. If there is consensus that it has served its purpose then removal makes sense. I have no view on whether tomcat-embed-programmatic has served its purpose or not. Would this be deprecation in 9.0.x/10.0.x and removal in 10.1.x? 2. Refactor existing graal JSON files This can allow us to create profiles with various memory footprints depending on functionality desired. Seems reasonable to me. 3. Potentially introduce tomcat-embed-graal This can have various code substitutions that we find beneficial. [4] If this sits alongside the existing code in a separate package and JAR (or something along those lines) then that seems reasonable to me. 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. This is the interesting one. I think there is a balance to strike here between making native compilation easier and making the existing code less clear. I think I'd want to look at each proposed refactoring on a case-by-case basis. Generally, I'm willing to consider a little more complexity but I suspect there will be some cases where substitution is the better option. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66008] New: Jasper Documentation is misleading (if not wrong) about the trimSpaces option
https://bz.apache.org/bugzilla/show_bug.cgi?id=66008 Bug ID: 66008 Summary: Jasper Documentation is misleading (if not wrong) about the trimSpaces option Product: Tomcat 10 Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: seeb...@orcasys.ch Target Milestone: -- The documentation "Jasper 2 JSP Engine How To" (https://tomcat.apache.org/tomcat-10.0-doc/jasper-howto.html) states under Production Configuration: trimSpaces - To remove useless bytes from the response, set this to true. This is misleading and dangerous (if not just plain wrong): trimSpace=true removes all spaces between jsp-tags and therefore may affect output. Example: The following line will print differently with trimSpaces=true than with trimSpaces=false The text in the documentation should be changed to: trimSpaces - To remove useless bytes from the response, set this to single. The same applies to Tomcat 9 Previous Tomcat versions don't have the "single" option. For these tomcats, that misleading line should be removed or at least a warning should be added, that output may look different if trimSpaces is enabled. -- 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] New: 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 Bug ID: 66009 Summary: M-TLS Fails, no user is found because "OID.2.5.4.5" is used as field name instead of "SERIALNUMBER", in Subject Product: Tomcat 9 Version: 9.0.62 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: bzapa...@dierdorp.nl Target Milestone: - We upgraded from Tomcat 9.0.60 to 9.0.62 and the Mutual-TLS failed. Logging from Tomcat 9.0.60 (M-TLS Works) 01 org.apache.catalina.authenticator.AuthenticatorBase.invoke Security checking request POST /speer/soap/services/somefunctionality 02 org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking constraint 'SecurityConstraint[MijnvfRealm]' against POST /services/somefunctionality --> true 03 org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking constraint 'SecurityConstraint[MijnvfRealm]' against POST /services/somefunctionality --> true 04 org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling hasUserDataPermission() 05 org.apache.catalina.realm.RealmBase.hasUserDataPermission User data constraint already satisfied 06 org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling authenticate() 07 org.apache.catalina.realm.CombinedRealm.authenticate Attempting to authenticate user [CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000] with realm [org.apache.catalina.realm.UserDatabaseRealm] 08 org.apache.catalina.realm.RealmBase.authenticate Authenticating client certificate chain 09 org.apache.catalina.realm.RealmBase.authenticate Checking validity for 'CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000' 10 org.apache.catalina.realm.RealmBase.authenticate Checking validity for 'CN=cnCA, O=o, C=c' 11 org.apache.catalina.realm.RealmBase.getPrincipal Got user name from X509 certificate: [CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000] 12 org.apache.catalina.realm.CombinedRealm.authenticate Authenticated user [CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000] with realm [org.apache.catalina.realm.UserDatabaseRealm] 13 org.apache.catalina.authenticator.AuthenticatorBase.register Authenticated 'CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000' with type 'CLIENT_CERT' 14 org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling accessControl() 15 org.apache.catalina.realm.RealmBase.hasResourcePermission Checking roles GenericPrincipal[CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000()] 16 org.apache.catalina.realm.RealmBase.hasRole Username [CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000] has role [correctUser] 17 org.apache.catalina.realm.RealmBase.hasResourcePermission Role found: correctUser 18 org.apache.catalina.authenticator.AuthenticatorBase.invoke Successfully passed all security constraints Logging from Tomcat 9.0.62 (M-TLS fails, no/wrong user found) 01 org.apache.catalina.authenticator.AuthenticatorBase.invoke Security checking request POST /speer/soap/services/somefunctionality 02 org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking constraint 'SecurityConstraint[MijnvfRealm]' against POST /services/somefunctionality --> true 03 org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking constraint 'SecurityConstraint[MijnvfRealm]' against POST /services/somefunctionality --> true 04 org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling hasUserDataPermission() 05 org.apache.catalina.realm.RealmBase.hasUserDataPermission User data constraint already satisfied 06 org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling authenticate() 07 org.apache.catalina.realm.CombinedRealm.authenticate Attempting to authenticate user [CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000] with realm [org.apache.catalina.realm.UserDatabaseRealm] 08 org.apache.catalina.realm.RealmBase.authenticate Authenticating client certificate chain 09 org.apache.catalina.realm.RealmBase.authenticate Checking validity for 'CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000' 10 org.apache.catalina.realm.RealmBase.authenticate Checking validity for 'CN=cnCA, O=o, C=c' 11 org.apache.catalina.realm.RealmBase.getPrincipal Got user name from X509 certificate: [CN=cn, O=o, L=l, ST=st, C=c, OID.2.5.4.5=0001804415183000] 12 org.apache.catalina.realm.CombinedRealm.authenticate Failed to authenticate user [CN=cn, O=o, L=l, ST=st, C=c, SERIALNUMBER=0001804415183000] with realm [org.apache.catalina.realm.UserDatabaseRealm] 13 org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed authenticate() test If you look at line 11, in both logging you can see that "OID.2.5.4.5" is used in Tomcat 9.0.62 and "SERIALNUMBER" in Tomc
Re: Native Compilation, Continuation 2022
On Tue, Apr 12, 2022 at 9:14 AM Mark Thomas wrote: > > On 11/04/2022 23: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 > > Keep in mind I have not been as involved in these changes as other folks > have so while I am expressing my current opinions below, I am likely to > defer to the folks that have been more involved if their opinion differs > from mine. > > > > > Back to Proposal > > 1. Remove tomcat-embed-programmatic > > I believe this served its purpose. > > If there is consensus that it has served its purpose then removal makes > sense. I have no view on whether tomcat-embed-programmatic has served > its purpose or not. > > Would this be deprecation in 9.0.x/10.0.x and removal in 10.1.x? > > > 2. Refactor existing graal JSON files > > This can allow us to create profiles with various memory footprints > > depending on functionality desired. > > Seems reasonable to me. > > > 3. Potentially introduce tomcat-embed-graal > > This can have various code substitutions that we find beneficial. [4] > > If this sits alongside the existing code in a separate package and JAR > (or something along those lines) then that seems reasonable to me. > > > 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. > > This is the interesting one. > > I think there is a balance to strike here between making native > compilation easier and making the existing code less clear. I think I'd > want to look at each proposed refactoring on a case-by-case basis. > Generally, I'm willing to consider a little more complexity but I > suspect there will be some cases where substitution is the better option. Yes, I agree with that opinion, it's all about good balance. I'm not sure that the additional benefits that remain matter a lot (as an example, embedded code generation does something, but it's really little; generating the full web.xml processing was something I tried, but it starts being very complex very quickly), so this better not do anything that would look weird or convoluted to achieve something. Overall Tomcat is still EE so it's never going to be fully optimal for Graal, which IMO is not the end of the world (the container remains small compared to the app, so any savings will be hard to notice; feel free to prove me wrong ;) ). Last, there will be more AOT techs after Graal. 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
[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 #1 from Remy Maucherat --- (In reply to Maikel from comment #0) > Possible suspect is release 9.0.61, and the change in Coyote, > https://tomcat.apache.org/tomcat-9.0-doc/changelog.html I recommend you investigate this further. The relevant change is not in the changelog I think: https://github.com/apache/tomcat/commit/38d2c138a102a793bce630056fbca7088b7e05a3 https://github.com/apache/tomcat/commit/b21268dcebc3d470430227978caa4f168a3346d4 Is this really equivalent in all cases ? -- 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 #2 from Michael Osipov --- Although, I haven't analyzed recent changes, the problem you see is different representations of the ASN.1 encoded subject DN. Here (https://github.com/apache/tomcat/blob/431f08b66e27411decb52e1333dd886cc181a854/java/org/apache/catalina/realm/RealmBase.java#L454-L455) it uses https://docs.oracle.com/javase/8/docs/api/javax/security/cert/X509Certificate.html#getIssuerDN-- which does not describe the format which is applied, but X509SubjectDnRetriever uses RFC 1779 (https://github.com/apache/tomcat/blob/431f08b66e27411decb52e1333dd886cc181a854/java/org/apache/catalina/realm/X509SubjectDnRetriever.java#L31) which is totally outdated. Moreover, depending on the X.500 Principal format you select Java maintains an internal map which OIDs can be reasonably mapped from ASN.1 to a string. Especially 2.5.4.5 is a total mess. I have a certificate processing application at work where I apply a custom formatting to properly canonicalize RFC 2253 formatted output with all possible OIDs Java will not map by default. I assume the codebase in Tomcat needs to be analyzed and apply similar. (My custom approach bases on the way OpenSSL handles DNs) -- 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 #3 from Konstantin Kolinko --- (In reply to Remy Maucherat from comment #1) > (In reply to Maikel from comment #0) > > Possible suspect is release 9.0.61, and the change in Coyote, > > https://tomcat.apache.org/tomcat-9.0-doc/changelog.html > > I recommend you investigate this further. > > The relevant change is not in the changelog I think: > https://github.com/apache/tomcat/commit/38d2c138a102a793bce630056fbca7088b7e05a3 > https://github.com/apache/tomcat/commit/b21268dcebc3d470430227978caa4f168a3346d4 > Is this really equivalent in all cases ? To help investigate this: Note that an implementation of org.apache.catalina.realm.X509UsernameRetriever that was changed by those commits is configurable, with "X509UsernameRetrieverClassName" attribute on a Realm. https://tomcat.apache.org/tomcat-9.0-doc/config/realm.html So that you can configure your own. -- 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-native] branch main updated: Fix typo
This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/main by this push: new c4c3b1372 Fix typo c4c3b1372 is described below commit c4c3b1372fe1b4db8a21de6f40334a83533a382f Author: Michael Osipov AuthorDate: Wed Apr 13 08:27:03 2022 +0200 Fix typo --- xdocs/miscellaneous/changelog.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xdocs/miscellaneous/changelog.xml b/xdocs/miscellaneous/changelog.xml index 2dafcbde9..8bd9bf42d 100644 --- a/xdocs/miscellaneous/changelog.xml +++ b/xdocs/miscellaneous/changelog.xml @@ -142,7 +142,7 @@ Remove default option passed for rpath to linker on HP-UX. (michaelo) - Add an option to allow the OCSP responder check to by bypassed. Note that + Add an option to allow the OCSP responder check to be bypassed. Note that if OCSP is enabled, a missing responder is now treated as an error. (jfclere) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
