On Fri, 6 Dec 2024 19:56:07 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 refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. The pull request contains two new > commits since the last revision: > > - 8315487: Security Providers Filter > > Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> > Co-authored-by: Martin Balao <mba...@redhat.com> > - 8345139: Fix bugs and inconsistencies in the Provider services map > > Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> > Co-authored-by: Martin Balao <mba...@redhat.com> A FIPS-certified cryptographic module needs to do more than blocking algorithms or key strengths when configured in FIPS mode. E.g. it needs to run self-integrity tests on startup, that you typically don't want if FIPS mode is off. Thus, FIPS-certified security providers will probably have their own configuration for FIPS, their own policy —which is under the certification scope—, and will have their own mechanism to offer the right algorithms and parameters. The Filter will be out of scope when they go through the certification process. That is the current situation and we are not proposing any change there. The goal of the Filter is to block cryptographic services from non-FIPS-certified providers. This is a help for Java applications to avoid mistakenly/inadvertently using non-FIPS cryptography. E.g. you plug-in an OpenSSL provider configured in FIPS mode and SUN for X.509 certificates. With the Filter, you can make sure that `MessageDigest` from SUN is not available. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2548616098
