12 ms·

Signing Your Apps for Gatekeeper

211 points by atarian 8y ago

bunnycorn 8y ago
Good, this doesn't even need for the software to be sent to Apple, only the hash.
- jtbayly 8y ago
  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 8y ago
    > 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.
  - orf 8y ago
    They scan the software, not your software. If the hashed match against a known scanned good bit of software then it's safe. Maybe.
  - deleted 8y ago
    [deleted]
  - benatkin 8y ago
    The software is sent to Apple when it is notarized. When a user downloads and runs it, it is not sent to Apple. It just uses the hash. It would be pretty crazy for Mac OS to send the whole package to Apple to do a security scan, but a naive reader might think that.
mariopt 8y ago
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.
- deleted 8y ago
  [deleted]
- lwansbrough 8y ago
  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 8y ago
    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.
- pducks32 8y ago
  iOS does not involve sending your source code. This involves ensuring your app runs in their Hardened Runtime and is properly signed. Apple checks that there is no Malware.
- djrogers 8y ago
  > This is the standard practice in iOS apps. Pretty sure you’ve got your wires crossed here - you absolutely do not have to submit source code to put your app on the App Store.
sophiebits 8y ago
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 8y ago
  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-mac-targeting-ransomware-hits-transmission-users-researchers-say/ https://arstechnica.com/information-technology/2016/03/first... [2] https://blog.malwarebytes.com/threat-analysis/2016/09/transmission-hijacked-again-to-spread-malware/ https://blog.malwarebytes.com/threat-analysis/2016/09/transm...
  - mrpippy 8y ago
    Transmission’s Developer ID cert wasn’t compromised, the compromised binary was signed by a different developer.
jtokoph 8y ago
> 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 8y ago
  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 8y ago
    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.)
    - Spivak 8y ago
      I mean RHEL Workstation is a very polished Linux environment. It might not be up to date enough for your needs but it's very stable and we'll documentated. Not the best for a laptop though. I would spring for Fedora or Ubuntu and deal with the lack of paid support for my own personal use but then again I've been using Linux for a while. Both options are perfectly stable desktops, it's really the commerical software support that will get you.
      - 8y ago
gergles 8y ago
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.
- seandougall 8y ago
  As others have pointed out, you already have to pay the tax to get a trusted signing certificate. So as far as the economics go, this isn’t a change.
  - thefounder 8y ago
    It's actually a big change. One issue is that Apple may not approve you(for whatever reason) or keep you on the waitlist for weeks(happened to me). Not to mention that there won't be any competition. Next would be to make Safari and any browser running on osx accept only Apple tls certificates. That would be "awesome"! Finally Apple "secures" the internet
    - millstone 8y ago
      It's a big change because Apple may keep you on the waitlist for weeks, which already happened to you? Why is a time traveler speculating on the future?
      - thefounder 8y ago
        You don't need to be a time traveller to see that Apple will be the only one accepted as issuer. I really don't understand how people can feel comfortable with that. The next step is making the browsers trust only Apple's tls. At some point Apple will have to "obey the law" and ban any application that either violates certain country laws or its own TOS.
foobarbazetc 8y ago
Did anyone figure out how to just get a DMG or whatever created outside Xcode notarized? These docs are too Xcode focused.
- varenc 8y ago
  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 8y ago
    Xcode doesn't do anything special to your binary; you should be able to submit a valid codesigned application bundle AFAIK.
    - foobarbazetc 8y ago
      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 8y ago
        > 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.
  - xenadu02 8y ago
    xcrun just locates tools inside the current $DEVELOPER_DIR, which is inside the Xcode.app bundle (based on which Xcode is selected with xcode-select). You can think of xcode-select as virtualenv or similar systems: you select which version of the tools you want to use. Fun fact: If you symlink xcrun as a different name, it will assume that is the name of the tool you wish to run. So "ln -s /usr/bin/xcrun altool" will make altool an alias to run the version of altool bundled with the currently selected Xcode.
thefounder 8y ago
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 8y ago
  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 8y ago
    You didn't need a Apple developer account to sign the app if you used a 3rd party(i.e digicert) certificate/signer.
    - galad87 8y ago
      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 8y ago
        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
        8y ago
GeekyBear 8y ago
A pretty good blog summary of how this differs from past practice. https://eclecticlight.co/2018/09/24/has-that-app-been-notarized-and-what-are-the-benefits-to-the-user/ https://eclecticlight.co/2018/09/24/has-that-app-been-notari... 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 8y ago
  > You have to adopt the new OS user privacy protections. Don't you have to do this anyways?
makecheck 8y ago
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.
- Arqu 8y ago
  That works for "us" HN geeks. The consumer market is all about convenience, and the monent the custoners have to go through some hoops a new company will pop up that will do it as a service which they then trust for doing it properly. And while I'm all for decentralizing power, I'd rather have 1 accountable company or a couple of them handle this compared to a bunch of small independent ones consodering they are less auditable and more open to skewing the system. Maybe something like the W3 consortium but we know how that turned out...
  - darawk 8y ago
    True, but there need not be a convenience tradeoff. Make Apple the default signing authority, but make it configurable by the user. Normal users need not ever see it, but they retain an opt out if it ever becomes necessary.
