Silent Replacement of Trusted macOS App Executables

I agree that Apple was wrong in not considering this worth fixing. I hope this post gets enough attention to make them reconsider.

It's surprising that you can remove and create, but not modify, files in /Applications. It seems like an obvious bug considering that "remove + create" on regular files is roughly equivalent to "modify"? That should definitely be fixed.

Thinking about this problem more generally, though, I'm not sure you can close off this vulnerability for good without significant architectural changes to macOS which would also have the side effect of making software development a little more annoying. Although /Applications is where most apps are installed in practice, macOS allows you to install apps to any location. Any (unsandboxed) app can "install" (i.e. copy files for) a new unsigned, unsandboxed app to any location, and then open it without user confirmation, by design.

Revalidate an application’s code signature before launch when its bundle has changed. The brief validation process macOS displays after the modification suggests it has already detected the change.

Probably won't work because there's nothing preventing two apps installed in different locations from sharing the same name (bundle ID is supposed to be unique but users wouldn't notice if that changes). A malicious app could delete the original app and then open and immediately close the modified app stored in some other location so that it's indexed by Spotlight and ready for the user to re-open it later, thinking it's the original. A perceptive user may wonder why Signal was abruptly removed from their dock, but that could easily be written off as a bug.

Improve authorization prompts by displaying the code-signing identity (developer or Team ID) of the executable requesting access, not just the application’s name and icon.

I think that making code-signing identity information accessible to the end user would be a welcome improvement, but it'd probably get tiring after a while to scan over the same developer information again every time an app needs permission to do anything. The right time to show this is when an app is first opened, IMO. Integrate it into the Gatekeeper prompt that currently only displays 1 bit of information about the app (whether it's notarized or not).

When I was writing code that was restricted by trusted bit, I had my program copy the binary and run the copy instead. Seemed to fix the limits I was facing.