Bug 20124 – macOS 10.15 requires notarized apps

Status
NEW
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Mac OS X
Creation time
2019-08-12T11:21:02Z
Last change time
2024-12-13T19:04:52Z
Assigned to
No Owner
Creator
Jacob Carlborg
Moved to GitHub: dmd#19607 →

Attachments

IDFilenameSummaryContent-TypeSize
1759notarise.shNotarization scriptapplication/x-shellscript4581

Comments

Comment #0 by doob — 2019-08-12T11:21:02Z
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/
Comment #1 by aliloko — 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.
Comment #2 by iamthewilsonator — 2019-08-13T01:08:41Z
I guess this will affect LDC & GDC too.
Comment #3 by doob — 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.
Comment #4 by ibuclaw — 2019-08-13T09:09:24Z
Will this affect OSX ports in any way?
Comment #5 by iamthewilsonator — 2019-08-13T09:12:11Z
RDMD, Dub, digger et al, are all distributed with DMD. LDC and GDC aren't.
Comment #6 by doob — 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"?
Comment #7 by ibuclaw — 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/
Comment #8 by doob — 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.
Comment #9 by dlang-bugzilla — 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.
Comment #10 by robert.schadek — 2024-12-13T19:04:52Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19607 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB