Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Gates to Hell: Apple’s Notarizing

cdfinder.de

Post reply on HN
Print view View original

201–210 of 214 posts

Re: The Gates to Hell: Apple’s Notarizing

#201

Post by FredPret »

maxwell wrote: post #193
pwinnski wrote: post #138

Earlier quoted context omitted.

BMW, Facebook, KFC, and Yahoo! are branded phones I remember off the top of my head, but even Microsoft gave up on the phone business because they couldn't gain traction. "iOS seems poised for a slow ride into irrelevance" is quite a thing to say the same week Apple announced all-time record Q2 revenue on the back of their iPhone business. It's up there with "this is the year of Linux on the desktop" as a perennial s…

Developers are also users, usually some of the more advanced users, important early adopters and power users. Remember non-developers saying they would never get Facebook, or an iPhone, or bitcoin, or Snapchat, or TikTok... and then Road to Damascusing into evangelists? Developers tried all of those out first, with many seeing the problematic social mechanics and rejecting them early, instead of running the hamster w…

That’s certainly possible, and you’re right about the leading edge early adopters dictating the success or failure of a system.

I’d be delighted if I could get Windows 10/iOS/MacOS-level reliability and functionality out of Linux and would switch to it as a daily driver. But the delta in user experience right now is massive, so I just use Linux for the things that only work on Linux

Re: The Gates to Hell: Apple’s Notarizing

#202

Post by AnthonyMouse »

zackees wrote: post #176
AnthonyMouse wrote: post #173

Earlier quoted context omitted.

> I think the issue with pushing malware signatures to the client is that it is reactive rather than proactive - i.e. by the time you have identified a malware signature, it is already too late (which leads to an inevitable cat-and-mouse / whack-a-mole game). But notarization is the same. Apple isn't vetting notarized apps before they're distributed. All it does is impose a cost on the developer, who could still for…

Malware can change its signature and then it’s no longer on the exclusion list. However if an inclusion list is used, then the malware changing its signature means that it loses the ability to execute.

Except that approval is automatic so they just modify the signature and submit it to be included again.

Re: The Gates to Hell: Apple’s Notarizing

#203

Post by AnthonyMouse »

iancarroll wrote: post #179
AnthonyMouse wrote: post #171

Earlier quoted context omitted.

> Notarization is clearly part of a defense in depth strategy for macOS. Defense in depth means layering security. It's, for example, when you use password hashing but also full disk encryption. That way if someone gets your hard drive, even if they break the disk encryption, they don't get your password in plaintext. Even if they know how to crack the password hash, they first have to get past the disk encryption. N…

Notarization is distinct from code signing/signatures, and has distinct security benefits. Notarization involves uploading the entire binary to Apple, where signatures involve you creating signatures on files that Apple is blind to. Apple cannot guarantee they are revoking all certificates for a given malicious application with code signing, because they do not know what variants exist even if they have obtained one…

It's linguistically confusing to try to distinguish between malware signatures and digital signatures when we're comparing them, so let's call one fingerprinting and the other one certifying.

> Apple cannot guarantee they are revoking all certificates for a given malicious application with code signing, because they do not know what variants exist even if they have obtained one of them.

This is making the case that certification/notarization is worse than fingerprinting because the same malicious application could have multiple independent certificates. But since notarization is the thing people are objecting to, that's no argument in its favor. (Though, of course, they could, and possibly do, refuse to notarize apps with known-malicious fingerprints, so if there is a difference there at all then it's only by implementation and not by necessity.)

> With notarization, they can search for these variants and prevent new variants from being signed by new developer accounts -- protecting machines that i.e. have outdated XProtect definitions.

Let's think about this for a minute. You have a malicious application that at one point had a valid certificate. The user goes to run it.

If they have a working network connection to check whether the certificate is revoked, they have a working network connection to get the latest malware fingerprints. If they don't, they get neither. So what's it buying you?

Re: The Gates to Hell: Apple’s Notarizing

#204

Post by AnthonyMouse »

jolux wrote: post #178
AnthonyMouse wrote: post #171

Earlier quoted context omitted.

> Notarization is clearly part of a defense in depth strategy for macOS. Defense in depth means layering security. It's, for example, when you use password hashing but also full disk encryption. That way if someone gets your hard drive, even if they break the disk encryption, they don't get your password in plaintext. Even if they know how to crack the password hash, they first have to get past the disk encryption. N…

XProtect has a wider scope than notarization, though, and its detection rules are different. Notarization and XProtect are both focused on stopping malware but they don't actually operate on the same principle, notarization happens in the cloud before deployment (to stop malware from being deployed) and XProtect happens continuously in the operating system (to stop malware from running), checking for malicious signat…

It operates based on the same principle. There is a list of known-malicious software and you reject that software. If the bad software is known, they can both reject it. If it isn't known, neither of them would.

Defense in depth requires one of the measures to catch things the other one wouldn't.

Re: The Gates to Hell: Apple’s Notarizing

#205

Post by GekkePrutser »

sneak wrote: post #200
GekkePrutser wrote: post #197

Earlier quoted context omitted.

