On Sun, 15 Dec 2024 07:18:02 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
> > It's only the combination of a Provider that overrides > > getService/getServices + does not call putService/put + overrides > > newInstance without calling its parent + uses a non-Java SE service type > > that would be unfiltered. > > FYI. I found [a > case](https://www.bouncycastle.org/download/bouncy-castle-java-fips/) that: > > 1. Override getService/getServices, has its own logic to use put properties. > 2. Use extended Provider.Service, but not Provider.Service directly. > 3. call put() and get() internally. But because of `#1` and `#2`, the > provider filter theory may not work, please verify. > 4. overrides newInstance without calling its parent. > 5. uses non-Java SE service types > > This is a popular provider (IIRC 17% marketing share per a report). I think > you might have evaluated it and confirmed that the theory works. Otherwise, > please make sure the compatibility issues is limited and the theory works for > it. Thank you! BC has some sort of cache in `BouncyCastleProvider::serviceMap` but calls `putService` (`BouncyCastleProvider.super.putService(service)`) anyways. public static void main(String[] args) throws Throwable { System.setProperty("jdk.security.providers.filter", "!BC.Cipher.AES/CBC/PKCS5Padding; *"); Provider bc = new BouncyCastleProvider(); System.out.println("Name BC: " + bc); Cipher c1 = null; Cipher c2 = null; try { c1 = Cipher.getInstance("AES/CBC/PKCS5Padding", bc); } catch (NoSuchAlgorithmException e) {} try { c2 = Cipher.getInstance("AES/GCM/NoPadding", bc); } catch (NoSuchAlgorithmException e) {} System.out.println("Cipher AES/CBC/PKCS5Padding (BC): " + c1); System.out.println("Cipher AES/GCM/NoPadding (BC): " + c2); } Name BC: BC version 1.79 Cipher AES/CBC/PKCS5Padding (BC): null Cipher AES/GCM/NoPadding (BC): Cipher.AES/GCM/NoPadding, mode: not initialized, algorithm from: BC ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2548981071
