Improve `-H:+TraceSecurityServices` to list Security Services/Providers removed by recent change that filters out "unused" security providers

[zakkak]

Feature request

Improve -H:+TraceSecurityServices to list Security Services/Providers removed by 10cc640.

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

At the moment (3061677), -H:+TraceSecurityServices reports the reachable providers but provides no info regarding those that are being filtered out making hard to understand what providers one might need to explicitly add in order to make an application work (see quarkusio/quarkus#17774 (comment) for instance).

Describe the solution you'd like.
I would like to see a mark/annotation next to providers that end up being filtered out, or a separate list with the filtered out providers (probably easier to implement).

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

Express whether you'd like to help contributing this feature
If needed, I am willing to help contributing this feature.

cc @gradinac

[gradinac]

Hey @zakkak!
In cases where the security services feature has been disabled, all providers are by default filtered out. However, I agree with you, it would be useful to see exactly which providers got removed.
I propose that we print a list of removed providers' class names after analysis, once the provider caches have the final value. This will be very simple to implement, and provide the whole list in one place. What do you think? cc @cstancu

[zakkak]

Hi Aleksandar

In cases where the security services feature has been disabled, all providers are by default filtered out.

In quarkusio/quarkus#17774 (comment) the security services feature is enabled, however as we are using some services that are not specified in the JCA it would be useful to be able to list the filtered out services/providers with -H:+TraceSecurityServices and then figure out which of them we need to explicitly include.
If there is any other way to achieve the same result please let me know.

However, I agree with you, it would be useful to see exactly which providers got removed.
I propose that we print a list of removed providers' class names after analysis, once the provider caches have the final value. This will be very simple to implement, and provide the whole list in one place. What do you think?

It sounds good to me.
Thanks

[gradinac]

Ah, my bad! Hmm, we do not really filter service types in the SecurityServicesFeature - we only filter the security providers that got included in the image but weren't observed as used by the feature. The security services themselves are handled in a different way: at first, none are included and we incrementally include more as specific methods become reachable. If a service gets included, all providers that offer such a service are included as well.

One note: even if the service type isn't specified by the JCA, you can still have it automatically registered, provided that the service is in a specific format (see https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.test/src/com/oracle/svm/test/SecurityServiceTest.java#L121 and https://github.com/oracle/graal/blob/master/substratevm/JCASecurityServices.md#custom-service-types)

[zakkak]

(see https://github.com/oracle/graal/blob/master/substratevm/src/com.oracle.svm.test/src/com/oracle/svm/test/SecurityServiceTest.java#L121 and https://github.com/oracle/graal/blob/master/substratevm/JCASecurityServices.md#custom-service-types)

Thanks for the extra info @gradinac.

I guess you meant

graal/substratevm/src/com.oracle.svm.test/src/com/oracle/svm/test/SecurityServiceTest.java

Lines 135 to 139 in cbc5a97

	private abstract static class JCACompliantNoOpService {
	public static JCACompliantNoOpService getInstance(String algorithm) throws NoSuchAlgorithmException {
	return (JCACompliantNoOpService) GetInstance.getInstance("JCACompliantNoOpService", null, algorithm).impl;
	}
	}

instead of

graal/substratevm/src/com.oracle.svm.test/src/com/oracle/svm/test/SecurityServiceTest.java

Lines 121 to 129 in cbc5a97

	private static final class NoOpProviderTwo extends Provider {
	static final long serialVersionUID = 1234L;
	@SuppressWarnings("deprecation")
	protected NoOpProviderTwo() {
	super("no-op-provider-two", 1.0, "No-op provider two used in " + SecurityServiceTest.class.getName());
	putService(new Service(this, "JCACompliantNoOpService", "no-op-algo-two", JcaCompliantNoOpServiceImpl.class.getName(), null, null));
	}
	}

, right?

[gradinac]

Ah yes, both the provider and the service are important in this case.
On the provider side, the provider adds a service with the type "JCACompliantNoOpService", which is the simple name of the service class. On the service side, we have a getInstance method that returns the appropriate service. Both of these assumptions are needed to provide automatic service registration.