The Gates to Hell: Apple’s Notarizing • Hacker News Board

Re: The Gates to Hell: Apple’s Notarizing

#191

Post by api » Sat, May 01, 2021, 1:11 PM UTC

SheinhardtWigCo wrote: post #142

api wrote: post #91

All this code signing stuff is an admission of defeat. "Our OSes are insecure and we can't secure them, so fuck it." Unix and VMS/NT, the two most popular kernel lineages, were both designed when computers were either isolated or connected to an Internet that was effectively an academic/government walled garden. They absolutely were not designed to deal with the present information war zone where everything is trying…

An admission of defeat is one way to look at it, or you could describe it as acceptance of reality. As you point out, security engineers have been working for decades on a vast array of techniques to mitigate classes of vulnerabilities. There's no reason to believe this is something that can ever be finished. There will always be bugs, always. Code signing embraces that reality by making it much easier to contain bad…

I didn’t say you’d just rewrite it in Rust and that’s it, just that the use of safe languages would be one thing that would help. We really do need to get away from C with its endless footguns.

Apps absolutely do not run with least privilege on any current popular OS. If I install an app on Windows, Linux, or Mac it can see tons of my data out of the box. In some cases it can see the whole system except for specifically locked directories and files. Then there’s the huge pile of local exploits afforded by unsafe languages and cruft.

Perfection may not be possible but if OS app isolation were as good as popular browser JS environments that would go a long, long way toward making it safer to run stuff locally.

Re: The Gates to Hell: Apple’s Notarizing

#192

Post by judge2020 » Sat, May 01, 2021, 2:30 PM UTC

tonyedgecombe wrote: post #186

judge2020 wrote: post #153

Earlier quoted context omitted.

The cheapest base code signing certificate will be via a Sectigo (formerly Comodo, although they allow resellers to advertise either brand) reseller. I'm not affiliated with this site beyond being a customer, but the website 'codesigncert.com' is the absolute cheapest i've found for Windows signing (EV 3 years: $219/yr [0] / regular 3 years: $59/yr [1]). Note that this landscape might change in the future. Microsoft…

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 (sometimes) as well as prove that your certificate infrastructure is secure enough.

Re: The Gates to Hell: Apple’s Notarizing

#193

Post by maxwell » Sat, May 01, 2021, 3:20 PM UTC

pwinnski wrote: post #138

maxwell wrote: post #134

Earlier quoted context omitted.

Where's a good branded phone? Linux is already running on the majority of smartphones, individual manufacturers and distros seem less important. Any Android user would switch to another Linux phone with the right features, price, etc. iOS seems poised for a slow ride into irrelevance as developers start suing them and begin leaving (Basecamp, Spotify, Epic...), before long they'll be the dusty old devices in schools…

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 wheel to enrich others and centralize power in furtherance of one's own greed.

If enough developers give up on the proprietary OSs and just run Linux, which is basically actually doable now, the tides will turn. Certainly unclear if developers will unify and go all in on Linux, of course, but given historical trends it looks quite likely.

Anecdotally, I've always been fine enough with Win and Mac since the '90s, fine with iOS and Android since the '00s/'10s. But something shifted last year, and while I will remain a user, I've mostly given up on actively developing/maintaining native or web apps targeting those platforms.

Re: The Gates to Hell: Apple’s Notarizing

#194

Post by comex » Sat, May 01, 2021, 4:36 PM UTC

anentropic wrote: post #190

saagarjha wrote: post #158

Earlier quoted context omitted.

I suspect that the code you're trying to run is ad-hoc signed.

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.

Re: The Gates to Hell: Apple’s Notarizing

#195

Post by GekkePrutser » Sat, May 01, 2021, 5:37 PM UTC

I agree about notarisation, I think it's the wrong solution. It gives Apple too much insight in what applications are used on Macs. This is my business and mine alone. I don't wany my Mac calling home with everything I open. Despite there being a way to turn it off.

I think simply spreading signatures of known malware for a local check would be a much better option.

However as a Mac enterprise admin I don't think the process is particularly difficult. When it came in I scripted it all once and that worked fine. Only issue is that sometimes it doesn't like if I make a PKG with a package from another supplier embedded in it. The problem is that I have to do that because some solutions have several packages that need to be installed in a particular order, and my MDM (MS Intune) does not provide a means by which to specify installation order. It just blasts all packages in a random order at the machines. So I re-package those. But anyway even that is not all that tough to get around.

Re: The Gates to Hell: Apple’s Notarizing

#196

Post by sneak » Sat, May 01, 2021, 5:40 PM UTC

GekkePrutser wrote: post #195

