-
Notifications
You must be signed in to change notification settings - Fork 82
Try direct path for MessageDigest before invasive path #194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This logic is responsible for the remaining known "illegal access" warning on Java 9+. I am not sure why we do not trust the default provide to give us most algorithms, since it should be identical to the one provied by Bouncy Castle. This change reverses the logic and only uses the invasive provider-specific form when the direct lookup fails. Relates to jruby/jruby#6098.
Thanks, not sure these reports will stop coming unless smt is done about |
@kares Ideally this is a step toward not using it at all. Both of the cases I've fixed have turned out to be unnecessary. I left the fallback logic in place for unusual hashes, but it seems like nearly all of the hashes supported by CRuby are supported by OpenJDK:
Of the digests listed here, only two appear to have issues: MD4 and MDC2:
MD4 is preceded by the illegal access warning, so I assume that means it must come from Bouncy Castle. MDC2 does not appear to be supported by either OpenJDK or Bouncy Castle and likely has never worked. It's also not clear to me why we need to get digest implementations from a specific provider; these are simple algorithms and could probably be instantiated directly. There's another change we could, and perhaps should make to these SecurityHelper accesses: make them use my backport9 library to test if these classes are open before attempting to access their internals. In this case, it would mean the MD4 algorithm would not be supported on a Java 9+ OpenJDK (until we add it). |
Hi! I'm trying to get rid of this warning, which I believe has been fixed on I tried to compile and install the master version of the gem locally, but getting this errors (I seem to be building an empty jar):
Any hints? |
@deivid-rodriguez The first warning is not related to our code. I would guess it's a Maven plugin that has not been updated for Java 9+ reflection restrictions. Perhaps there's a newer plugin? Running with Java option The stack of five warnings later in the build are indeed from JRuby but it's a JRuby version used by the gem-maven-plugin. Upgrading that plugin to a newer version of JRuby should eliminate the first four. The fifth might go away as well, but it's used by the native IO subsystem and compatibility may be altered. |
@deivid-rodriguez Oh, FWIW this would be good to file as a separate issue, perhaps after digging up more details like plugin versions etc. |
@headius Thanks. What about the error? You mentioned five warnings, but not the actual error. Anyways, I opened a separate ticket. |
Oh I misunderstood...I thought you were asking how to get rid of those warnings :-) I'll have a look in the other issue. |
Yeah, my bad, not very well explained. When I said "this warning" I meant "the warning that presumabily got fixed by this PR" :) |
This logic is responsible for the remaining known "illegal access"
warning on Java 9+. I am not sure why we do not trust the default
provide to give us most algorithms, since it should be identical
to the one provied by Bouncy Castle. This change reverses the
logic and only uses the invasive provider-specific form when the
direct lookup fails.
Relates to jruby/jruby#6098.