RFR: regex changes -- sun.security.util.Debug issue

[Wang Weijun]

Security-dev,

If we can live with "engine=keystore" happily, why not just make the whole string lowercase and search for "permission=java.io.filepermission"? I don't think there are permission types or URL names that are only different in cases. Although file names are case-sensitive in Unix, I doubt if any customer will complain if we show him info on /ETC even if what he sets is "codebase=/etc".

We can add new methods like hasCodebase(URL) and hasPermission(Class<? extends Permission>) to hide the search details inside Debug.

Thanks
Max

> On May 10, 2016, at 1:36 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> While testing for the attached regex changes, a fatal vm init error was triggered for test
> case with -Djava.security.debug=xyz turned on, as showed in following stacktrace.
> 
> It appears sun.security.util.Debug is being initialized even before the lambda is ready
> for use, and unfortunately it uses j.u.regex (for its args parsing), which is being migrated
> to use lambda function in the proposed regex change.
> 
> Since Debug is the only class now triggers j.u.regex -> lambda during initialization, it
> is suggested to update/rewrite the related method in Debug to NOT use j.u.regex to
> solve/workaround this specific initialization issue.
> 
> The webrev below has been updated to include such a change.
> 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ 
> 
> The sun.security.util.Debug related change is at
> 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/src/java.base/share/classes/sun/security/util/Debug.java.sdiff.html
> 
> Can security-dev guys help take a look if this is an acceptable/reasonable approach.
> 
> Thanks,
> Sherman
> 
> -----------------------------------------------------------------------------
>  Caused by: java.lang.ExceptionInInitializerError
> 
>  
> 	at jdk.internal.loader.BootLoader.loadClassOrNull(java.base/BootLoader.java:110)
> 	at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:497)
> 	at java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:492)
> ...
> 	at java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandleNatives.java:240)
> 	at java.util.regex.Pattern.<clinit>(java.base/Pattern.java:5682)
> 	at sun.security.util.Debug.marshal(java.base/Debug.java:247)
> 	at sun.security.util.Debug.<clinit>(java.base/Debug.java:59)
> 	at java.security.ProtectionDomain.<clinit>(java.base/ProtectionDomain.java:142)
> 	at jdk.internal.misc.InnocuousThread.<clinit>(java.base/InnocuousThread.java:129)
> 	at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:48)
> 	at jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:45)
> 	at java.security.AccessController.doPrivileged(java.base/Native Method)
> 	at jdk.internal.ref.CleanerFactory$1.newThread(java.base/CleanerFactory.java:45)
> 	at jdk.internal.ref.CleanerImpl.start(java.base/CleanerImpl.java:116)
> 	at java.lang.ref.Cleaner.create(java.base/Cleaner.java:203)
> 	at jdk.internal.ref.CleanerFactory.<clinit>(java.base/CleanerFactory.java:42)
> 	at sun.nio.fs.NativeBuffer.<init>(java.base/NativeBuffer.java:60)
> 	at sun.nio.fs.NativeBuffers.allocNativeBuffer(java.base/NativeBuffers.java:49)
> 	at sun.nio.fs.UnixNativeDispatcher.copyToNativeBuffer(java.base/UnixNativeDispatcher.java:44)
> 	at sun.nio.fs.UnixNativeDispatcher.stat(java.base/UnixNativeDispatcher.java:306)
> 	at sun.nio.fs.UnixFileSystemProvider.isRegularFile(java.base/UnixFileSystemProvider.java:514)
> 	at java.nio.file.Files.isRegularFile(java.base/Files.java:2244)
> 	at java.lang.module.ModuleFinder.ofSystem(java.base/ModuleFinder.java:165)
> 	at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:105)
> 	at java.lang.System.initPhase2(java.base/System.java:1924)
> 
> ---------------------------------------------------------------------------------
> 
> 
> On 3/18/16 1:05 PM, Xueming Shen wrote:
>> Hi, 
>> 
>> There are couple regex related changes waiting for review. I have pull them 
>> together here (with the notes) to make it easy to review. 
>> 
>> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ 
>> 
>> (1) Exponential backtracking 
>> 
>> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking
>> 
>> https://bugs.openjdk.java.net/browse/JDK-6328855 
>> https://bugs.openjdk.java.net/browse/JDK-6192895 
>> https://bugs.openjdk.java.net/browse/JDK-6345469 
>> https://bugs.openjdk.java.net/browse/JDK-6988218 
>> https://bugs.openjdk.java.net/browse/JDK-6693451 
>> https://bugs.openjdk.java.net/browse/JDK-7006761 
>> https://bugs.openjdk.java.net/browse/JDK-8140212 
>> 
>> (2) Anonymous class to lambda function cleanup 
>> 
>> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8151481 
>> https://bugs.openjdk.java.net/browse/JDK-6609854 
>> 
>> (3) Canonical Equivalents 
>> 
>> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ
>> 
>> https://bugs.openjdk.java.net/browse/JDK-4916384 
>> https://bugs.openjdk.java.net/browse/JDK-4867170 
>> https://bugs.openjdk.java.net/browse/JDK-6995635 
>> https://bugs.openjdk.java.net/browse/JDK-6728861 
>> https://bugs.openjdk.java.net/browse/JDK-6736245 
>> https://bugs.openjdk.java.net/browse/JDK-7080302 
>> 
>> Thanks 
>> Sherman 
>