RFR: JDK-8318854: [macos14] Running any AWT app prints Secure coding warning

Harshitha Onkar honkar at openjdk.org
Thu Nov 9 22:30:32 UTC 2023


On Wed, 8 Nov 2023 19:49:48 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
> 
> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
> 
> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
> 
> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
> 
> The fix for JDK-8318854 involves:
> 
> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
> 
> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
> 
> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
> 
> 
> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.

@prrace There are other references to shared delegate within ApplicationDelegate.m in JNI calls such as here [#L820](https://github.com/openjdk/jdk/blob/a95062b39a431b4937ab6e9e73de4d2b8ea1ac49/src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m#L820). I haven't added null checks here because the references are within JNI calls and when this code is reached a shared delegate is positively installed because of the following condition -

`if ([NSApp isKindOfClass:[NSApplicationAWT class]]) shouldInstall = YES;`

Do you anticipate any circumstance that can still result in a null shared delegate in this case and recommend that null checks be added to these locations (within JNI calls) too?

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

PR Comment: https://git.openjdk.org/jdk/pull/16569#issuecomment-1804779156


More information about the client-libs-dev mailing list