Well by turning it off I mean blocking ocsp.apple.com in my firewall. I do this personally, not at work by the way. But yes they should really provide a way to properly turn it off in the OS itself. By the way another issue I have with the developer cert thing is that this way they will block all your apps if they have an issue with just one thing you've uploaded. And we all know Apple tends to blur the line between…

There are a lot of other host names that need blocking, too, pancake.apple.com and xp.apple.com and *.push.apple.com among them The amount of spyware in macOS these days is absolutely astounding: https://sneak.berlin/20210202/macos-11.2-network-privacy/

Thanks, again something I wasn't aware of. The problem with the push one is that blocking it will also block some legitimate stuff unfortunately :(

I'll keep an eye on your blog! Excellent info.

Re: The Gates to Hell: Apple’s Notarizing

#206

Post by Klonoar »

saagarjha wrote: post #161
Klonoar wrote: post #135

Earlier quoted context omitted.

Hmmm, well I'm willing to believe it then, yeah (although I definitely have a nested bundle setup in a project where --deep works fine... odd). This is good to know though, and hopefully this exchange helps someone in the future too (actually, this would make for a good blog post - this kind of nuance is lost in most of the docs/existing posts).

If you're curious, Quinn (the Eskimo) has more details: https://developer.apple.com/forums/thread/129980

Perfect, exactly what I was looking for. Thanks!

Re: The Gates to Hell: Apple’s Notarizing

#207

Post by AnthonyMouse »

AnthonyMouse wrote: post #204
jolux wrote: post #178

Earlier quoted context omitted.

XProtect has a wider scope than notarization, though, and its detection rules are different. Notarization and XProtect are both focused on stopping malware but they don't actually operate on the same principle, notarization happens in the cloud before deployment (to stop malware from being deployed) and XProtect happens continuously in the operating system (to stop malware from running), checking for malicious signat…

It operates based on the same principle. There is a list of known-malicious software and you reject that software. If the bad software is known, they can both reject it. If it isn't known, neither of them would. Defense in depth requires one of the measures to catch things the other one wouldn't.

People seem to be having trouble with this, so let's go to the ogre analogy.

Defense in depth is layered, like an onion.

Combining automatic certification with fingerprinting is layered, like a cake. It's not the same thing.

Re: The Gates to Hell: Apple’s Notarizing

#208

Post by tonyedgecombe »

judge2020 wrote: post #192
tonyedgecombe wrote: post #186

Earlier quoted context omitted.

I just renewed a certificate using Sectigo, it was a painful experience.

Wasn't for me. That site's renew button simply starts an order for a new one (as renewal is really just replacing with a new, extended certificate) and sectigo themselves re-did all the company verification, after which my cert was issued. Went smoothly except for waiting ~24 hours for it. If you were trying to get an EV certificate, the process is supposed to be more strenuous on making you prove your operation (som…

It wasn't an EV certificate, just ordinary code signing. I guess you were just lucky.

Re: The Gates to Hell: Apple’s Notarizing

#209

Post by anentropic »

comex wrote: post #194
anentropic wrote: post #190

Earlier quoted context omitted.

Not by me... and it's my own code build from src in a github action.

When targeting ARM macOS, the linker automatically ad-hoc signs everything it outputs. You can check this by running `codesign -dvv` on the binary. Alternately, if your binary is an Intel binary running under Rosetta, those can be unsigned.

Hmm, it was built on Intel though (GitHub Actions macos runners are only Intel)

But maybe some other part of the toolchain (Gradle, GraalVM native-image) was implicitly ad-hoc signing it

Re: The Gates to Hell: Apple’s Notarizing

#210

Post by anentropic »

anentropic wrote: post #209
comex wrote: post #194

Earlier quoted context omitted.

When targeting ARM macOS, the linker automatically ad-hoc signs everything it outputs. You can check this by running `codesign -dvv` on the binary. Alternately, if your binary is an Intel binary running under Rosetta, those can be unsigned.

Hmm, it was built on Intel though (GitHub Actions macos runners are only Intel) But maybe some other part of the toolchain (Gradle, GraalVM native-image) was implicitly ad-hoc signing it

https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-...

"This new policy doesn’t apply to translated x86 binaries running under Rosetta"

...I guess that's why.

The whole situation is so confusing. The article talks about how unsigned code won't run on ARM macs, but an ad hoc cert is fine.

I suppose this fits what others have said in the thread - unsigned native-ARM binaries will be completely blocked. Unsigned x86 binaries can run on ARM macs under Rosetta (what I tried... or possibly my bin was signed by the build tool).

But all these will still get block/warnings from Gatekeeper if un-notarized, which is the part you have to pay for.

This https://github.com/Homebrew/homebrew-core/issues/47129 suggests there is yet another factor to consider - the "quarantine" flag. Presumably downloading a tar.gz from github releases via Chrome gets a quarantine flag triggering the Gatekeeper warnings. That Homebrew issue (from 2019 though...) seems to say that "bottles" installed via Homebrew (which is basically the same thing - a precompiled bin downloaded from internet) won't have the quarantine flag set and they just need to be ad-hoc code-signed.

Post reply on HN