Yes, however I did not find anything related to Installer.app. I considered adding Installer.app to the listing, but no longer have access to the offending machine and I'm since unable to reproduce on the latest Ventura version. I'll see if I can find out which OS version was originally used.

Feel free to file a bug against the docs. Done via FB11983426 (<-- hmm... this auto-linking is broken, shall I file another?). As a slight aside, I reported an unrelated bug with Notes (FB11709965) on Ventura beta that still seems to be present, so my confidence in this system has yet to be won over. :)

Most organisations that use a custom CA install its root certificate via MDM. Indeed, that’s the only option on iOS and its child platforms [1]. If you want to use a custom CA, that’s the path you should be on. iOS does offer installing custom device profiles for this exact purpose (which MDMs can automate). It's an unfortunate side-effect of the mobile landscape. I do admit that these profiles (whether provided via MDM or manually) do place iOS better than Android in this area, but this conversation is about the MacOS desktop. Mobile platforms are not the target for this app due specifically to their strict sandboxing. In regards to MDM solutions, these just don't scale well for non-enterprise deployments. The simple act of proposing an MDM solution for an SSL problem is quite presumptuous. In my case, SSL is needed for websocket communication from browser to a natively running application. This application is distributed to millions of PCs worldwide and macOS is the only platform that places a blocking UI prompt in this fashion. To that point, macOS is also the only one to warn of other important security, privacy and non-sandboxed actions, which is fantastic, but these are all non-blocking. For example, the same application must make changes in other areas of the OS (background tasks, browser helpers) and the OS -- quite politely -- asks if this is OK, something no other OSs keep track of, which is a step in the right direction. To that point, SSL is so important and prolific in the industry it should come as no surprise that there are perfectly valid use-cases for limited scope certificates, perhaps this is the biggest oversight of prescriptive solutions, that once you mandate SSL everywhere, private-network communication is left in the dust unless exceptions to the assumption of "HTTPS = public websites" are made. Using a CA-issued certificate is just the first step. I'll have to strongly disagree. Using CA-issued certificates inside distributed applications is a substantial security risk. Furthemore, CA-issued certificates can't easily be issued for localhost or LAN communication anyway. If you're aware of a non-enterprise way to do this, I'm all ears. :) In an attempt to stay on topic, I'll file a bug against the documentation. Disclaimer, the OP -- Vzor -- and I have been discussing this problem offline. He'll be sharing a GitHub actions CI issue that suffers a similar problem.

Why are you changing trust settings? Adding an SSL certificate to the machine for secure communication. Running a process as "root" requires authentication by the OS, making it redundant. But to the OP's point, this prompt seems to mismatch the documentation, which clearly indicates that no further action is required, quoting it again: "[...] When making changes to system-wide trust settings, the user is prompted with an alert panel asking for an administrator’s name and password unless the calling process is running as root, in which case no further authentication is needed. [...] The documentation warns that this can and will block, quoting: "[...] Note that this function might block while waiting for user input. [...] ... so I find the OP's question to be valid. It sounds like you’re under the misapprehension that “running … as root” is the same as “Administrator privileges”. I'm having a hard time understanding where this assumption was drawn from, the OP clearly says "root". XCode calls this root: Product > Scheme > Edit Scheme > Debug process as root Changing trust settings requires user interaction regardless of the BSD level privileges of your process. I'm having a hard time understanding if this is suggesting that the documentation is outdated, or if the Scheme is not doing as described? In general this is not a happy path to be going down. Reading between the lines, I think there's some assumption that modifying the SSL trust settings is bad practice. This is both presumptuous as well as untrusting. In my use-case, myself and my company have been vetted by Apple through Dun & Bradstreet. Each application distributed undergoes notarization and stapling by Apple, however there are use-cases where this User Interaction blocks similarly as documented (but even when running as root). I think the OP's question as well as the quoted documentation have merit and as a result promote happiness. :) More strictly speaking, self-signed certificates are arguably more secure than CA-issued certificates because the chain of trust does not imply monolith issuers. Furthemore, when done properly, private key leakage will only impact a single machine. I understand there are some cases where self-signed certificates are lazily installed (e.g. SuperFish / Lenovo) and those concerns have merit as well, but then this turns more into a conversation about the dangers in self-signed certificate (e.g. wildcard and/or non-owned FQDN and/or non-localhost) scope, rather than about security in general. Furthemore, in the event of the SuperFish / Lenovo disaster, it was the worldwide private-key sharing across all devices that made the scope so terrifying. Perhaps this behavior should be fingerprinted and added as a blocker to the notarization process, since I've seen other apps (e.g. Cricut) continue this practice years after that fiasco. :( Oddly, Apple does have a plist flag for suppressing this prompt, but this technique seems like using a sledgehammer to crack a nut, and due to how contradictory this appears from a security perspective, can be presumed will be removed in a future OS update.

Sorry to be a necromancer here, but @eskimo, has this behavior changed since Monterey? Reference: https://github.com/java-native-access/jna/issues/1423#issuecomment-1382220523

