> 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 allow or deny
> decision if the ser...
Martin Balao has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains seven commits:
- Merge openjdk:master into martinuy:JDK-8315487
Conflicts
=========
src/java.base/share/classes/javax/crypto/Cipher.java
Caused by JDK-8359388 (ec7c6be6a9e84c8cd2077fea07930592ddd13669).
Resolved by adding JDK-8359388 new checks on our codebase (we need
the checks separated from splitting).
- Add missing @implNote to Security::getAlgorithms
Create a jdk.security.providers.filter @implNote for
java.security.Security::getAlgorithms, explaining that this method is
NOT affected by the filter.
NOTE: we could have modified the method to stop using the Provider
Hashtable and start to be affected by the filter, but we think this
is unnecessary, given the method doesn't look to be widely used.
Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com>
Co-authored-by: Martin Balao <mba...@redhat.com>
- Address review comment 2
Create a jdk.security.providers.filter @implNote for:
• java.security.Security::getProviders(String)
• java.security.Security::getProviders(java.util.Map<String,String>)
Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com>
Co-authored-by: Martin Balao <mba...@redhat.com>
- Address review comment 1
Add a java.security.Provider.Service link in the 'services' mention of
the jdk.security.providers.filter @implNote.
NOTE: instead of the first mention in each API, we preferred to add it
everywhere in order to simplify the criteria.
Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com>
Co-authored-by: Martin Balao <mba...@redhat.com>
- Fix bad conflict resolution
Due to our changes, AlgorithmDecomposer::getTransformationTokens returns
an array which does not always have three elements, so the code from
JDK-8358159 (3ff83ec49e561c44dd99508364b8ba068274b63a) needs adjustment.
- Merge openjdk:master into martinuy:JDK-8315487
Conflicts
=========
src/java.base/share/classes/javax/crypto/Cipher.java
Caused by JDK-8358159 (3ff83ec49e561c44dd99508364b8ba068274b63a), which
did something similar to what we had done for this proposal. Resolved by
keeping JDK-8358159 changes.
src/java.base/share/conf/security/java.security
Caused by JDK-8298420 (bb2c80c0e9923385e0b6243c0ebff9afef208470), which
added content at the end. Trivially resolved.
- 8315487: Security Providers Filter
Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com>
Co-authored-by: Martin Balao <mba...@redhat.com>
-------------
Changes: https://git.openjdk.org/jdk/pull/15539/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=26
Stats: 3829 lines in 43 files changed: 3429 ins; 93 del; 307 mod
Patch: https://git.openjdk.org/jdk/pull/15539.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539
PR: https://git.openjdk.org/jdk/pull/15539