I agree about notarisation, I think it's the wrong solution. It gives Apple too much insight in what applications are used on Macs. This is my business and mine alone. I don't wany my Mac calling home with everything I open. Despite there being a way to turn it off. I think simply spreading signatures of known malware for a local check would be a much better option. However as a Mac enterprise admin I don't think the…

> Despite there being a way to turn it off.

There isn't; the OCSP checks happen on launch automatically.

I got Apple to encrypt it next year and delete their logs, though, thanks in part to the publicity afforded by HN to my yelling about it. They also committed to adding an off switch.

Hopefully they'll do it in a clever, privacy-preserving way using a bloom filter or something, instead of just sending the developer cert hash up to Apple as soon as you double-click an app.

Re: The Gates to Hell: Apple’s Notarizing

#197

Post by GekkePrutser » Sat, May 01, 2021, 5:49 PM UTC

sneak wrote: post #196

GekkePrutser wrote: post #195

I agree about notarisation, I think it's the wrong solution. It gives Apple too much insight in what applications are used on Macs. This is my business and mine alone. I don't wany my Mac calling home with everything I open. Despite there being a way to turn it off. I think simply spreading signatures of known malware for a local check would be a much better option. However as a Mac enterprise admin I don't think the…

> Despite there being a way to turn it off. There isn't; the OCSP checks happen on launch automatically. I got Apple to encrypt it next year and delete their logs, though, thanks in part to the publicity afforded by HN to my yelling about it. They also committed to adding an off switch. Hopefully they'll do it in a clever, privacy-preserving way using a bloom filter or something, instead of just sending the developer…

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 plain old malware and "against our T&C/Commercial interests". They already have a say in what apps I can use on my iPad. Like the ban on emulators, etc. It's my device, it should be a recommendation at most.. This is why I fear they are moving Mac in this direction as well.

PS: I didn't realise you were the one who raised this issue a couple months ago. Thanks for your work!!

Re: The Gates to Hell: Apple’s Notarizing

#198

Post by sneak » Sat, May 01, 2021, 5:50 PM UTC

Svoka wrote: post #185

I don't get the whole panic around notarization. I maintain a big open source project, and is quite complex. It is a game engine with downloadable plugins and lots of system integration. Notarization was easy. I didn't use Xcode GUI for it, because it has one line command to do it, which is more comfortable for me: https://github.com/coronalabs/corona/blob/53eeb3e31ac09f7a46... Not a biggie.

The panic is that it is an anticompetitive moat that they are setting up that, if used in such a way, would allow them insane preference for their own App Store on all Apple computers.

Imagine what sort of system-level settings you'd have to change on macOS today if you wanted to ship a competing macOS App Store on Apple devices with UX similar to Apple's own, but without Apple signing keys.

You'd basically have to write some malware-style code to get inside of Gatekeeper and privilege your downloaded/purchased apps the same way Apple does for apps from their own App Store.

How long do you think they would let this stand before trying to whack your installer daemon with XProtect for posing "danger to profit integrity"? (They'd spell "profit" as "system", though.)

Re: The Gates to Hell: Apple’s Notarizing

#199

Post by sneak » Sat, May 01, 2021, 5:52 PM UTC

galad87 wrote: post #38

anentropic wrote: post #32

And, not mentioned in the article... you have to have an Apple Developer ID which costs £79/year ($99). Presumably if your subscription lapses any previously released software will stop working? That is the part I find most offensive, if it was just difficult and buggy I would suck it up and work around it. But having to pay for the privilege is too painful, particularly if you're offering free software. For my case…

No, if your subscription lapses previously released software won't stop working. If you are offering free software you can sign with an ad-hoc certificate, and instruct the user on how to bypass gatekeeper, which isn't great at all but it doesn't cost any $$.

Instructing users on how to bypass gatekeeper is a nonstarter, as explained here:

https://lapcatsoftware.com/articles/unsigned.html

This simply is not a viable distribution method for the mass market. Apple has positioned apps from devs that pay Apple so far above apps from devs that don't that you cannot compete outside of their subscription revenue model.

Re: The Gates to Hell: Apple’s Notarizing

#200

Post by sneak » Sat, May 01, 2021, 7:27 PM UTC

GekkePrutser wrote: post #197

sneak wrote: post #196

Earlier quoted context omitted.

> Despite there being a way to turn it off. There isn't; the OCSP checks happen on launch automatically. I got Apple to encrypt it next year and delete their logs, though, thanks in part to the publicity afforded by HN to my yelling about it. They also committed to adding an off switch. Hopefully they'll do it in a clever, privacy-preserving way using a bloom filter or something, instead of just sending the developer…

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/