I have a somewhat similar issue. Since Big Sur, one of my machines cannot read files from the Desktop (AdoptOpenJDK 11). Granting java full disk permissions didn't fix it. My app is distributed as an .app. The launcher uses /usr/libexec/java_home to find a suitable Java vendor, which -- in this case -- returns /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home. What's most troubling is the "Application Foo is trying to Access the Desktop" popup doesn't show on the offending machine.

I've found a project which uses JNA to accomplish this in Java: https://github.com/dyorgio/macos-tray-icon-fixer. Note, future Java versions will have a new property. More about that here: JDK-8252015

have you seen the https://github.com/apple/openjdk/ repo? Apple has open sourced JNF as part of that just recently. They just built it with the openjdk project. That's OK, I guess, but it would be nice to have it bundled with XCode for ARM64 so developers can use it, or at least provide it as a standalone project to fetch at build time, since it's a one-liner: https://github.com/apple/openjdk/blob/xcodejdk14-release/build.sh#L32

Since Apple is unable to provide a technique to detect this, we've begun the process to update the JDK to internally (properly) use the NSImage:isTemplate flag. More details about this available here: https://github.com/AdoptOpenJDK/openjdk-support/issues/146#issuecomment-697723671 I'm marking this as the accepted answer. The patch will not be available in the JDK for some time yet as it takes a while to get the code approved through the proper channels.

I still haven't found an API to query this, so I'm proposing a patch to OpenJDK to fix it -- at least for Java, see JDK-8252015

This leads me to believe that Safari may actually be the ONLY browser to allow the 825 day requirement in the edge-case that it was installed by an administrator. This assumption was false, at least for Edge and Chrome, quoting Microsoft's tech community: @stesch79 These changes apply to certificates that are rooted to a public CA trust anchor. Certificates that are rooted to a private PKI CA (“locally-trusted anchor”) are not limited this way. I'm still waiting to hear back from Firefox.

Despite the response from Apple stating the following: "This change will not affect [...] administrator-added Root CAs." This change seems to have affected the cabforum, specifically SC31, which seems to make no mention of this administrator-added exception.... https://github.com/cabforum/documents/pull/195 Granted, SC31 pertains to issuers, not the applications honoring these rules, but according to Mozilla, they're already prepared to honor this quoting: a) If that ballot passes, then the requirement will automatically apply to Mozilla’s Root Store Policy by reference. With SC31 merged combined with an email I've received from DigiCert, I can only assume this ballot has passed, quoting: [...] all Certificate Authorities are required to stop issuing 2-year TLS/SSL certificates. The new industry-allowed maximum validity will be 1 year (398 days).  This leads me to believe that Safari may actually be the ONLY browser to allow the 825 day requirement in the edge-case that it was installed by an administrator. Although this makes the question no-longer Apple-specific, any insight or information is appreciated as any organization attempting to keep ubiquity to the users needs to make an informed decision -- especially considering that the change was in large part spearheaded by Apple.

I began writing a crude luminosity test based on the top-left pixel of the screen. Here's a the test, written in Java: public static boolean isDarkTaskbar() { &#9;&#9;try { &#9;&#9;&#9;&#9;Rectangle rectangle = new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()); &#9;&#9;&#9;&#9;Rectangle topCorner = new Rectangle(rectangle.x, rectangle.y, 1, 1); &#9;&#9;&#9;&#9;BufferedImage pixel = new Robot().createScreenCapture(topCorner); &#9;&#9;&#9;&#9;Color color = new Color(pixel.getRGB(0, 0)); &#9;&#9;&#9;&#9;return (color.getRed() * 0.299) + (color.getGreen() * 0.587) + (color.getBlue() * 0.114) <= 174; &#9;&#9;} catch(AWTException e) { &#9;&#9;&#9;&#9;log.warn("Unable to detect dark taskbar: {}", e.getMessage()); &#9;&#9;} &#9;&#9;return false; } This has some unfortunate side effects: It triggers the "Screen recording" security prompt, something I'd rather not do. It doesn't work 100% of the time. Some wallpapers such as "Catalina Silhouette" switch the taskbar to "Light Mode" for seemingly no good reason. Preview: i.imgur.com/eiWa864.png I assume Apple offers an API, it's just not well known yet. Where would I be able to find API information about this feature?

Thanks. I'll mark this as resolved for now and plan accordingly. Meanwhile if the feature makes it into a release (either through release notes or silently) having a unit test to prove the app will survive this update would be the most favorable outcome.

Hi,@meaton Per recommendation, I'm pinging you 2 months later hoping to find out the path to verifying the new -- shortened -- CA cert behavior on Safari.I've read the Release Notes for the Technology Preview but I still cannot seem to find mention of this change.I'd also rest assured knowing that this stament is guaranteed to be correct:-- "This shorten validity period only affects certificates created with a root that already exists in the trust store of the device."Our certificate is generated just-in-time using a CA&lt;---&gt;intermediate&lt;---&gt;SSL to be compliant with Firefox, then installed using security add command line interface. It sholud not qualify as "Already existing in the trust store of the device", but having a way to confirm this prior to the change would vastly improve the confidence of our prodcut for the future of Safari.Best regards,