On Mon, 2 Dec 2024 00:37:45 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
Martin Balao has updated the pull request incrementally with one additional
commit since the last revision:
Undo SunNativeProvider provider changes. They will be implemented in
JDK-8345221.
Thank you for the response, but I'm not sure I get all of your points.
On Sat, Nov 30, 2024 at 11:04 PM Martin Balao Alonso <
***@***.***> wrote:
Hi @XueleiFan <https://github.com/XueleiFan> ,
Looks to me that this is a significant change compared to what we proposed
and would require a heavier specification. I am not seeing a compelling
argument at the moment.
Sorry if it will be a significant change of the proposal. But it is the
case for review, right?
My first concern is not so much the work that would be required now but the
burden of maintaining these APIs in the future if it turns out to be a low
demand for them, a marginal benefit or both.
Yes, I am on your side on this point. That's also the reason why I am here.
While the decision of introducing a built-in filter requires a new
system/security property that will need to be maintained, it's not
incompatible with a more powerful, extensible and pluggable API in the
future. We will not be with our hands tied in that sense. If we introduce a
pluggable API, that is a stronger commitment.
I see it differently. This proposal impacts the compatibility for future
introduction of pluggable APIs. Any new APIs for similar purposes have to
consider the impact of this proposal, implementation and deployment. If
we have a goal, it would be nice to do it right at the beginning,
especially if the extensible and pluggable API solution is more simple and
more powerful.
The idea of a pluggable core security component looks to me like a door
open for different filtering criteria and potential risk of confusion. I
see the filter more like a simple firewall with a clear and single
specification, that does not leave any room for intepretation or
differences in implementation. This core component builds on top of a well
defined and unambiguous concept: services are defined as a combination of a
provider, service type and algorithm (*).
I'm not sure how it is possible, or how it is only possible with your
current proposal. If I get it right, the filter will not appear in the
default Java security, and it allows people to edit it. When you allow
people to edit it, it is already a public API. I did not see the point
about "does not leave any room for interpretation or differences in
implementation". The security property is editable. If it is the goal of
yours, does the following an alternative proposal looks right, which also
update java.security file:
java.s...
Hi @XueleiFan,
Thanks for elaborating more on your proposal. Just to clarify, we appreciate
and encourage all sort of ideas in the interest of a better solution, even if
they imply significant change and require a heavier specification. By pointing
that out in my previous comment, I had the intention to start a technical
discussion and see if we find a compelling argument to take that path. Had it
been something minor, we could have incorporated it to the proposal without
further discussion.
With that said, and having read your last comments, I still have concerns about
the proposed change that will try to explain.
It's true that the built-in filter is a public API that defines a syntax that
we will need to maintain and potentially extend in a backward-compatible way. A
pluggable filter does not replace this API-requirement but adds on top. It's
not the property value itself but the interface and hook points that we will
need to document and support for (now) filter developers. Pluggable filters
will access in principle the same information as the built-in filter (provider
name, service type and algorithm) and in the same places (hook points). The
idea of hook points and access decisions made by an external component reminds
me in a way of the pluggable aspect of the Security Manager architecture. A
pluggable filter can walk a call stack to learn a little more about the context
but this does not say much about the use for a service SPI instance —e.g. a
service will probably be filtered after ::putService—. From this perspective,
what is their additional value? I agree that it opens a door.
I struggle to see is how it can be more simple, powerful and what are the
actual requirements that compensate the burden of supporting this open door
from now on. We all probably agree in that once a door is open and there is a
community of external producers and consumers, it's difficult to go back. If it
is worth having it, I'm all in. If there is something that a pluggable filter
can theoretically do that the built-in can not, I'd like to know what it is and
enhance it. Having a whole ecosystem of filters with different capabilities may
not contribute to a single and robust solution, and may be evidence of a poor
built-in filter design and implementation.
The risk of inconsistency is inheritant to additional complexity and
interaction between more components, including external ones. For example, a
criteria will need to be defined and specified to address the problem of how a
pluggable filter interacts with a built-in one. To name a few possibilities,
the interface can try to prevent both from being set, but also an error can be
thrown if both filters are defined —e.g. one statically and the other with
::setProperty—, one filter can invalidate the other if both are defined, one
filter can apply on top of the other with a pre-established order, filters can
cooperate conservatively so services need to pass both, etc. With the current
proposal, there is a single firewall-like rule applied that can be seen in the
configuration itself. With pluggable filters, the behavior will depend on a
specific implementation and (potentially) and external configuration. E.g. are
we going to have different syntax depending on the 3rd-party filter im
plementor? Do we need to analyze and compare each 3rd-party filter option to
understand how one filter can apply some criteria and some other a different
one?
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. The built-in filter can be extended if we come to the
conclusion that we hit the limits of a pattern-matching language and there are
actions that we cannot express. With a better understanding of the problem, we
may want to narrow the door we open (e.g. @franferrax suggested
pattern-matching in the context of a built-in filter rule). The idea that
filter by use is doable with a pluggable filter is not taking into account that
there won't be hook points for that unless we add them. Adding them will make
us incur in critical-path costs —same as if they were part of the built-in
filter—. But then, if that's what we want, why not adding it to the built-in
filter?
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.
Regards,
Martin.-
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2512839417
