
Signing Your Apps for Gatekeeper - atarian
https://developer.apple.com/developer-id/
======
makecheck
On the one hand, of all the big companies, Apple seems closest to “getting it”
with respect to security.

On the other hand, NO entity is inherently trustworthy “forever”, nor should
any entity have the power to be a unilateral Decider even on its own platform.
Just like when a good restaurant may some day become bad under new management,
we are just one “new management” away from Apple becoming something that maybe
we don’t trust so much. This system is being set up to give “Apple” tremendous
power for “all future definitions of Apple”, which is ridiculous. That
wouldn’t make sense even if Apple were a perfect saint today, invulnerable to
buggy software and disgruntled employees and other potential weaknesses.

We need a system whereby users decide which _SET_ of entities they trust, one
of which may include Apple, and which may even _exclude_ Apple if the user so
chooses. The complex mechanism for signing and verifying things should be
open-source so it can be understood and validated and reproduced cross-
platform. Then you decide who you trust, period. You can rely on others to
help you determine what is trustworthy. Given _this_ type of system, I would
be fine with macOS saying “select at least one trusted source to enable
software installations”, knowing that I ultimately decide what those
authorities will be. I am _not_ fine with their seeming “father knows best”
approach.

~~~
ChrisSD
To paraphrase an infamous quote: Apple have root.

What good is any signing if you can't trust the OS? There are a myriad of ways
they could undermine the verification.

~~~
JohnStrangeII
Your position is based on an (implicit) false dilemma.

It's perfectly possible to "trust" Apple in the sense that you use their
operating system and hardware after you've bought it. This kind of "trust" is
similar to "agreeing with an EULA or TOS". There is not much of an alternative
to it.

This does not imply that you therefore must also trust Apple as the one and
only broker and manager of certificates for software running on your machine.
You could, for example, suspect that Apple might revoke a certificate for some
developer that creates a controversial product (e.g. a p2p client) or some
product that competes with Apple products or some future plans of features.
For example, Apple has in the past essentially copied innovative apps and
revoked licences for the app store of the original developers. In theory,
Apple could just erase such applications, since they "have root". In practice,
they wouldn't do so. But they would and will revoke certificates and app store
licences.

The new rules also make alternative app stores impossible, of course, although
I'm not sure they were possible before.

In a nutshell, trust != trust. You can trust a hardware or software maker in
some respects but not in others.

The primary goal of Gatekeeper is monopolization of secure access, not
security.

~~~
vsl
> For example, Apple has in the past essentially copied innovative apps and
> revoked licences for the app store of the original developers.

Source? I develop in the Apple ecosystem and never heard of this. Would be
scandalous.

“Heavily inspired” Apple apps, yes. Revoking certificates or access to
developer program (which I guess you must mean by “App Store licenses”,
because there’s no such thing otherwise), not that I’m aware of.

------
gergles
So this is another step for Apple to try to get everyone paying them their
software development tax, since "notarization" requires you paying the $100
annual fee.

