On Wed, 12 Feb 2025 21:52:57 GMT, Martin Balao <mba...@openjdk.org> wrote:
>> In addition to the goals, scope, motivation, specification and requirement >> notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we >> would like to describe the most relevant decisions taken during the >> implementation of this enhancement. These notes are organized by feature, >> may encompass more than one file or code segment, and are aimed to provide a >> high-level view of this PR. >> >> ## ProvidersFilter >> >> ### Filter construction (parser) >> >> The providers filter is constructed from a string value, taken from either a >> system or a security property with name "jdk.security.providers.filter". >> This process occurs at sun.security.jca.ProvidersFilter class —simply >> referred as ProvidersFilter onward— static initialization. Thus, changes to >> the filter's overridable property are not effective afterwards and no >> assumptions should be made regarding when this class gets initialized. >> >> The filter's string value is processed with a custom parser of order 'n', >> being 'n' the number of characters. The parser, represented by the >> ProvidersFilter.Parser class, can be characterized as a Deterministic Finite >> Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting >> point to get characters from the filter's string value and generate state >> transitions in the parser's internal state-machine. See >> ProvidersFilter.Parser::nextState for more details about the parser's states >> and both valid and invalid transitions. The ParsingState enum defines valid >> parser states and Transition the reasons to move between states. If a filter >> string cannot be parsed, a ProvidersFilter.ParserException exception is >> thrown, and turned into an unchecked IllegalArgumentException in the >> ProvidersFilter.Filter constructor. >> >> While we analyzed —and even tried, at early stages of the development— the >> use of regular expressions for filter parsing, we discarded the approach in >> order to get maximum performance, support a more advanced syntax and have >> flexibility for further extensions in the future. >> >> ### Filter (structure and behavior) >> >> A filter is represented by the ProvidersFilter.Filter class. It consists of >> an ordered list of rules, returned by the parser, that represents filter >> patterns from left to right (see the filter syntax for reference). At the >> end of this list, a match-all and deny rule is added for default behavior. >> When a service is evaluated against the filter, each filter rule is checked >> in the ProvidersFilter.Filter::apply method. The rule makes an all... > > Martin Balao has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains four commits: > > - Merge JDK-8345139 into JDK-8315487 > > This way, we are syncing with the dependency of this PR. > > Manually apply src/java.base/share/classes/java/security/Provider.java > changes, as a lot of context changed after JDK-8345139 updates. > - Copyright date update. > > Co-authored-by: Martin Balao Alonso <mba...@redhat.com> > Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> > - Add a debug message to inform the Filter property value read. > > See more in > https://mail.openjdk.org/pipermail/security-dev/2024-October/041800.html > > Co-authored-by: Martin Balao Alonso <mba...@redhat.com> > Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> > - 8315487: Security Providers Filter > > Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> > Co-authored-by: Martin Balao <mba...@redhat.com> > I have been starting to review the code, and am initially reviewing this with > respect to how it complies with the current API specification. > > All of the JCA API `getInstance` methods that do not have a provider argument > have text like the following: > > > This method traverses the list of registered security Providers, starting > > with the most preferred Provider. A new `<service>` object encapsulating > > the `<service>Spi` implementation from the first provider that supports the > > specified algorithm is returned. > > However, the providers filter can be configured to prevent that object from > being returned. I think this is an important difference in behavior that it > should be documented as an implementation note. My initial suggestion is > something like the following: > > "The JDK Reference Implementation additionally uses the > `jdk.security.providers.filter` system and security property to determine > which services are enabled. A provider whose algorithm is not enabled by the > filter will not be selected." > > I think similar text will need to be added in the `Provider` API, but I need > to review those changes more closely first. @martinuy Any comments on the above? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2660279702
