RFR: 8315487: Security Providers Filter [v9]

[Xue-Lei Andrew Fan]

On Mon, 21 Oct 2024 18:30:50 GMT, Martin Balao <mbalao at 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 eight commits:
> 
>  - 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 c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab.
>      src/java.base/share/classes/sun/security/jca/GetInstance.java
>        Adjust GetInstance::getCipherServices return type to Iterator<Service>.
>      src/java.base/share/classes/sun/security/jca/ProvidersFilter.java
>        Rename CipherServiceList to CipherServiceIterator in comment.
>  - Minor changes to align with the JEP.
>    
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - ProvidersFilterTest extended to cover all JCA service types.
>    
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at openjdk.org>
>  - Support for cipher transformations and JEP alignment
>    of the java.security documentation.
>    
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Copyright dates update.
>  - More clear text in invalid pattern exception.
>  - 8315487: Security Providers Filter
>    
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>

This update is really too big to review in details.  There are 5512 lines changed, 4881 ins and 631 del per the webrev data.  If I read the description and code right, there are three types of update in this PR:
1. bug fixes of the current OpenJDK code.
2. A provider filter API design to check if a service is allowed in a certain circumstances.
3. A provider filter implementation in java.security to perform the service checking.

I may use multiple PR for this purpose:
1. Multiple pull requests to fix bugs.
2. Design a public API to check if a service is allowed and update the JDK code accordingly.  A public API design will allow third party to define their own service restriction policy, without depends on the java.security.
3. Implement the provider filter with java security property.

The 1st and 2nd one should be small enough, straightforward to implementation and easy to integrate.  The 3rd one could big, but it will be an implementation details, and it can even be optional.  As would make it easy to review and backport.

Just for your reference.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2455562203