While you currently can still run digitally signed software that is not
notarized, this document admits that in the future signed software will
require Apple's approval, so Apple will make everyone's software LESS secure
(by forcing developers to not sign the code if they aren't paying Apple) so
that it will continue running.

Sigh.

~~~
danieldk
_So this is another step for Apple to try to get everyone paying them their
software development tax, since "notarization" requires you paying the $100
annual fee._

I don't think Apple really cares about the fee. I know that the three
platforms are now bundled together under one developer program, but suppose
that there are 100,000 Mac developers that publish signed or App Store
applications (which is probably an overestimation), the fees will make Apple
10 million. This is less than pocket change to them.

To me it seems that the $100 annual fee is to prevent fraud: (1) using a
credit card to tie the developer account to an actual person; (2) make it
expensive enough to avoid playing whack-a-mole with malicious account
creation.

~~~
camillomiller
Indeed. Plus don't underestimate the psychological barrier that value can
provide. 100$ are a sweet spot: it keeps everyone and their dog from signing
up just because ("it's free, I might give it a go"), but at the same time it's
not too much for a motivated developer who wants to dabble into programming
for the Apple ecosystem of devices.

~~~
SSLy
>it's not too much for a motivated developer

living in a first world state.

~~~
icebraining
We're talking about owners of a Mac. They're not likely to be _that_ strapped
for cash, regardless of where they live.

~~~
LaGrange
Plenty of people out there with hand-me-down or 2nd (or 3rd) hand Macs.

~~~
icebraining
At a global level, those are called "rich people". I'm sure you can find some
individual exception somewhere, but by and large every mac user will be able
to scrape or borrow $100 by the time their software is developed, tested and
ready to ship.

~~~
LaGrange
That is so hilariously out of touch I feel hard not to consider this wilful
ignorance.

~~~
icebraining
That seems uncharitable of you.

------
GeekyBear
A pretty good blog summary of how this differs from past practice.

[https://eclecticlight.co/2018/09/24/has-that-app-been-
notari...](https://eclecticlight.co/2018/09/24/has-that-app-been-notarized-
and-what-are-the-benefits-to-the-user/)

TLDR: You have to adopt the new OS user privacy protections. (Users must give
permission for your app to access things like the webcam, microphone,
contacts, photos, location data, etc.)

Your app gets scanned for malware before it is signed.

There is still no App Store approval process involved.

~~~
saagarjha
> You have to adopt the new OS user privacy protections.

Don't you have to do this anyways?

------
jtokoph
> Note that in an upcoming release of macOS, Gatekeeper will require Developer
> ID signed software to be notarized by Apple.

Does this mean that anything distributed outside of the App Store will have to
be approved by Apple? Will the App Store sandboxing rules apply to outside
apps too?

~~~
notafraudster
No, that's not what it means. Currently there are three security tiers for
applications on macOS: App Store, not App Store but cryptographically signed,
and not cryptographically signed. All three can be run.

That sentence means that in the future, the second category (applications
which are not on the App Store but are cryptographically signed) will need you
to generate a certificate with Apple. Nothing about the app store's sandboxing
rules, and nothing about all applications -- you can run unsigned applications
to your heart's content.

~~~
api
It's another slow gradual step toward total lockdown.

I feel like eventually I'll have to abandon Mac, but for what? Linux is still
flaky and Windows adware unless you spring for Enterprise.

I would pay for a commercial Linux as polished as MacOS, but there may not be
enough of me. (It could also have a list of officially supported hardware to
at least approach the stability benefits of Apple's vertically integrated
HW/SW stack.)

~~~
losteric
Not debating Apple's overall trajectory, but I think it's cynical to call this
a step towards lockdown. Mitigating certificate forgery attacks ultimately
increases trust in software distributed outside Apple's walled garden.

~~~
thefounder
How is this not lock-down? If Apple doesn't like VLC or whatever software
competes with their interests they can simply not renew their membership.

~~~
klodolph
Are you talking about the old policy?

You can run unsigned apps. The new policy affects the process for signing
apps.

~~~
fiddlerwoaroof
But things like gdb just don’t work unless they’ve been signed. So, if Apple
starts blocking unnotarized aogned apps, whether or not these programs will
run will depend on whether Apple considers them malicious

~~~
geocar
You can still self-sign your apps.

------
thefounder
So if Apple won't like my app it won't renew my developer account so that I
cannot sign it anymore. Seems quite "fair" and I sense no lock-down or
censorship. Let's be happy for making the internet "safer". As some have said
this is good news for ...(fill the gap)

~~~
klodolph
Are you talking about the old policy, or what? The only thing that has changed
here is the process for signing an app, which has always required a developer
account. It just requires uploading a binary now, instead of working entirely
offline. And you can still run unsigned apps.

~~~
thefounder
You didn't need a Apple developer account to sign the app if you used a 3rd
party(i.e digicert) certificate/signer.

~~~
galad87
Yes, you can sign an app with a third party certificate, but only a Developer
ID certificate works with Gatekeeper. And there is no app review when you
notarise and app anyway.

~~~
thefounder
Of course it's a review process. That's why you need a developer ID. The only
difference is that the app will be reviewed "later". Here is an example: You
sign an app like "uTorrent", all is working great, people can download and run
it. Then mpaa tells Apple to ban your application because it's used to pirate
their content. Apple now "reviews" your app and suspends your developer id. O
top of that it tells gatekeeper to stop running the installed instances.
Review done! Any question? Please review our TOS to find out why we blocked
your app...bla bla blah

~~~
galad87
No it's not. It's an automated malware scan. They can already revoke Developer
ID certificates and block whatever they want by updating XProtect (even
unsigned apps).

------
rgovostes
I was recently cleaning off someone's Mac and made this note:

> I found no fewer than eight fake Adobe Flash updaters, six of them identical
> and signed by Nevaeh Mitchell (WMAA75SZMS), one signed by Lambert Jeremy
> (B4MCPEJ42J), and one by Wolfe Bailey (3W8NF7PWUL). It does not appear that
> Apple has revoked any of these signing certificates or flagged any of these
> installers through macOS's built-in malware removal tools.

So it doesn't seem to me that malware authors are exactly afraid of signing
requirements.

------
abcd_f
Today it may be optionally notarized.

Tomorrow it must be notarized.

Then it won't be notarized if it uses "dangerous" APIs.

Then it won't be notarized unless it's distributed through the AppStore.

You can't force every vendor into the AppStore, but you can gradually train
_users_ to distrust everything that's not in it. What we are seeing here is
just an Act 1 of that.

------
foobarbazetc
Did anyone figure out how to just get a DMG or whatever created outside Xcode
notarized? These docs are too Xcode focused.

~~~
varenc
The docs say you can use ‘xcrun altool’ to get a dmg/zip/pkg notarized. That’s
an XCode tool but no indication that what you’re submitting needs to be
created in XCode.

~~~
saagarjha
Xcode doesn't do anything special to your binary; you should be able to submit
a valid codesigned application bundle AFAIK.

~~~
foobarbazetc
The problem is the “submit” part. I.e. the docs say “xcrun aitool” but doing
that gets some you an undocumented CLI app where it seems like you have to
supply your Apple ID and password on the command line.

Seems... less than ideal? How does that work with 2FA?

~~~
geocar
> How does that work with 2FA?

It's for people who want to submit their app non-interactively (e.g. as part
of a build process). Those people aren't going to use 2FA since the keys are
under control of a robot.

