[derefr]

Further, there is a CRL/OCSP cache — which means that if you're running a program frequently, Apple are not receiving a fine-grained log of your executions, just a coarse-grained log of the checks from the cache's TTL timeouts.

Also, a CRL/OCSP check isn't a gating check — i.e. it doesn't "fail safe" by disallowing execution if the check doesn't go through. (If it did, you wouldn't be able to run anything without an internet connection!) Instead, these checks can pass, fail, or error out; and erroring out is the same as passing. (Or rather, technically, erroring out falls back to the last cached verification state, even if it's expired; but if there is no previous verification state — e.g. if it's your first time running third-party app and you're doing so offline — then the fallback-to-the-fallback is allowing the app to run.)

Remember that CRLs/OCSP function as blacklists, not whitelists — they don't ask the question "is this certificate still valid?", but rather "has anyone specifically invalidated this certificate?" It is by default assumed that no, nobody has invalidated the certificate.

[heavyset_go]

> i.e. it doesn't "fail safe" by disallowing execution if the check doesn't go through. (If it did, you wouldn't be able to run anything without an internet connection!) Instead, these checks can pass, fail, or error out; and erroring out is the same as passing. (Or rather, technically, erroring out falls back to the last cached verification state, even if it's expired; but if there is no previous verification state — e.g. if it's your first time running third-party app and you're doing so offline — then the fallback-to-the-fallback is allowing the app to run.)

https://www.sentinelone.com/blog/what-happened-to-my-mac-app...

> Last week, just after we covered the release of Big Sur, many macOS users around the world experienced something unprecedented on the platform: a widespread outage of an obscure Apple service caused users worldwide to be unable to launch 3rd party applications.

[dialup_sounds]

Scroll down a little further on your link for confirmation of what the parent said:

> As was well-documented over the weekend, trustd employs a “fail-soft” call to Apple’s OCSP service: If the service is unavailable or the device itself is offline, trustd (to put it simply) goes ahead and “trusts” the app.

Even at the time people quickly figured out you could just disconnect from the internet as a workaround until the issue was fixed.

[sooheon]

Why is it that non app store apps refuse to run until I explicitly allow it in settings then?

[derefr]

Presumably because you have Gatekeeper set to "Allow applications from: App Store" rather than "Allow applications from: App Store & Known Developers".

This is just Gatekeeper asking you which code-signing CA certs you want to mark as trusted in its kernel-internal trust store (which is, FYI, a separate thing from the OS trust store): do you want just the App Store CA to be trusted? Or do you also want the Apple Developer Program's "Self-Published App" Notarization CA to be trusted?

Choosing which code-signing CA-certs to trust will, obviously, determine which code-signed binaries pass certificate validation. Just like choosing which TLS CAs to trust, determines which websites pass certificate validation.

Code-signing certificate validation doesn't happen online, though. Just like TLS certificate validation doesn't happen online. It's just a check that the cert you have has a signing path back to some CA cert in the local trust store.

[sooheon]

I have the latter Gatekeeper option, and I often have to click "Allow anyway". I don't see how being forced to click an extra button in a preference pane makes things more secure.

[derefr]

If you're getting the Gatekeeper dialog with the "Open anyway" button (the "Apple cannot verify that this app is free of malware" alert), then this is a specific case: you're on Catalina or later, and the app you're using has a valid code-signature but hasn't been notarized.

This warning only triggers for legacy releases of apps, published before notarization existed. Since Catalina, notarization has been part-and-parcel of the same flow that gets the self-published app bundle code-signed by Apple. AFAIK it is no longer possible to create a code-signed but non-notarized app bundle through XCode. (It's probably still possible by invoking `codesign` directly, and third-party build systems might still be doing that... but they really shouldn't be! They've had years to change at this point! Catalina was 2019!)

Thus, the "Open anyway" option in this dialog is likely transitional. This warning is, for now, intended to not overly frighten regular users, while also indicating to developers (esp. the developer of the app) that they should really get out a new, notarized release of their app, because maybe, one day, this non-notarized release of the app won't be considered acceptable by Gatekeeper any more.

I'm guessing that once a sufficient percentage of apps have been notarized, such that macOS instrumentation reports this dialog being rarely triggered, the "Open anyway" option will be removed, and the dialog will merge back into the non-code-signed-app version of the dialog that only has "Cancel" and "Move to Trash" options. Though maybe in this instance, the dialog would have the additional text "Please contact the app developer for a newer release of this app" (because, unlike with an invalid digital signature, macOS wouldn't assume the app is infected with malware per se, but rather just that it might do low-level things [like calling private OS frameworks] that Apple doesn't permit notarized apps to do.)

[GeekyBear]

Both Windows and MacOS require that developers digitally sign their software, if you want users to be able to run that software without jumping through additional hoops on their computer.

You can't distribute software through the Apple or Microsoft app stores without the software being signed.

You can sign and distribute software yourself without having anything to do with the app stores of either platform, although getting a signing certificate that Windows will accept is more expensive for the little guys than getting a signing certificate that Macs will accept.

On Windows, allowing users to run your software without jumping through additional hoops requires you to purchase an Extended Validation Code Signing Certificate from a third party. Prices vary, but it's going to be at least several hundred dollars a year.

https://www.reddit.com/r/electronjs/comments/17sizjf/a_guide...

Apple includes a software signing certificate with a basic developer account, which runs $100 a year.

You can ignore that on either platform, but users will have to take additional actions before they can run your unsigned software.

[spacedcowboy]

I have literally never experienced that and I use homebrew apps a lot

Perhaps you turned some "make things ultra-secure" setting on at some point ?

[bdash]

I suspect they're referring to changes to Gatekeeper in recent macOS versions: https://arstechnica.com/gadgets/2024/08/macos-15-sequoia-mak...

It used to be that you could run any third-party application you downloaded. And then for a while you'd have to right-click and select Open the first time you ran an application you'd downloaded, and then click through a confirmation prompt. And macOS 15, you have to attempt to open the application, be told it is unsafe, and then manually approve it via system settings.

[m4rtink]

Looks like a clear trend then.

[eviks]

That's just your extremely limited experience (2 stores): homebrew runs a special command clearing up a bit so you don't get that notification, which does exist if yout download apps directly

[phs318u]

This reply is very informative and should be much more visible given the extent of general ignorance about the "zomg it phones home" feature.

[GeekyBear]

There was a since fixed bug in a prior MacOS release that did fail to launch an app on the local machine if the CRL data was unreachable.