On Mon, 2 Dec 2024 21:05:53 GMT, Martin Balao <mba...@openjdk.org> wrote:
> getService/getServices API overrides are supported since the initial PR.
> Please check the JEP and implementation, and let us know if you see any flaw.
I guess you refer to the following section in the JEP. Otherwise, please let
me know the correct JEP section. That's the key point that I would like to
address. Without this concern, the issue could be simpler.
> For third-party providers that override java.security.Provider::getService or
> java.security.Provider::getServices to return services that have not been
> evaluated against the filter or are evaluated and not allowed, a second
> filter enforcement occurs in java.security.Provider.Service::newInstance.
For unknown providers that override the Provider::getService and
Provider::getServices methods, I'm not sure how the filter could get them
evaluated with the 1st filter. For the 2nd filter, please refer to the next
comment.
> In rare situations, a third-party provider can override
> java.security.Provider.Service::newInstance and return an unvetted service
> implementation (SPI).
Well, there is a concern of mine. I don't agree the case is rare. What if you
are making a wrong judgment about it popularity here? Did you have data to
support your point. How could you get the case covered even for the rare case
even if it is really rare?
With a new public API, for example ServicePermission.permit(Provider service).
I don't think you need the 2nd filter for
java.security.Provider.Service::newInstance any longer. All you need is to
updates the following 2 or 3 methods, plus a few bug fixes out of the scope of
this JEP:
provider.putService() (optional, for performance improvement only)
provider.getService()
provider.getServices()
And document the public API and have third party provider follow the spec and
use the API. Without a public API, there is not much we can do for unknown
third party providers. Even with the public API, third party's provider may
not follow it. But they now have a way to follow the spec, and application
also have solutions for those that do not follow the new spec yet.
Let's see the scenarios:
1. Define a public service API: ServicePermission.permit(Provider service),
and a method to get the service so that it can be set with a security property
(see #4).
2. Update provider.getService() and provider.getServices(), and submit to JDK
repository.
3. Application implement the ServicePermission service, ThisIsMyFilterProvider
(JDK could have a java.security property filter implementation in a new JEP,
but it is not necessarily have any value in default JDK).
4. Update java.security update, java.security.filter="ThisIsMyFilterProvider",
default value is empty.
5. Enjoy it.
> are we going to have different syntax depending on the 3rd-party filter
> implementor?
No, there is not syntax to maintain at all, unless you want to define a
specific ServicePermission provider. You can do that with your proposal about
the syntax for default JDK, and enforce it for your own proposal. You don't
want to worry about those applications that don't use your proposal:
java.security.filter=my-filter-Provider-with-my-loved-syntax
> The problems of filtering by algorithm parameters and by use (e.g. MD5 for
> UUID) are not easy to solve, will require further discussion and are
> orthogonal to a pluggable filter.
No, it is not easy for your proposal. But it is not that hard with a
customizable ServicePermission.permit(Provider service) APIs. I think smart
developers could have it addressed for specific environment, so that we don't
need to worry about them for a general approach for all environment.
It looks like more simple, powerful and having actual requirements, is it?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2539993473
