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

151–160 of 214 posts

Re: The Gates to Hell: Apple’s Notarizing

#151

Post by judge2020 »

DCKing wrote: post #48
mmastrac wrote: post #7

Notarization has been a nightmare of a solution to a problem that isn't effective. You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach of having Apple archive each and every bit of code that you generate for distribution. This is just Apple's overreach extended to the desktop. Excessive control that makes developer's lives hell while adding barely…

Having to get any Apple code signing key for regular users is a barrier of entry for malware. However low it is, it is there. Moreover, it gives Apple the power to revoke certificates in the future to at least attempt to contain further malware activity. Is it really that hard to get your code signed as a malware developer? No, not at all. Is that worth bothering developers so much? Maybe not. Is it a power grab? Pro…

The economics also work in Apple's favor as it either requires using your real identity to commit fraud, committing identity theft by creating an LLC with someone else's identity, or paying for a registered agent in a third-world country to sign up for you (not sure how much that costs though, I've never looked!). I'm sure most malware cases they deal with are triaged for the possibility of filing a police report.

Re: The Gates to Hell: Apple’s Notarizing

#152

Post by dunham »

cwizou wrote: post #55

The initial setup is a bit of a pain (and the documentation is a bit lacking - though much better than most Apple documentation - particularly for edge cases like mine, distributing a screensaver), but to Apple's credit the process is pretty solid and is now consistently quick. I've notarized dozens of builds of Aerial since the requirement was announced and I think only once did I have to wait to release because the…

Yup, "You must first sign the relevant contracts online." And large company, so I've gotta track down the guy that can actually sign the contracts.

Re: The Gates to Hell: Apple’s Notarizing

#153

Post by judge2020 »

nly wrote: post #150
Klonoar wrote: post #109

Earlier quoted context omitted.

Cheap considering buying a proper certificate for signing and releasing on Windows will often cost you the same. ;P If your bar to hit is Linux, you'll never be happy with anything.

On this note, does HN know where to acquire the cheapest possible code signing cert for Windows?

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 is working on Azure Code Signing, which will mean Microsoft themselves manages issuing the certificate, doing the identity verification, etc - the only catch being that they probably don't want to have to deal with any lost keys or improperly stored keys, so they don't let you generate your own cert and you can only sign certs via the API or other integrations. All of this info is available via this talk [2] and it's the only public information available on this service that i've found.

0: https://codesigncert.com/sectigo-ev-code-signing

1: https://codesigncert.com/sectigocodesigning

2: https://youtu.be/Wi-4WdpKm5E?t=530

Re: The Gates to Hell: Apple’s Notarizing

#154

Post by fiddlerwoaroof »

Closi wrote: post #62
mmastrac wrote: post #7

Notarization has been a nightmare of a solution to a problem that isn't effective. You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach of having Apple archive each and every bit of code that you generate for distribution. This is just Apple's overreach extended to the desktop. Excessive control that makes developer's lives hell while adding barely…

> You can get practically as much security by pushing malware signatures to the client without the massive privacy overreach 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).

So, my take has been that Apple’s been doing a long push to switch incrementally from a Unix user/group/ACL security mode to a capability model: the various entitlements, things like PowerBox not having an API, notarization, etc.

The big issue I’ve always had with capability security (as implemented here and in Fuschia) is that, while it is a better security model in many ways, it’s also a lot easier to use against developers and power users, especially when you depend on PKI to implement your unforgeable tokens.

Re: The Gates to Hell: Apple’s Notarizing

#156

Post by hansvm »

Klonoar wrote: post #147
sorbits wrote: post #140

Earlier quoted context omitted.

While you only have to update your build process once, you now have a noticeable delay for every single release build, and worse, a few times per year, your build will break because you haven’t signed Apple’s latest contract. And for what? There is no way Apple can make it impossible to get malware notarized.

But your release build is not done constantly, and so you have to sign in and accept an agreement - neither of which is a big deal.

> But your release build is not done constantly

Some people (are they the minority? probably?) cut release builds frequently enough for it to be a big pain point.

> and so you have to sign in and accept an agreement - [which isn't] a big deal

It probably is though. Have _any_ agreements you've accepted in the last, say, 5yrs not had blatantly overbearing or malicious terms?

Re: The Gates to Hell: Apple’s Notarizing

#157

Post by saagarjha »

judge2020 wrote: post #151
DCKing wrote: post #48

Earlier quoted context omitted.

Having to get any Apple code signing key for regular users is a barrier of entry for malware. However low it is, it is there. Moreover, it gives Apple the power to revoke certificates in the future to at least attempt to contain further malware activity. Is it really that hard to get your code signed as a malware developer? No, not at all. Is that worth bothering developers so much? Maybe not. Is it a power grab? Pro…

The economics also work in Apple's favor as it either requires using your real identity to commit fraud, committing identity theft by creating an LLC with someone else's identity, or paying for a registered agent in a third-world country to sign up for you (not sure how much that costs though, I've never looked!). I'm sure most malware cases they deal with are triaged for the possibility of filing a police report.

It turns out that getting access to an Apple developer account is not all that hard.

Re: The Gates to Hell: Apple’s Notarizing

#158

Post by saagarjha »

anentropic wrote: post #132
galad87 wrote: post #111

Earlier quoted context omitted.

Unsigned (arm64) binaries don't run at all on M1 Macs, so yes, an ad-hoc certificate provides a better experience ;)

I just tried an unsigned bin on M1 Big Sur and the experience is the same: it's initially blocked with a "Move to Trash" dialog but you can go to security prefs and click "allow anyway" Then try again, click "open" rather than "move to trash" on another warning dialog and the file does get run. I haven't tried a signed+un-notarized one but it sounds like it'd be similar?

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

Re: The Gates to Hell: Apple’s Notarizing

#159

Post by saagarjha »

jerrysievert wrote: post #149
foepys wrote: post #116

Earlier quoted context omitted.

What happens when the cert root expires? Does it not expire or does Apple grant an eternal valid signature when apps were signed before the root expired?

For apps I’ve downloaded on my iPhone, there are sometimes updates that denote Apple updated the key. Assuming that’s App Store only behavior though.

Apple just did this recently for iOS 14.5, actually.

Re: The Gates to Hell: Apple’s Notarizing

#160

Post by kitsunesoba »

maxwell wrote: post #2

Apple devices are becoming increasingly unusable for developers. Fantastic opportunity for Linux apps to gain more dev resources, as anyone with a bit of foresight sees little future in macOS, iOS, Windows, or Android as development platforms.

I think Linux needs a better desktop GUI development story before its app ecosystem can really bloom.

The most complete it has now are the Qt-based KDE frameworks, but those are natively C++, and many if not most developers are not going to want to have to deal with C++ no matter how many quality of life affordances are offered by Qt. Bindings exist, but are limited to a handful of languages and come with their own quirks.

GTK is much better from a bindings standpoint, but isn't as complete as the KDE frameworks meaning devs have to bring a lot of their own stuff, plus GTK devs are subjected to new releases pulling the rug out from under them with new versions.

What I'd really like to see is an equivalent to AppKit, which includes practically everything needed for the most app (reducing dependencies to a minimum) and is C-accessible making it reasonable to write bindings for other languages for.

Post reply on HN