Invalidated Signing Certificate for Releases

[MisutaaAsriel]

I tried running the program from the latest release on macOS 26.0 (25A354) and was immediately greeted by an alert by macOS informing me that the application "contains malware", was blocked from running, and has been removed from my system.

Not sure if this is a false positive from some sort of API usage, or another issue, but uhhhhh… yeah.

[trey-a-12]

That's a new one... it actually said CONTAINS malware, and not "cannot verify that it does or doesn't contain malware?" Mind you, I do not have a paid Apple Developer account, so you SHOULD see the "'Launchback.app' Not Opened" message with "Apple could not verify 'LaunchBack.app' is free of malware that may harm your Mac or compromise your privacy."

This is distinct from the "'LaunchBack.app' is damaged and can't be opened. You should move it to the Trash." message, as well as the "Malware Blocked and Moved to Trash" message it SOUNDS like you're describing here. If either of those is the case, there might've been some new change in how Gatekeeper handles things like this from macOS Tahoe Beta 9 to the full release version 1.

If you could, perhaps double-check and grab a screenshot of the exact Gatekeeper message. I actually helped someone with what sounded like this exact issue on the macOS Tahoe Betas not long ago. Last I checked, running LaunchBack always had a "Cannot verify that it doesn't have malware" and would let me force open it from Settings → Privacy and Security. I HAVE seen the "contains malware" error before, and the supposed cause is distinct.

Check out that discussion here: kushalpandya/Petrichor#62 (comment)

And yes, that should be a false positive. Historically, LaunchBack has only had the "could not verify" message, and you are more than welcome to run the app through Apparency or Virustotal to double-check for yourself.

[C4J]

Sounds very much like the message you get when an app has not been digitally signed by Apple. I think there is a command line you can run to flag the file as “not” being downloaded from the internet which fixes this. A quick google came back with this: ``` xattr -d com.apple.quarantine ```

[trey-a-12]

↑ My edit to your prior response was simply cleaning up the original "on ## at ###, user said..." extra that came with responding via email.

I also did run release 1.1.1 LaunchBack through Virustotal once again and it came back clean, so there's no files that've suddenly been tampered with or anything of the sort. (I am still pretty new to the development side of things here, so something could very well happen and I be unaware of it!)

See the VirusTotal summary here: https://www.virustotal.com/gui/file/0271b0919fc1e9bf23ea9f7be989a3f62e14b4cc12d59ad3be22113f76276b40

[trey-a-12]

Okay, can confirm the app still just shows up as "Rejected" by Gatekeeper and Apparency as it did on previous betas, but it did NOT previously give the "Malware Blocked and Moved to Trash" message. I will see what I can do!

[MisutaaAsriel]

@trey-a-12

That's a new one... it actually said CONTAINS malware, and not "cannot verify that it does or doesn't contain malware?" Mind you, I do not have a paid Apple Developer account, so you SHOULD see the "'Launchback.app' Not Opened" message with "Apple could not verify 'LaunchBack.app' is free of malware that may harm your Mac or compromise your privacy."

Yes. It explicitly says contains malware. This is contrary to other applications which are not signed with a paid Apple Developer ID, where it says it cannot verify the author.

To note: I have GateKeeper on its lowest setting short of allowing everything (App Store & Known Developers): I can run software with prompt that has not been signed by Apple, permitting the scheme used to sign an application and its contents match. Unsigned software in some cases can also be ran (but much less often as is the case with Apple Silicon). Apps signed by "known" developers can run without prompt.

This is distinct from the "'LaunchBack.app' is damaged and can't be opened. You should move it to the Trash." message, as well as the "Malware Blocked and Moved to Trash" message it SOUNDS like you're describing here.

It isn't even the "You should move it to the Trash." dialog. it is the (either rarer or replacement) "Malware blocked and moved to Trash." dialog — Tahoe doesn't even give the option. Just immediately kills the app and trashes it ASAP without user input.

This wasn't the "is dangerous" dialog. This wasn't the "could not verify" dialog. This wasn't the "is an app downloaded from the internet" dialog.

If you could, perhaps double-check and grab a screenshot of the exact Gatekeeper message.

I actually did but there's a weird issue impacting my GitHub account where I cannot upload images in issues. Only in Discussions. Go figure. ‪¯\_(・–・)_/¯‬

The error message in question is:

"Launchback.app" was not opened because it contains malware. This action did not harm your Mac.

With either "Malware Blocked" (ran from DMG or Read-only storage), or "Malware Blocked and moved to Trash" (Writeable directory) as the header.

I actually helped someone with what sounded like this exact issue on the macOS Tahoe Betas not long ago. Last I checked, running LaunchBack always had a "Cannot verify that it doesn't have malware" and would let me force open it from Settings → Privacy and Security. I HAVE seen the "contains malware" error before, and the supposed cause is distinct.

And yes, that should be a false positive. Historically, LaunchBack has only had the "could not verify" message, and you are more than welcome to run the app through Apparency or Virustotal to double-check for yourself.

