Skip to content
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

[WFCORE-4296][WFCORE-5406] Add required --add-opens for java.base/com.sun.net.ssl.internal.ssl when HTTPS is configured #4966

Merged
merged 4 commits into from Sep 16, 2023

Conversation

@github-actions github-actions bot added the deps-ok Dependencies have been checked, and there are no significant changes label Feb 9, 2022
@wildfly-ci
Copy link

Core - Full Integration Build 11374 outcome was FAILURE using a merge of 3e02eaf
Summary: Tests failed: 1 (1 new), passed: 7165, ignored: 144 Build time: 03:33:57

Failed tests

org.wildfly.extension.undertow.ServerServiceTestCase.testDefinedAttributes: java.lang.AssertionError: expected:<1> but was:<0>
	at org.wildfly.extension.undertow.ServerServiceTestCase.testDefinedAttributes(ServerServiceTestCase.java:141)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


@soul2zimate
Copy link
Contributor

soul2zimate commented Feb 10, 2022

The warning on the illegal reflective access is gone, but there is going to be a new WARNING: package com.sun.net.ssl.internal.ssl not in java.base with Java 13 or later (server boot up and jboss-cli.sh launching), Because the internal package com.sun.net.ssl has been removed since Java 13 (https://bugs.openjdk.java.net/browse/JDK-8215430). Is that OK ?

@ropalka
Copy link
Contributor Author

ropalka commented Feb 10, 2022

This is interesting problem @bstansberry . Package to be opened exists on JDK11 but doesn't exist on JDK17. I think JDK17 represent higher priority than JDK11, doesn't it? I am thinking whether to not drop this PR. WDYT?

Copy link
Contributor

@bstansberry bstansberry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fjuma
Copy link
Contributor

fjuma commented Feb 10, 2022

@ropalka Just FYI, when that method doesn't exist, a different approach is used to detect if FIPS is enabled, see:

https://issues.redhat.com/browse/WFCORE-5566

and

return () -> new SecureRandom().getProvider().getName().toLowerCase().contains("fips");

@ropalka
Copy link
Contributor Author

ropalka commented Feb 10, 2022

@bstansberry
Copy link
Contributor

@ropalka Good question, and thank you @soul2zimate for raising the point. I agree that SE 17 should get higher priority. JPMS warns in SE 11 are partly (mostly?) meant to guide people toward the right code for later releases when JPMS would be more strict. And we've been guided -- WFCORE-5566 is evidence of that.

But please leave this open as it's a good place to discuss the tradeoffs.

@ropalka
Copy link
Contributor Author

ropalka commented Feb 10, 2022

But please leave this open as it's a good place to discuss the tradeoffs.

The main problem is there is currently not available any way to detect the JVM version we are running on. Neither in shell scripts nor in Java source code. This kind of problems would be nicely solvable if we would have such detection possibility.

@yersan yersan added the rebase-this This PR must be rebased before it is merged label Mar 10, 2022
@bstansberry bstansberry removed the rebase-this This PR must be rebased before it is merged label Mar 18, 2022
@github-actions
Copy link

github-actions bot commented May 3, 2022

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

@github-actions github-actions bot added the Stale label May 3, 2022
@soul2zimate
Copy link
Contributor

Is there any decision made on this ?

@github-actions github-actions bot removed the Stale label Jun 9, 2022
@github-actions
Copy link

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

@github-actions github-actions bot added the Stale label Jul 24, 2022
@github-actions
Copy link

There has been no activity on this PR for 90 days and it has been closed automatically.

@github-actions github-actions bot closed this Oct 22, 2022
@soul2zimate
Copy link
Contributor

reopen this since the WFCORE issue is still open.

@soul2zimate soul2zimate reopened this Nov 1, 2022
@github-actions github-actions bot removed the Stale label Nov 2, 2022
@ropalka
Copy link
Contributor Author

ropalka commented Dec 13, 2022

Is there any decision made on this ?

No @soul2zimate . The problem still persists - no possibility to detect exact running JVM version in shell scripts.

@github-actions
Copy link

There has been no activity on this PR for 45 days. It will be auto-closed after 90 days.

@github-actions github-actions bot added the Stale label Jan 28, 2023
@jbliznak
Copy link
Contributor

no possibility to detect exact running JVM version in shell scripts

@ropalka why do we need exact version?

Aother idea, can't we just use the exact same trick as here (simply try the problematic argument first and act accordingly later)? https://github.com/wildfly/wildfly-core/blob/main/core-feature-pack/common/src/main/resources/content/bin/common.sh#L27-L29

@github-actions github-actions bot removed the Stale label Apr 22, 2023
@darranl darranl added the rebase-this This PR must be rebased before it is merged label May 25, 2023
@gaol
Copy link
Contributor

gaol commented Jul 4, 2023

@ropalka does what @jbliznak's suggestion make sense to you ? and may I ask you to rebase ? Thanks :)

@wildfly-ci
Copy link

Core -> WildFly Preview Integration Build 12795 outcome was FAILURE using a merge of 1914cd3
Summary: Tests failed: 1 (1 new), passed: 2651, ignored: 44 Build time: 01:52:25

Failed tests

org.wildfly.test.scripts.AppClientScriptTestCase.testBashScript: java.lang.AssertionError: Expected 2 lines.
Command Executed:
/opt/buildAgent/work/e8e0dd9c7c4ba60/full/testsuite/scripts/target/wildfly/bin/appclient.sh -v
Environment:
Output:
WARNING: package com.sun.net.ssl.internal.ssl not in java.base
&#27;[0m16:24:59,545 INFO  [org.jboss.modules] (main) JBoss Modules version 2.1.2.Final
&#27;[0mWildFly Core 22.0.0.Beta2-SNAPSHOT
 expected:<2> but was:<3>
java.lang.AssertionError: 
Expected 2 lines.
Command Executed:
/opt/buildAgent/work/e8e0dd9c7c4ba60/full/testsuite/scripts/target/wildfly/bin/appclient.sh -v
Environment:
Output:
WARNING: package com.sun.net.ssl.internal.ssl not in java.base
 [0m16:24:59,545 INFO  [org.jboss.modules] (main) JBoss Modules version 2.1.2.Final
 [0mWildFly Core 22.0.0.Beta2-SNAPSHOT
 expected:<2> but was:<3>
	at org.wildfly.test.scripts.AppClientScriptTestCase.testScript(AppClientScriptTestCase.java:52)
	at org.wildfly.test.scripts.ScriptTestCase.executeTests(ScriptTestCase.java:153)
	at org.wildfly.test.scripts.ScriptTestCase.testBashScript(ScriptTestCase.java:102)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


@ropalka ropalka force-pushed the WFCORE-4296 branch 2 times, most recently from d559874 to 33624f8 Compare September 8, 2023 07:50
@ropalka
Copy link
Contributor Author

ropalka commented Sep 12, 2023

@bstansberry please review

@ropalka ropalka removed the rebase-this This PR must be rebased before it is merged label Sep 12, 2023
Copy link
Contributor

@bstansberry bstansberry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @ropalka

I have a few comments; only substantial one is the timeout.

When this is ready please ping me in chat so I don't forget about it.

@ropalka
Copy link
Contributor Author

ropalka commented Sep 14, 2023

Fixed @bstansberry . Thanks for review!

@@ -164,7 +164,7 @@
NB: In case an update is made to these exports and opens, make sure that the common.sh script is in sync.
-->
<embedding.jar.jpms.exports>java.desktop/sun.awt java.naming/com.sun.jndi.ldap java.naming/com.sun.jndi.url.ldap java.naming/com.sun.jndi.url.ldaps jdk.naming.dns/com.sun.jndi.dns</embedding.jar.jpms.exports>
<embedding.jar.jpms.opens>java.base/java.lang java.base/java.lang.invoke java.base/java.lang.reflect java.base/java.io java.base/java.net java.base/java.security java.base/java.util java.base/java.util.concurrent java.management/javax.management java.naming/javax.naming</embedding.jar.jpms.opens>
<embedding.jar.jpms.opens>java.base/com.sun.net.ssl.internal.ssl java.base/java.lang java.base/java.lang.invoke java.base/java.lang.reflect java.base/java.io java.base/java.net java.base/java.security java.base/java.util java.base/java.util.concurrent java.management/javax.management java.naming/javax.naming</embedding.jar.jpms.opens>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ropalka @jfdenise AIUI this will result in a warning if the CLI or a bootable jar is used on SE 17. So in this case it seems we are forced to make a choice, unless there's some fancy MANIFEST.mf, etc thing in SE that allows some kind of conditional behavior.

If not, my inclination is to not add this since

  1. Getting the warn with SE 11 is the existing state, whereas introducing a warn for SE 17 would be a breaking change. All things equal, annoying a fresh set of users in order to stop annoying ones who may already be used to the warn seems a bad tradeoff.

  2. We'll be moving on from SE 11 soon enough.

Copy link
Contributor

@jbliznak jbliznak Sep 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unless there's some fancy MANIFEST.mf, etc thing in SE that allows some kind of conditional behavior.

there isn't anything conditional, but when MANIFEST.MF has add-opens/add-exports on non-existing module, it silently ignores it, so IIUC this could be fine then.

https://openjdk.org/jeps/261#Breaking-encapsulation

Two new JDK-specific JAR-file manifest attributes are defined to correspond to the --add-exports and --add-opens command-line options:

Add-Exports: <module>/<package>( <module>/<package>)*
Add-Opens: <module>/<package>( <module>/<package>)*
The value of each attribute is a space-separated list of slash-separated 
module-name/package-name pairs. 
A <module>/<package> pair in the value of an Add-Exports attribute has the same meaning 
as the command-line option --add-exports <module>/<package>=ALL-UNNAMED. 
A <module>/<package> pair in the value of an Add-Opens attribute has the same meaning 
as the command-line option --add-opens <module>/<package>=ALL-UNNAMED.

Each attribute can occur at most once, in the main section of a MANIFEST.MF file. 
A particular pair can be listed more than once. 
If a specified module was not resolved, or if a specified package does not exist, 
then the corresponding pair is ignored. 
These attributes are interpreted only in the main executable JAR file of an application,
i.e., in the JAR file specified to the -jar option of the Java run-time launcher; 
they are ignored in all other JAR files.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, a lot @jbliznak -- that's very helpful.

@bstansberry bstansberry merged commit 2d8f15c into wildfly:main Sep 16, 2023
12 checks passed
@bstansberry
Copy link
Contributor

Thanks @ropalka and @jbliznak

@ropalka
Copy link
Contributor Author

ropalka commented Sep 18, 2023

@jbliznak is right. Not existenting values of add-opens or add-exports attributes in MANIFEST.MF are silently ignored for executable jar files.

@ropalka
Copy link
Contributor Author

ropalka commented Sep 18, 2023

Thanks for review and merge of this PR @bstansberry

@ropalka
Copy link
Contributor Author

ropalka commented Sep 18, 2023

I provided a reproducer (for the claim about executable jars) and attached it to the JIRA @bstansberry

@ropalka ropalka deleted the WFCORE-4296 branch September 18, 2023 08:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deps-ok Dependencies have been checked, and there are no significant changes
Projects
None yet
9 participants