------
sophiebits
This protects against… making many slightly-different copies of a malware app
and signing them all locally, so that revoking one doesn't affect the others?

~~~
IBM
This lets Apple nuke a compromised version of an app without doing it to all
versions or apps by that developer. Which would have been useful in the case
of Transmission [1][2].

[1] [https://arstechnica.com/information-
technology/2016/03/first...](https://arstechnica.com/information-
technology/2016/03/first-mac-targeting-ransomware-hits-transmission-users-
researchers-say/)

[2] [https://blog.malwarebytes.com/threat-
analysis/2016/09/transm...](https://blog.malwarebytes.com/threat-
analysis/2016/09/transmission-hijacked-again-to-spread-malware/)

~~~
mrpippy
Transmission’s Developer ID cert wasn’t compromised, the compromised binary
was signed by a different developer.

------
garganzol
So, basically this a replay of Orwellian "1984" where the tables have turned.
Now Apple _is_ the Big Brother and it is there to _dictate._ Who is going to
throw that hammer nowadays?

------
gamegod
Remember that time Apple messed up and decided to punish all their app
developers by forcing them to resign their apps?

------
tmymt
What's the difference between this and Authenticode?

------
bunnycorn
Good, this doesn't even need for the software to be sent to Apple, only the
hash.

~~~
jtbayly
How can they scan your software and run security checks on it based only on a
hash?

Are the checks actually run locally by xCode?

~~~
pgib
> Give users even more confidence in your software by submitting it to Apple
> to be notarized. The service automatically scans your Developer ID-signed
> software and performs security checks.

Looks like it uploads a bundle to them for all that to happen on their side.

------
mariopt
What does this mean for non open source projects? They need to submit the
source code to ensure there is no malware, right? This is the standard
practice in iOS apps.

~~~
lwansbrough
iOS app binaries are submitted to the App Store, not the source code. Malware
is detected via static analysis of the byte code (and presumably some runtime
heuristic analysis) but it isn’t perfect.

~~~
scarface74
For the most part, the main thing that I’m aware that static code analysis
detects is using non public APIs. Most of the malware protection comes from
IOS’s sandbox.