Noted.

I also did run release 1.1.1 LaunchBack through Virustotal once again and it came back clean, so there's no files that've suddenly been tampered with or anything of the sort. (I am still pretty new to the development side of things here, so something could very well happen and I be unaware of it!)

See the VirusTotal summary here: https://www.virustotal.com/gui/file/0271b0919fc1e9bf23ea9f7be989a3f62e14b4cc12d59ad3be22113f76276b40

https://www.virustotal.com/gui/file/5bb4f0142d44a5669ddcddb9c67807cb140ba63660dc4e0a1a51d6935cfb5363/relations

I threw the whole bundle up and the closest thing to a detection was with PkgInfo, but swapping/removing that does nothing.

Interesting, XProCheck reports no detections. The only thing in the log is an error about a Gatekeeper rejection:

Terminating process due to Gatekeeper rejection: 26831, <private>

---

@C4J

Sounds very much like the message you get when an app has not been digitally signed by Apple. I think there is a command line you can run to flag the file as “not” being downloaded from the internet which fixes this. A quick google came back with this:

xattr -d com.apple.quarantine

This is not accurate at all. I have that bound to a Quick Action in Shortcuts. I already tried this anyways.

The error you get when an app isn't digitally signed or is incorrectly signed is "The application has exited" or "The application can't be opened", sometimes with an error code of -1 or -7 IIRC.

This is straight up the OS, despite all attempts, rejecting the application in full.

[MisutaaAsriel]

Even more interesting… When I run codesign -s - --deep --force LaunchBack.app to sign it with a local ad-hoc signature valid for my personal Mac, trying to launch the app gives the "could not verify is free of malware" error instead.

This is making me think that something about the application might be broken?

[trey-a-12]

OKAY. That is a lot to digest there and quite the oddity, especially seeing as again, prior macOS Tahoe Betas at least gave the "could not verify" dialog. Upon downloading the app from the 1.1.0 installer .dmg, I too got the "Contains Malware" message, and I mean... I of all people should know it doesn't; I'm not gonna steal data from myself or something 😭

First off, THANK. YOU for taking the time to do such a deep inspection. I can personally promise you right now that if by some chance some malware or something has wormed its way into this project, it has somehow done so without my knowledge whatsoever, and I have no indicator that this would be the case. It's detailed responses like yours that help get to the potential root of the issue.

Secondly, and potentially even more interestingly, is how Gatekeeper appears to treat Ad-Hoc signatures (as they are referred to in the Apparency docs). An app like Darktable can have a plethora of Ad-hoc signatures and only give the "could not verify" message. With that, even having a bunch of red markers that would normally cause caution, that one little distinction makes Gatekeeper unable to evaluate the app and thus doesn't classify it as a "threat."

Yes, that app is called "darkertable" and it is the vanilla app otherwise; I renamed it so I could hopefully remove it without triggering Pearcleaner and accidentally catching files from my ACTUAL darktable installation lol

I would very much like to learn what distinguishes this Ad-hoc signature from the Gatekeeper-rejecting signature of an actual (albeit free) Apple Developer Account, as well as how I can change that in the actual Xcode project file. Perhaps finding this may be the key to resolving the installation issue.

[MisutaaAsriel]

Deleting my previous comment as I learned it was effectively nothing.

Tip

So, I've been doing some forensics, diving into the internals of Apple codesigning, learning the meaning of hashes and entitlements. I even delved into analyzing your certificate itself!

I have since ran some tests, and resigned your release bundle with:

codesign -s "Apple Development: [ redacted ]" --deep --force --preserve-metadata --generate-entitlement-der /private/tmp/LaunchBack_DER.app

I have then compared the two bundles side by side…

Note

I have truncated the output to omit irrelevant data such as information relating to my signature, and any details unlikely to have changed under different signature contexts.

Original Signature

$ codesign -dv --verbose=5 /Volumes/LaunchBack\ 1.0\ \(Initial\ Release\)\!/LaunchBack.app

CodeDirectory v=20500 size=766 flags=0x10000(runtime) hashes=13+7 location=embedded

Executable Segment base=0
Executable Segment limit=114688
Executable Segment flags=0x1
Page size=16384
    -7=662d7e12de97b1d9bf3a9e4574652bc4d1927f4b989a6b7a1d1380e542f2b4f9
    -6=0000000000000000000000000000000000000000000000000000000000000000
    -5=2198747bee96847909af4417876f446cea964f842bd1fbbdea39f53ff947e0d8
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=cc980e7c6b05f057edb0854e8a2b52effa6897833ce38a3e97b13c7d26263ba8
    -2=329ad27897f8da9bdb0845faafbf93f9aa3499bba6baf8961140475e7407a3b1

Info.plist entries=22

Runtime Version=15.5.0
Sealed Resources version=2 rules=13 files=2
Internal requirements count=1 size=196

Resigned Application

$ codesign -dv --verbose=5 /tmp/LaunchBack_DER.app

