Interestingly enough, it seems to be possible to notarize someone else's app, so perhaps it might be a worthwhile use of my developer ID to provide this service to people I trust but don't want to shell out money…
Interestingly enough, it seems to be possible to notarize someone else's app, so perhaps it might be a worthwhile use of my developer ID to provide this service to people I trust but don't want to shell out money…
If you check the code signature of a Developer ID signed app, you'll see the developer's name and Team ID from the signing certificate. This guarantees the app was signed by that developer, as long as the developer has kept their private key secure.
First you sign the app, then you upload it to App Store Connect for notarization. It's an "open secret" that Apple has allowed any Apple Developer Program member to submit any app for notarization, even if the app wasn't signed by them. Apple really wanted all apps notarized. Whether Apple will crack down on this practice in the future, who knows.
The notarization "ticket" is signed by Apple, not by the developer. I've heard of developers who discovered that someone else notarized their app. But nobody else can put their "name" on the app except the owner of the Developer ID certificate. If you Developer ID sign someone else's unsigned binary, you're presenting it to the world as your own. But that's not the case with notarization. Nobody except Apple knows who submitted an app for notarization.
Note that I'm not necessarily arguing that training people to click "yes, yes, continue..." is a good idea. Digital security is my day job and I totally see why Apple wants digital signatures for software. However, the message is opaque about what is really going on and just tries to scare people into buying "trusted" software rather than using free software: that developer fee doesn't pay itself.
> perhaps it might be a worthwhile use of my developer ID to provide this service to people I trust
I was thinking the same, we could pool the money, but figured Apple almost certainly prohibits that "for security".
How does a certificate let "macOS verify the app is free from malware"?
(1) and probably a manual review if the App under analysis was found to call into any but a whitelist of “safe” system APIs.
Without the code signing, you can’t be sure that the app you’re seeing is the same one Apple‘s servers saw. It might be a copy of the app that has had a virus injected into it (which has happened quite a few times recently in pirated macOS software.)
How so? Even if they don’t catch malware during notarization, Apple also reacts pretty quickly to invalidate a developer’s code-signing certificate if they use it to sign apps that contain malware (as soon as Apple is made aware of that malware-app, for which they maintain relationships with both major antivirus vendors and independent security researchers.) Your computer then receives the new Apple code-signing CRL in a silent update, and won’t run the app (or any app by that developer) any more. Even if you’re offline at the moment, and so can’t contact the notarization servers to find out the app has been denotarized, as long as you’ve been online at any point since the CRL was updated, you’ll be protected. (And where does malware come from? These days, 99% of the time, the network. So if you stay offline, you’re extremely unlikely to run into novel malware anyway. And if you’re online to receive the malware, you’re almost certainly going to have received the CRL update first.)
And sure, there’s a small period of vulnerability before Apple is made aware of new malware; but most malware infections are not from zero-day malware, but rather from malware that’s been going around for a long time already. (And I believe they also push ‘disinfectant’ logic in those same silent updates that update the code-signing CRLs, same as Microsoft does with Windows Defender. So the usual “join a botnet, hijack your browser” kind of malware can simply be reverted.)
Plus, there’s the whole System Integrity Protection thing, meaning that macOS malware can’t really do anything to permanently subvert the Gatekeeper infrastructure, since it lives in the “untouchable” root partition. (It could do something clever with a system extension, but as of Catalina you have to explicitly activate those in the Security preference pane; and probably, as of Big Sur, you won’t be able to activate them at all.) So it’s only people with SIP off (i.e. system extension developers; Hackintosh owners) who would even feel any sort of “deep impact” from any of this malware. Meaning that macOS malware authors basically don’t bother to try to “deeply embed” their malware into the OS, given that the process will only actually work on a tiny fraction of systems.
Anyway, all that being said: it’s not like Apple said they can’t “guarantee” that the app is free from malware, implying that signed+notarized apps would be guaranteed free from malware. They just say they can’t “validate” that the app is free from malware, implying that the apps that don’t show this warning have been “validated” by Apple—i.e. audited, to the best of their own abilities and current knowledge. Signed off on, like a home inspector signs off on a house. And that’s exactly the case. Apple has “validated” those apps. That doesn’t translate to some technical guarantee of safety, like running the app in a VM would give. It only translates to “you can trust this app to the degree that you trust Apple’s validation process.”
It’s exactly the same claim that Chrome and Edge are implicitly making when you download software through them on Windows: the software gets “validated” by Google/Microsoft as not containing malware to the best of their knowledge. It’s an antivirus signature scan, combined with a trustworthiness heuristic based on whether the developer was willing to sign their software. The only difference is that, in Apple’s case, the “antivirus scan” part happens on a server somewhere, asynchronously, rather than on the client. But it’s the same level of effective security.
Granted, you could quibble with the details (does pointing out that you can't verify that it's free from malware imply that you could verify that it's free from malware if there were a certificate?). But calling the message "intentionally" (!) misleading?
> misleading
I... don't think misleading means what you think it means. Misleading statements (pretty much by definition) don't imply falsehoods. They "merely" "suggest" falsehoods to those who don't already know better. If they intentionally "implied" falsehoods then they would be called "lies", not "misleading".
2) Apple documentation [1] says (my highlight) "The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly."
Is the claim that Apple is not actually scanning notarised software for malicious content?
3) Random unsigned apps presumably have not been scanned, and might contain malware. I still fail to see the problem, or what's misleading (and "intentionally" so!).
[1] https://developer.apple.com/documentation/xcode/notarizing_m...
No, the claim is that just because Apple _hasn't_ scanned some particular piece of software for malicious content, that doesn't necessarily mean it _does_ contain such.
> 3) Random unsigned apps presumably have not been scanned, and might contain malware.
Exactly: they _might._ But popping up big hysterical warnings about it strongly implies, particularly to less technically well-versed users, that they_ do._
> what's misleading (and "intentionally" so!).
Strongly implying something that is obviously not true, that's what's misleading. In fact, AFAICT, that is the very definition thereof. And unless they're putting stuff they didn't intend to say into the dialogs they pop up, then yes, it is obviously intentional. Is the claim that their dialog text is un-intentional?
> I still fail to see the problem
Two hoary old quotes (or is the first a proverb? Maybe literally, from Proverbs) come to mind:
1: Nobody is as blind as he who does not want to see.
2: It's hard to make a man see something he doesn't want to see, particularly if his salary depends on him not seeing it.
(Personally, I do data warehousing / ETL programming for a living; currently at the Finnish Social Security Agency.)
https://developer.apple.com/documentation/xcode/notarizing_m...
I don't think so, the concern would be revokation, if someone does a bad thing and Apple pulls the cert your entire friends would lose access.
I wonder if it would make sense to do ring-based instead (r0 being most trusted)