[8u] RFR 8242565: Policy initialization issues when the denyAfter constraint is enabled

[Lutker, Dan]

Hi Alexey,
We opened a JBS for the issue with the providers, JDK-8266929 [1], since it is a common scenario for our customers to load the provider in code and not through the config. I think your original backport is fine if the new issue is going to be fixed, I'll be sending an RFR for it shortly.

Thanks,
Dan

[1] https://bugs.openjdk.java.net/browse/JDK-8266929

On 5/12/21, 8:54 AM, "Alexey Bakhtin" <alexey at azul.com> wrote:

    Hello Dan,

    Thank you for your comments
    What do you think if just use available system providers while creating oidTable:
    http://cr.openjdk.java.net/~abakhtin/8266279_draft/webrev.v0/
    (patch applied on top of [2])

    It gives 133 entries in the oidTable if Bouncy Castle preconfigured in the java.security file and 59 entries if it is loaded from application ( Security Manager is enabled)

    Regards
    Alexey

    > On 7 May 2021, at 00:27, Lutker, Dan <lutkerd at amazon.com> wrote:
    > 
    > Hi Alexey,
    > 
    > We were also looking at this issue and think there may still cases where users get NoSuchAlgorithmException. If the algorithm is from another provider not on the jarVerificationProviders list, then the AlgorithmId oidTable will be initialized without that the complete list of algorithms and never updated. This is also an issue on OpenJDK11 and potentially in tip as well, we haven't verified that yet.
    > 
    > Currently on 8u292 we see 27 entries in the oidTable when BouncyCastle is getting loaded, while when no signed jars are loaded we see 59 entries. If we clear out the table after jar verification is completed and BouncyCastle provider is then added we see 133 entries.
    > 
    > We are trying to find a clean way to clear out the table when Security providers change and are open to ideas from the community.
    > 
    > I think your change should go in as well as the backport for JDK-8156584 [1] posted here [2]
    > 
    > Thanks,
    > Dan
    > 
    > [1] https://bugs.openjdk.java.net/browse/JDK-8156584
    > [2] http://cr.openjdk.java.net/~alexsch/sercher/8156584.8u/webrev.00/
    > 
    > On 5/6/21, 1:48 AM, "jdk8u-dev on behalf of Alexey Bakhtin" <jdk8u-dev-retn at openjdk.java.net on behalf of alexey at azul.com> wrote:
    > 
    >    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
    > 
    > 
    > 
    >    Hi,
    > 
    >    Please review the backport of JDK-8242565 to 8u:
    > 
    >    Bug: https://bugs.openjdk.java.net/browse/JDK-8242565
    >    Original change: https://hg.openjdk.java.net/jdk/jdk/rev/8d34198a0e26
    >    8u webrev: http://cr.openjdk.java.net/~abakhtin/8242565/webrev.v0/
    > 
    >    Original patch applies almost clean except for copyright years and SunJCE provider class name in the Providers.java class. All related jtreg tests in the :jdk_security group passed.
    > 
    >    Please note: this patch also fixes issues [1] [2] [3] in the latest 8u292 release because of adds “SunJCE” provider to the list of thread local jar verification providers. Test from the bug report with BC provider passed.
    > 
    >    [1] https://bugs.openjdk.java.net/browse/JDK-8266279
    >    [2] https://bugs.openjdk.java.net/browse/JDK-8266261
    >    [3] https://bugs.openjdk.java.net/browse/JDK-8266290
    > 
    > 
    >    Regards
    >    Alexey
    >