macOS 10.15 requires notarized apps

[dlangBugzillaToGithub]

Jacob Carlborg (@jacob-carlborg) reported this on 2019-08-12T11:21:02Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=20124

CC List

• ponce
• Vladimir Panteleev (@CyberShadow)
• Nicholas Wilson
• Iain Buclaw (@ibuclaw)

Description

On the latest version of macOS, Catalina (10.15), currently in beta, it's required that all applications are notarized. This includes command line applications and installers. If an application is not notarized the application will not run and a dialog opens. It's possible to start the application anyway by going into System Preferences and launch the application. But it's a pretty poor user experience. This applies not to just DMD but all executables that are shipped with in the archive and the installer itself.

To notarized an application it needs to be signed with a Developer ID certificate and the application needs to adopt the Hardened runtime [1].

A Developer ID costs 99 USD per year. Nonprofit organizations may get the fee waived [2].

[1] https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
[2] https://developer.apple.com/support/membership-fee-waiver/

!!!There are attachements in the bugzilla issue that have not been copied over!!!

[dlangBugzillaToGithub]

aliloko commented on 2019-08-12T22:01:37Z

Created attachment 1759
Notarization script

Here is a script app developers share in my domain. I've not used it yet.

From what I heard, notarization apparently must be applied to a complete redistributable (such as a ZIP file). It will notarize in a "deep" manner what it founds.

One of the (few?) advantages is that notarization will warn about errors with code signing. 
Code-signing for macOS is just $99/year and relatively easy.

[dlangBugzillaToGithub]

iamthewilsonator commented on 2019-08-13T01:08:41Z

I guess this will affect LDC & GDC too.

[dlangBugzillaToGithub]

doob (@jacob-carlborg) commented on 2019-08-13T09:04:56Z

(In reply to Nicholas Wilson from comment #2)
> I guess this will affect LDC & GDC too.

Not just LDC and GDC. Basically any application out there. RDMD, Dub, digger and so on.

[dlangBugzillaToGithub]

ibuclaw (@ibuclaw) commented on 2019-08-13T09:09:24Z

Will this affect OSX ports in any way?

[dlangBugzillaToGithub]

iamthewilsonator commented on 2019-08-13T09:12:11Z

RDMD, Dub, digger et al, are all distributed with DMD. LDC and GDC aren't.

[dlangBugzillaToGithub]

doob (@jacob-carlborg) commented on 2019-08-13T09:14:59Z

(In reply to Iain Buclaw from comment #4)
> Will this affect OSX ports in any way?

What exactly do you mean with "ports"?

[dlangBugzillaToGithub]

ibuclaw (@ibuclaw) commented on 2019-08-13T09:20:36Z

https://www.macports.org/(In reply to Jacob Carlborg from comment #6)
> (In reply to Iain Buclaw from comment #4)
> > Will this affect OSX ports in any way?
> 
> What exactly do you mean with "ports"?

https://www.macports.org/

[dlangBugzillaToGithub]

doob (@jacob-carlborg) commented on 2019-08-13T10:06:49Z

I looked into this a bit more. It looks like the OS (in this version at least) only checks applications with the quarantined flag. That's an extended attribute which is set when downloading a file using a browser (tested with Safari and Chrome). When I download the same file using "curl", it's not set. So that's not as bad as I thought it was.

I still think this needs to be done though.

[dlangBugzillaToGithub]

dlang-bugzilla (@CyberShadow) commented on 2019-08-14T21:12:09Z

(In reply to Jacob Carlborg from comment #0)
> On the latest version of macOS, Catalina (10.15), currently in beta, it's
> required that all applications are notarized. This includes command line
> applications and installers.

(In reply to Jacob Carlborg from comment #8)
> I looked into this a bit more. It looks like the OS (in this version at
> least) only checks applications with the quarantined flag.

I was about to say, that sounded strange, as based on your initial description, it would also apply to executables *produced* by the compiler, making it thus impossible to use any compiler on such a system. Presumably there would be a developer mode that someone could enable to run non-notarized programs, but then, this would also apply to the compiler itself, making it unnecessary to notarize.

We already do code signing for Windows, so if the foundation has the money to spare and the release manager can fit this into their flow, I guess "why not".

> That's an
> extended attribute which is set when downloading a file using a browser
> (tested with Safari and Chrome). When I download the same file using "curl",
> it's not set. So that's not as bad as I thought it was.

BTW, Windows and Free Desktop platforms (Linux/FreeBSD) have this too. On Windows it's in the :Zone.Identifier:$DATA alternate NTFS stream, and on Free Desktop, it's the user.xdg.referrer.url extended attribute.