[GitHub] [tomcat] csutherl commented on pull request #577: Update objenesis and unboundid versions for IDE configs
csutherl commented on PR #577: URL: https://github.com/apache/tomcat/pull/577#issuecomment-1410322341 Thank you for your contribution and congrats on your first commit to the Apache Tomcat project @TochigiV! :tada: -- 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
February release round
Hi all, As I started to think about preparing for the February release round, I received the notification from the OpenSSL project that they have a security release planned for a week today. That security release may (or may not) trigger a Tomcat Native release. I was wondering whether to delay the February release round in case we need to pick up an new Tomcat Native release. It really only affects Windows users since everyone else builds their own Tomcat Native library. In the Windows case it is trivial to update the library if required so I'm not sure if it merits delaying the releases... Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Issues playing around with digest.sh
All, I was trying to run digest.sh today with some potentially unusual arguments and it was behaving in ways I didn't expect. First, I wanted to get it to generate PBKDF2 hashes, and so I tried the most obvious thing I could think of: $ digest.sh -a 'PBKDF2' 'secret' I got this error output: Jan 31, 2023 11:11:59 AM org.apache.tomcat.util.IntrospectionUtils setProperty WARNING: IntrospectionUtils: InvocationTargetException for class org.apache.catalina.realm.MessageDigestCredentialHandler algorithm=PBKDF2) java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.tomcat.util.IntrospectionUtils.setProperty(IntrospectionUtils.java:70) at org.apache.tomcat.util.IntrospectionUtils.setProperty(IntrospectionUtils.java:46) at org.apache.catalina.realm.RealmBase.main(RealmBase.java:1492) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.catalina.startup.Tool.main(Tool.java:230) Caused by: java.security.NoSuchAlgorithmException: PBKDF2 MessageDigest not available at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:159) at java.base/java.security.Security.getImpl(Security.java:700) at java.base/java.security.MessageDigest.getInstance(MessageDigest.java:183) at org.apache.tomcat.util.security.ConcurrentMessageDigest.init(ConcurrentMessageDigest.java:118) at org.apache.catalina.realm.MessageDigestCredentialHandler.setAlgorithm(MessageDigestCredentialHandler.java:90) ... 12 more Jan 31, 2023 11:11:59 AM org.apache.tomcat.util.IntrospectionUtils setProperty WARNING: IntrospectionUtils: InvocationTargetException for class org.apache.catalina.realm.SecretKeyCredentialHandler algorithm=PBKDF2) java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.tomcat.util.IntrospectionUtils.setProperty(IntrospectionUtils.java:70) at org.apache.tomcat.util.IntrospectionUtils.setProperty(IntrospectionUtils.java:46) at org.apache.catalina.realm.RealmBase.main(RealmBase.java:1492) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.catalina.startup.Tool.main(Tool.java:230) Caused by: java.security.NoSuchAlgorithmException: PBKDF2 SecretKeyFactory not available at java.base/javax.crypto.SecretKeyFactory.(SecretKeyFactory.java:118) at java.base/javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:164) at org.apache.catalina.realm.SecretKeyCredentialHandler.setAlgorithm(SecretKeyCredentialHandler.java:56) ... 12 more secret:9e667cf452bd6eddc71d9613605a2dd75527d8fb9aa2b97c918d7aa3ae9ef995$2$69049fa7dec3dc9761092ff7b4d39ac5f7b798ec Woah. Two failures and a success? Interesting. The two failures tell me that both the MessageDigestCredentialHandler and the SecretKeyCredentialHandler both failed to set that algorithm, because it doesn't exist (in either one). Super ugly and scary, but technically correct. What about that "success" I got instead? Well... it includes 2 $ symbols with 2 in between them, indicating that 2 rounds of *something* was done. The default number of rounds for SecretKeyCredentialHandler is 2 so it's likely that I got the default algorithm for that class, which is PBKDF2WithHmacSHA1. Honestly, I should probably just have gotten an error saying "couldn't decide what to do" instead of getting a weird default, especially when the default algorithm for RealmBase (which really does this work) is single-iteration, non-salted SHA-215. These switching-defaults happen because of the way the handler is chosen. The code is here in RealmBase: CredentialHandler handler = null;
Re: Issues playing around with digest.sh
On 31/01/2023 18:51, Christopher Schultz wrote: $ digest.sh -a 'PBKDF2' 'secret' If we get (swallowed) errors while trying to find out which CredentialHandler should performing the password mutation, then we just always use the last one we tried. That effectively changes the default CredentialHandler to the last one in the search list. I think we should set handler=null in the case where the algorithm failed to be set. +1 Okay, what about specifying the correct algorithm name? $ digest.sh -a 'PBKDF2WithHmacSHA1' 'secret' One failure and one success. This time, we actually got exactly what we wanted, but we still got a really scary error message. Okay, it' a warning, but it still looks scary. Would you use that output for authentication if you got a stack trace like that? I'm not sure how best to change that. I can think of two obvious potential solutions: 1. Modify the logger at runtime to suppress warnings 2. Modify IntrospectionUtils.setProperty to allow errors to be suppressed instead of logged as error I'm not sure if #1 is easily doable given lots of ways to configure logging and I'm not sure there is any appetite to do #2. We may be unable to suppress the warnings, but maybe we can add a message later that says "you can ignore any warnings you see above about missing algorithms". I think #1 is possible. The IntrospectionUtils logger is always going to be obtained via LogFactory so this should work: // Load the class to create the logger IntrospectionUtils.escape(null); // Disable warning messages LogManager.getLogManager().getLogger(IntrospectionUtils.class.getName()).setLevel(Level.SEVERE); The final problem I see is, unfortunately, a nasty quoting problem. I wanted to test this using the sample inputs provided on the Wikipedia page for PBKDF2[1], which is "eBkXQTfuBqp'cTcar&g*" (without the double-quotes). Note that it contains a single quote. I could not get digest.sh to accept that password on the command-line regardless of the way I quoted it. digset.sh calls tool-wrapper.sh using "@*". This should be correct. tool-wrapper.sh calls eval exec ... "@*" which is where I think the problem is. I think eval "unrwaps" the "@*" and the resulting command-line has a bare value at the end. In this case, it's a weird thing that includes a trifecta of problematic characters on the command-line: a single quote, an ampersand, and an asterisk. I'm not sure how to get around that other than replacing "eval exec" with "exec" or maybe removing both of them. I don't know the history of decisions that led to the use of "eval exec" but I'm sure there are Good Reasons for those things to be in there. If they have to stay, I think we have a definite limitation of the digest.sh tool in that some characters simply cannot be used in command-line parameters, which is a real shame. `eval exec` is the result of trying to handle various oddities in JAVA_OPTS and CATALINA_OPTS. I suspect we'll need to change something in tool-wrapper to fix this but I don't immediately see a solution. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129 Philippe Cloutier changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #49 from Philippe Cloutier --- (In reply to Christopher Schultz from comment #48) > This bug report has been RESOLVED WONTFIX. This ticket does not report a bug, and the issue was not resolved (as of Tomcat 8.5.13 anyway). > Please don't use Bugzilla to conduct a flame war. If you want to discuss > this (again), please raise the issue on the users' or developers' mailing > list. Mailing lists are discussion forums. Unless someone proposes a solution which has drawbacks and wants to consult about acceptability, the issue tracker is the place to discuss issues. -- 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 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129 Remy Maucherat changed: What|Removed |Added Severity|normal |enhancement -- 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 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129 --- Comment #50 from Philippe Cloutier --- Thank you very much for reporting Jörgen and all those who commented constructively My employer is one of those organizations which lost hours due to variability in loading order. For those who are still struggling to understand the behavior they are experiencing, this not only causes specific WAR files to change behavior on different Tomcat versions, but it also causes the same Tomcat version (8+) to treat 2 WAR files with the same archived contents differently. Indeed, 2 WAR files which extract to identical file sets can still be binarily different by having their files at different offsets. Typically, with Maven, if a project depends on 3 libraries and pom.xml lists B before A and finally C, the WAR file can contain b.jar before a.jar and finally c.jar. But it can also be alphabetical (a.jar, b.jar, c.jar). I've verified that the same Maven version (3.8.6) building identical code, when invoked in equivalent ways, can result in such binarily different WAR-s, which - in our case - therefore behave differently under Tomcat 8.5 on Red Hat Enterprise Linux 7. Red Hat Enterprise Linux 7's readdir visibly returns in creation order. My best guess is Maven packages .jar files in alphabetical order on Microsoft Windows, while it uses Maven's Resolved Dependencies order when packaging on Red Hat Enterprise Linux. If so, this effectively means that moving builds from Windows to GNU/Linux could suffice to cause regressions. I do not know how to avoid that besides ensuring that the WAR-s do not contain classes with identical fully qualified names. -- 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 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129 --- Comment #51 from Philippe Cloutier --- (In reply to Mateusz Matela from comment #28) > (In reply to Mark Thomas from comment #27) > > The patch would have to be very minimal and the behaviour > > optional to be considered for inclusion in Tomcat. > > Can you explain why this has to be optional? Is there any conceivable > scenario where someone would prefer to have non-deterministic behavior? I would not call the behavior of Tomcat 8+ non-deterministic. It may be *unspecified*, and it may not be as deterministic as that of previous versions, but if we look only at the order of loading on a static system (where a package is already installed and remains untouched), readdir's order looks at least generally deterministic to me. If the current order is considered determined and differs from the previous (alphabetical) order, that means going back to the previous behavior would change that order again, potentially causing the same kind of regressions that the change brought. Considering that the change was released more than 8 years ago, I do think of obvious scenarios where someone would prefer the current behavior. -- 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