tmymt 8y ago
What's the difference between this and Authenticode?
abcd_f 8y ago
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.
gamegod 8y ago
Remember that time Apple messed up and decided to punish all their app developers by forcing them to resign their apps?
garganzol 8y ago
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?
rgovostes 8y ago
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.

211 points by atarian 8y ago

bunnycorn 8y ago

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

jtbayly 8y ago
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 8y ago
  > 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.
- orf 8y ago
  They scan the software, not your software. If the hashed match against a known scanned good bit of software then it's safe. Maybe.
- deleted 8y ago
  [deleted]
- benatkin 8y ago
  The software is sent to Apple when it is notarized. When a user downloads and runs it, it is not sent to Apple. It just uses the hash. It would be pretty crazy for Mac OS to send the whole package to Apple to do a security scan, but a naive reader might think that.

mariopt 8y ago

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.

deleted 8y ago
[deleted]
lwansbrough 8y ago
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 8y ago
  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.
pducks32 8y ago
iOS does not involve sending your source code. This involves ensuring your app runs in their Hardened Runtime and is properly signed. Apple checks that there is no Malware.
djrogers 8y ago
> This is the standard practice in iOS apps. Pretty sure you’ve got your wires crossed here - you absolutely do not have to submit source code to put your app on the App Store.

sophiebits 8y ago

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 8y ago
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-mac-targeting-ransomware-hits-transmission-users-researchers-say/ https://arstechnica.com/information-technology/2016/03/first... [2] https://blog.malwarebytes.com/threat-analysis/2016/09/transmission-hijacked-again-to-spread-malware/ https://blog.malwarebytes.com/threat-analysis/2016/09/transm...
- mrpippy 8y ago
  Transmission’s Developer ID cert wasn’t compromised, the compromised binary was signed by a different developer.

jtokoph 8y ago

> 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 8y ago
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 8y ago
  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.)
  - Spivak 8y ago
    I mean RHEL Workstation is a very polished Linux environment. It might not be up to date enough for your needs but it's very stable and we'll documentated. Not the best for a laptop though. I would spring for Fedora or Ubuntu and deal with the lack of paid support for my own personal use but then again I've been using Linux for a while. Both options are perfectly stable desktops, it's really the commerical software support that will get you.
    - 8y ago

gergles 8y ago

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.

seandougall 8y ago
As others have pointed out, you already have to pay the tax to get a trusted signing certificate. So as far as the economics go, this isn’t a change.
- thefounder 8y ago
  It's actually a big change. One issue is that Apple may not approve you(for whatever reason) or keep you on the waitlist for weeks(happened to me). Not to mention that there won't be any competition. Next would be to make Safari and any browser running on osx accept only Apple tls certificates. That would be "awesome"! Finally Apple "secures" the internet
  - millstone 8y ago
    It's a big change because Apple may keep you on the waitlist for weeks, which already happened to you? Why is a time traveler speculating on the future?
    - thefounder 8y ago
      You don't need to be a time traveller to see that Apple will be the only one accepted as issuer. I really don't understand how people can feel comfortable with that. The next step is making the browsers trust only Apple's tls. At some point Apple will have to "obey the law" and ban any application that either violates certain country laws or its own TOS.

foobarbazetc 8y ago

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

varenc 8y ago
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 8y ago
  Xcode doesn't do anything special to your binary; you should be able to submit a valid codesigned application bundle AFAIK.
  - foobarbazetc 8y ago
    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 8y ago
      > 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.
- xenadu02 8y ago
  xcrun just locates tools inside the current $DEVELOPER_DIR, which is inside the Xcode.app bundle (based on which Xcode is selected with xcode-select). You can think of xcode-select as virtualenv or similar systems: you select which version of the tools you want to use. Fun fact: If you symlink xcrun as a different name, it will assume that is the name of the tool you wish to run. So "ln -s /usr/bin/xcrun altool" will make altool an alias to run the version of altool bundled with the currently selected Xcode.

thefounder 8y ago

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 8y ago
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 8y ago
  You didn't need a Apple developer account to sign the app if you used a 3rd party(i.e digicert) certificate/signer.
  - galad87 8y ago
    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 8y ago
      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
      - 8y ago

GeekyBear 8y ago

A pretty good blog summary of how this differs from past practice. https://eclecticlight.co/2018/09/24/has-that-app-been-notarized-and-what-are-the-benefits-to-the-user/ https://eclecticlight.co/2018/09/24/has-that-app-been-notari... 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 8y ago
> You have to adopt the new OS user privacy protections. Don't you have to do this anyways?

makecheck 8y ago

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.

Arqu 8y ago
That works for "us" HN geeks. The consumer market is all about convenience, and the monent the custoners have to go through some hoops a new company will pop up that will do it as a service which they then trust for doing it properly. And while I'm all for decentralizing power, I'd rather have 1 accountable company or a couple of them handle this compared to a bunch of small independent ones consodering they are less auditable and more open to skewing the system. Maybe something like the W3 consortium but we know how that turned out...
- darawk 8y ago
  True, but there need not be a convenience tradeoff. Make Apple the default signing authority, but make it configurable by the user. Normal users need not ever see it, but they retain an opt out if it ever becomes necessary.

tmymt 8y ago

What's the difference between this and Authenticode?

abcd_f 8y ago

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.

gamegod 8y ago

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

garganzol 8y ago

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?

rgovostes 8y ago

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.