Notarizing App for macOS Catalina
 

Hi Kovid,
I assume you have received the same emails from Apple Developer Relations about the need to submit your app to Apple to be "notarized". Once version just notarizes an app as is while another requires you to relink with their new secure runtime and add info of what types of access is approved (files, folders, features,etc) and to get back a ticket to "staple" to your signed app.

The entire process seems to rely on using XCode and I can not find docs for simple command-line tools (yet) so that the process can be automated. I am a bit leery of giving Apple approval power over my app. I have been signing code long enough that these do not immediately effect Sigil but they will eventually.

What are your thoughts and plans for Calibre in this regard.

Thanks,

KevinH

I haven't received the emails, but I am aware of notarization. I have been signing calibre for several years now, so at least to start with, it should be fine. I am actually in the process of updating calibre's build pipeline, so on macOS it now builds on Mojave, which I think is a pre-requisite for getting notarization to work.

I too do not like giving apple any kind of "approval" over calibre. They suffer from extreme naivety if they think that they can successfully detect malware in an automated fashion. Probably just a trojan horse for extending more control over third party software.

That said, in the long term I dont really see an alternative, if you want to continue using their platform, you will have to play by their rules. macOS users are ~15% of calibre users, so I dont feel comfortable just abandoning them. At least to start with I plan to continue without notarizing and see how the situation evolves, let other people figure out how to notarize in an automated fashion. Automated signing via ssh is already unnecessarily difficult, so I doubt notarization will be straightforward. This is code needed to get automated signing via ssh to work, absurdly complex: https://github.com/kovidgoyal/calibr...os/sign.py#L29

I am definitely not using their "secure runtime". It is completely unsuited to an application of calibre's power and complexity.

I think that is a good plan. I will keep paying my $100 to keep my developer id and keep signing but not notarize until it is actually an issue and people have figured out how to automate the process via command line tools.

Thanks,

KevinH

Just FYI you dont need to pay $100 every year, only in th eyear you need ot renew the certificate.

They automatically charge me a renewal fee direct to my credit card each year in February. I will look into that.

Here is code to notarize via command line:

https://blog.zeplin.io/dev-journal-a...s-94b0b144ba9d

The process seems not too bad, however, the main problem is the indeterminate amount of time one needs to wait for notarization to complete. This is going to make automated building unneccessarily slow.

According to this, notarization time is typically between 2 and 24 mins https://eclecticlight.co/2019/06/29/...ions-analysed/

except when the service goes down, which will likely happen a lot more once notariztion becomes compulsory and therefore more heavily used.

Thanks for the link. The problem is acording to the docs on Apple's website, in order to pass notorization in the immediate future you must timestamp and use Apple's hardened runtime with a list of requested exceptions. Things like JIT, access to video, photos, allowing use dylib load library environment vars, etc, etc.

For that process you need to create an exceptions plist file (or whatever they call it) that needs to somewhere/somehow be included in the build/signing process. I still haven't found the command line docs that talk about these capabilities/exceptions file format and where in the process they are injected.

So it is really the hardened runtime requirement that is giving me issues. Early on they will allow you to notarize legacy builds without the hardened runtime but their website clearly states it is required.

Well yeah, if they require hardened runtime for notarization and require notariztion for all apps, then basically macOS is dead in the water.

I looked into the hardened runtime a bit and it looks like most things can be turned off. For example, firefox is building with it according to this: https://bugzilla.mozilla.org/show_bug.cgi?id=1470597

Here is the firefox entitlements file:

https://d3kxowhw4s8amj.cloudfront.ne...7a/D27396.diff


Basically looks like adding that entitlements file and calling codesign with it should be all that's needed (and adding the enable hardened runtime flag to Infoplist)

But I have to say, Aple's documentation is horrenduous.

You have to pay Apple $100 in order to develop apps for the Mac?

What are the fees for developing apps for Windows? I'm guessing you need to buy Visual C# or whatever.

Microsofts compilers have been free for a few years now. There is a "Visual Studio Community Edition" you can use. You do have to pay for authenticode certificates, but you dont pay microsoft, you pay third party certificate vendors.

Yes, that should help. At least it shows what an entitlements file needs to look like and which exception setting a webkit/webengine based viewer might need to use, and where it goes in the signing process.

You are right, Apple's mac developer docs are bad and especially are horrible for anyone wanting to automate the process and not use XCode.

I am still unsure what exceptions are needed to embed an entire Python 3.7 interpreter inside our app, and how external python modules/packages will be viewed that are not signed, how pure python plugins are treated if not signed, etc. What about python byte code and bytecode caches being written to places inside the app. Their current docs seem set for simple do one thing apps.

Thanks again for the links. They will be a big help.

Why not just declare you need everything possible, just in case?

...

If you're not actually buying into Apple's security guidelines, then your only goal is to shut up the complaints, so you don't actually care if the program is being "too permissive".

I will take that approach for Sigil's first attempt at notarization and the hardened runtime. If it still interferes with the embedded python interpreter and plugins, then at least I will know Eigil did everything it could.