CodeDirectory v=20500 size=766 flags=0x10000(runtime) hashes=13+7 location=embedded

Executable Segment base=0
Executable Segment limit=114688
Executable Segment flags=0x1
Page size=16384
    -7=662d7e12de97b1d9bf3a9e4574652bc4d1927f4b989a6b7a1d1380e542f2b4f9
    -6=0000000000000000000000000000000000000000000000000000000000000000
    -5=2198747bee96847909af4417876f446cea964f842bd1fbbdea39f53ff947e0d8
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=cc980e7c6b05f057edb0854e8a2b52effa6897833ce38a3e97b13c7d26263ba8
    -2=329ad27897f8da9bdb0845faafbf93f9aa3499bba6baf8961140475e7407a3b1

Info.plist entries=22

Runtime Version=15.5.0
Sealed Resources version=2 rules=13 files=2
Internal requirements count=1 size=196

…they are identical. Okay, so the contents are valid. What about the signature itself?

codesign --verify --deep --strict -v –verbose=4 /Volumes/LaunchBack\ 1.0\ \(Initial\ Release\)\!/LaunchBack.app

/Volumes/LaunchBack 1.0 (Initial Release)!/LaunchBack.app: valid on disk
/Volumes/LaunchBack 1.0 (Initial Release)!/LaunchBack.app: satisfies its Designated Requirement

…huh.

I have no idea what GateKeeper is balking at at this point.

[MisutaaAsriel]

@trey-a-12

$ spctl -a /Volumes/LaunchBack\ 1.0\ \(Initial\ Release\)\!/LaunchBack.app 

/Volumes/LaunchBack 1.0 (Initial Release)!/LaunchBack.app: CSSMERR_TP_CERT_REVOKED

…CERT_REVOKED

Apple has, uh, revoked that certificate. You might be able to update it in Xcode settings.

Tip

I too got the "Contains Malware" message, and I mean... I of all people should know it doesn't; I'm not gonna steal data from myself or something 😭

This would explain this behavior. Because its a certificate revocation, it will throw this error on all machines, including your own.

It is… well we cannot rule out the possibility that someone at Apple has taken notice of this project in an unfortunate way...

[MisutaaAsriel]

@trey-a-12 out of curiosity, can you ad-hoc sign the .app bundle and post a DMG of it here? Specifically with:

codesign -s - --deep --force --options=runtime --preserve-metadata --generate-entitlement-der /path/to/LaunchBack.app

I want to see how an adhoc-signed bundle from your machine will behave on mine.

[trey-a-12]

I'll see what I can do (a bit later, currently in college intermission and just wanted at acknowledge the message). Again, just to clarify, you're asking me to re-compile the LaunchBack application, run the command you showed to give it an ad-hoc signature, and put it in a DMG to send to you?

[MisutaaAsriel]

I'll see what I can do (a bit later, currently in college intermission and just wanted at acknowledge the message). Again, just to clarify, you're asking me to re-compile the LaunchBack application, run the command you showed to give it an ad-hoc signature, and put it in a DMG to send to you?

Not even that far.

1. Mount the existing DMG containing the bundle
2. Copy the file somewhere (e.g. /tmp)
3. Remove all attributes with xattr -c -r /path/to/LaunchBack.app
4. Resign existing bundle ad-hoc using codesign -s - --deep --force --options=runtime --preserve-metadata=entitlements --generate-entitlement-der /path/to/LaunchBack.app
5. Repackage bundle in new .DMG or more simply a .ZIP
6. Attach packaged bundle to a response on this issue via drag-and-drop.

I have a theory about code signing and Macs:

• Ad-hoc signatures are designed for un-notarized apps distributed over the internet.
  • This comes with additional considerations, as frameworks and helper applications which exist as part of a bundle may have signatures which are virtually incompatible with ad-hoc signing. Launching ad-hoc signed applications with bundled code that is signed by a different entity may result in the application refusing to launch on Apple Silicon.
    • This can be bypassed using the --deep and --force options in codesign to resign all code within a particular bundle, at the expense of reducing trust in bundled code.
      • There are pitfalls to using --deep signing as well.
• Apple Developer ID certificates are designed for and limited to your own devices and a small pool of testers.
• Developer ID Application signatures are designed for notarized apps distributed over the internet.
• Apple Distribution certificates are designed for apps distributed via TestFlight and the App Store.

If I am correct: This would mean that, either heuristically once LaunchBack was installed on the nth device which pushed it over the limit, or manually through review by an Apple employee, your certificate was deemed to be compromised or abused, and invalidated, as it was a Developer ID certificate being used in a way that requires either Ad-hoc (less secure) or Developer ID Application (more secure, $99/year) certification.

The motivation, if true, to invalidating your certificate, would essentially be: Apple has not verified your code is safe, but it is using a certificate validated by Apple, bypassing warnings provided by macOS. This breaks the chain of trust, and is considered insecure. This form of signature is (if true) only to be used for limited developer testing, and not designed for en-masse, nor organizational distribution.