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

[GR-47922] Enforce -H:±UnlockExperimentalVMOptions #7370

Open
2 of 5 tasks
fniephaus opened this issue Sep 7, 2023 · 8 comments
Open
2 of 5 tasks

[GR-47922] Enforce -H:±UnlockExperimentalVMOptions #7370

fniephaus opened this issue Sep 7, 2023 · 8 comments
Assignees
Labels

Comments

@fniephaus
Copy link
Member

fniephaus commented Sep 7, 2023

-H:±UnlockExperimentalVMOptions was introduced in GraalVM for JDK 21 (see #7105). This is a follow up issue to track outstanding tasks such as its enforcement, bugs and improvements, or API option changes.

Main task

  • Turn unlocking warning into a failure. This has the highest priority.

Bug fixes and improvements

API changes

@zakkak
Copy link
Collaborator

zakkak commented Sep 7, 2023

Feature request

Add stable option for -H:AdditionalSecurityProviders

Is your feature request related to a problem? Please describe.

Starting with 23.1 using -H:AdditionalSecurityProviders results in a warning like the following:

Warning: The option '-H:AdditionalSecurityProviders=org.wildfly.security.password.WildFlyElytronPasswordProvider' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: Please re-evaluate whether any experimental option is required, and either remove or unlock it. The build output lists all active experimental options, including where they come from and possible alternatives. If you think an experimental option should be considered as stable, please file an issue.

Four core Quarkus Extensions (security, elytron-security-jdbc, kafka-client, infinispan-client) rely on this option to define additional security providers.

Describe the solution you'd like.

Provide a stable way to define additional security providers, either making this option stable or adding a new API option.

Describe who do you think will benefit the most.
GraalVM users and developers of libraries and frameworks which depend on GraalVM

Describe alternatives you've considered.
Wrap it in -H:+UnlockExperimentalVMOptions and -H:-UnlockExperimentalVMOptions.

@cstancu
Copy link
Member

cstancu commented Sep 8, 2023

@zakkak I'm actually curious why do you need to use -H:AdditionalSecurityProviders? Is it because the WildFlyElytronPasswordProvider relies on the SHA512_256MessageDigest service which is not JCA compliant, i.e., it doesn't declare a getInstance() method? Why not make SHA512_256MessageDigest JCA compliant instead and use -H:AdditionalSecurityServiceTypes to declare the custom service type and enable automatic processing by SecurityServicesFeature.registerServiceReachabilityHandlers(). Or do you completely disable -H:-EnableSecurityServicesFeature?

@zakkak
Copy link
Collaborator

zakkak commented Sep 11, 2023

@sberyozkin can you please have a look at ^^?

Or do you completely disable -H:-EnableSecurityServicesFeature?

No we don't disable this.

zakkak added a commit to zakkak/quarkus that referenced this issue Oct 16, 2023
Starting with Mandrel 23.1 and GraalVM for JDK 21 the use of
`-H:ResourceConfigurationFiles` and `-H:ReflectionConfigurationFiles` is
marked as experimental and requires the use of
`-H::±UnlockExperimentalVMOptions` to avoid warnings (see
oracle/graal#7190), while in the future (planned
for the next release) the presence of this option will be mandatory when
using experimental options (see
oracle/graal#7370).

Furthermore, as described in oracle/graal#7487
Mandrel and GraalVM will also adopt glob patterns in the future (planned
for the next release) and gradually phase out the ability to use exclude
patterns.

The aim of this change is to discourage Quarkus users from creating
their own configuration files.
zakkak added a commit to zakkak/quarkus that referenced this issue Oct 16, 2023
Starting with Mandrel 23.1 and GraalVM for JDK 21 the use of
`-H:ResourceConfigurationFiles` and `-H:ReflectionConfigurationFiles` is
marked as experimental and requires the use of
`-H::±UnlockExperimentalVMOptions` to avoid warnings (see
oracle/graal#7190), while in the future (planned for the next release)
the presence of this option will be mandatory when using experimental
options (see oracle/graal#7370).

Furthermore, as described in oracle/graal#7487 Mandrel and GraalVM will also adopt glob patterns in the future (planned for the next release) and gradually phase out the ability to use exclude patterns.

The aim of this change is to inform Quarkus users that they are
responsible for keeping such configuration files up to date and to make
clear that they need to start using the
`-H::±UnlockExperimentalVMOptions` option.
@fniephaus fniephaus linked a pull request Nov 1, 2023 that will close this issue
@zakkak
Copy link
Collaborator

zakkak commented Nov 1, 2023

@sberyozkin can you please have a look at ^^?

@sberyozkin this is a kind reminder.

holly-cummins pushed a commit to holly-cummins/quarkus that referenced this issue Feb 8, 2024
Starting with Mandrel 23.1 and GraalVM for JDK 21 the use of
`-H:ResourceConfigurationFiles` and `-H:ReflectionConfigurationFiles` is
marked as experimental and requires the use of
`-H::±UnlockExperimentalVMOptions` to avoid warnings (see
oracle/graal#7190), while in the future (planned for the next release)
the presence of this option will be mandatory when using experimental
options (see oracle/graal#7370).

Furthermore, as described in oracle/graal#7487 Mandrel and GraalVM will also adopt glob patterns in the future (planned for the next release) and gradually phase out the ability to use exclude patterns.

The aim of this change is to inform Quarkus users that they are
responsible for keeping such configuration files up to date and to make
clear that they need to start using the
`-H::±UnlockExperimentalVMOptions` option.
@zakkak
Copy link
Collaborator

zakkak commented Mar 8, 2024

@sberyozkin can you please have a look at ^^?

@sberyozkin this is a kind reminder.

@sberyozkin it looks like this fell through the cracks, can you please have a look?

@sberyozkin
Copy link

Apologies for totally missing this issue. Let me CC @fjuma and @darranl - can you please check #7370 (comment), is it possible to add .getInstance() to SHA512_256MessageDigest.java ? Thanks

@darranl
Copy link

darranl commented Mar 8, 2024

@sberyozkin Can I please double check what is being asked for here?

I am just looking at JCA documentation to clarify the requirements and I am currently in this section:

https://docs.oracle.com/en/java/javase/11/security/howtoimplaprovider.html#GUID-CB446B7A-CEA2-4F4A-A4AF-4D492CB58733

Is this about adding a .getInstance() to the SHA512_256MessageDigest.java or is this about adding the newInstance(Object) method where we register the Provider.Service ? I assume this also applies to all Security Provider registration and not just this example?

@sberyozkin
Copy link

@darranl Thanks for checking it. Now that you have asked, I have to admit, I'm not sure.

I've reread the comment from @zakkak where he indeed mentions org.wildfly.security.password.WildFlyElytronPasswordProvider, and I believe @cstancu assumed the reason Quarkus had to add it to native image with an -H:AdditionalSecurityProviders option to workaround the fact that the Elytron SHA512_256MessageDigest misses getInstance().

@zakkak has also mentioned other Quarkus extensions which use -H:AdditionalSecurityProviders, quarkus-security, quarkus-security-jdbc, quarkus-infinispan-client, quarkus-kafka-client.

quarkus-security-jdbc also adds org.wildfly.security.password.WildFlyElytronPasswordProvider with -H:AdditionalSecurityProviders but quarkus-infinispan-client and quarkus-kafka-client add com.sun.security.sasl.Provider (quarkus-kafka-client adds a couple of other providers).

I've tested that quarkus-security-jdbc integration tests are passing in native mode without adding org.wildfly.security.password.WildFlyElytronPasswordProvider with -H:AdditionalSecurityProviders.

However with quarkus-infinispan-client, avoiding adding com.sun.security.sasl.Provider with -H:AdditionalSecurityProviders leads to the following error:

2024-03-10 21:16:46,416 WARN  [io.net.cha.ChannelInitializer] (HotRod-client-async-pool-3-3) Failed to initialize a channel. Closing: [id: 0x5477bf1b]: java.lang.IllegalStateException: SaslClientFactory implementation not found
	at org.infinispan.client.hotrod.impl.transport.netty.ChannelInitializer.g

Does it mean -H:AdditionalSecurityProviders is really needed ?

@cstancu What are you thoughts about it ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: In Progress
Status: In progress
Development

No branches or pull requests

6 participants