On Thu, 5 Dec 2024 20:45: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 15 commits: > > - Merge openjdk/master into JDK-8315487 > > Fix conflict caused by de3a218a2801b8a4b414fce9337bd151ded9b7f8, due to > a change in the imports context: > src/java.base/share/classes/jdk/internal/access/SharedSecrets.java > - Fix typo > - Merge openjdk/master into JDK-8315487 > > Deal with 940aa7c4cf1bf770690660c8bb21fb3ddc5186e4 integration: > src/java.base/share/classes/java/security/Provider.java > Fix minor conflicts due to context changes. > src/java.base/share/classes/sun/security/jca/ProvidersFilter.java > Use getOverridableProperty instead of privilegedGetOverridable. > - Undo SunNativeProvider provider changes. They will be implemented in > JDK-8345221. > - Merge 'openjdk/master' into JDK-8315487. > - Perform some minor adjustments > > Add LF character at the end of the ServicesConsistency.java and > java.security files. > > Change jtreg bug ID of ServicesConsistency.java to refer to the new one > created by @martinuy: https://bugs.openjdk.org/browse/JDK-8345139. > > Remove Security Manager related comments, as #22418 is in the pipeline, > also see https://bugs.openjdk.org/browse/JDK-8338411. > - Merge 'openjdk/master' into JDK-8315487 > > Below is a conflicts resolution summary. > > Trivial conflict, caused by 2a1ae0ff89a8ac364206b09059d9dc884adcc5ac: > src/java.base/share/classes/java/security/Provider.java > > Drop unnecessary change after db85090553ab14a84c3ed0a2604dd56c5b6e6982: > src/java.base/share/lib/security/default.policy > > Trivial conflict, caused by 0329855831102a48abf14b5befc933f84dfd3460: > test/jdk/tools/launcher/Settings.java > - Remove -Xdebug from commented-out debug command > > This is unnecessary, see 842d6329cf5a3da8df7eddb195b5fcb7baadbdc3. > - Merge 'openjdk/master' into JDK-8315487 > > Resolved conflicts: > src/java.base/share/classes/java/security/Provider.java > src/java.base/share/classes/javax/crypto/Cipher.java > src/java.base/share/classes/sun/security/jca/ProviderList.java > src/java.base/share/conf/security/java.security > > src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java > > Additional fixes: > src/java.base/share/classes/java/security/Security.java > Import sun.security.jca.ProvidersFilter, since the sun.security.jca.* > import was removed in c6f1d5f374bfa9bd... Last force-push was just to base this pull request on #22613, we can see that the codebase before and after the force-push is exactly the same. f3c5e58029cfe3c36ae920edd196893d244d65c4 and 96709e3fbab456fe1b9767e1961176c0e5e32aa7 refer to the same code, [`git diff f3c5e58 96709e3`](https://github.com/openjdk/jdk/compare/f3c5e58029cfe3c36ae920edd196893d244d65c4..96709e3fbab456fe1b9767e1961176c0e5e32aa7) show no changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2524047081
