notarization needs for build pipeline

> I want to automated notarization as part of my build pipeilne

Notarization is intended to be the last step before distribution. It really shouldn't be part of the build pipeline at all.

> We need a web service, not a command line

Is the command line not working? Subscribing to a web service would be even more difficult.

> Today, I have to parse text on the return from the command line, and there is no spec on what will be returned

It supports XML output

> We need a notaration test endpoint

Notarization is Apple's server-side analysis. There is nothing stopping you from code signing with the hardened runtime and appropriate entitlements. If that build runs all of its tests, then you can proceed to notarization. You are essentially asking Apple to setup a code-signing validation service. You already have that. Granted, it does require the use of command line tools. Such is life.

Appreciate the tip regarding the undocumented support for xml output. I don't know how anyone discovered that; there is no mention of it that I can find at developer.apple.com. for those watching this thread, --output-format xml should be added to the command line. If you can find an official reference, that would be welcomed.

Regarding your view on it being a release process; you are certainly welcome to your opinion. Hundreds of other develpers I've spoken to are in the same camp as me.

I'm not sure the size and scope and complexity of the apps you build, but mine have dozens of 3rd party libraries, and 1000's of binaries, with multiple frameworks, such as React/Electron/Typescript/Java/Native code as within the same package. With 3rd parties being upgraded every week in our code base because of the constant identification of security issues, with 100's of developers actively working in the code base, baking these ship requirements into the 3rd party acceptance pipeline and then our build pipeline is a must.

As an example, I have a jar file that has hundreds of jar files within it. Some of those jar files happen to have native binaries that require signing within them. Only through submitting for notarization did we discover that there are actually native binaries inside some jars, and that some of them are unsigned.

It is completely unreasonable to expect every enterprise app company to attempt to do what notarization does in their build pipeline.

So I want to expand upon why this is critically important, as notarization does far more than simply check for codesigning.

• It checks the SDK version
• It checks for secure time stamp
• It checks for malware
• It checks for runtime hardening
• And yes, it checks for codesigning
• It also walks every compressed file, such as jars, and jars within jars, and even jars within jars within jars, to search for any code files.

It's not as simple as just signing/hardening my build and running tests, and if everything passed, I just notarize it.

As indicated, complex apps use dozens of 3rd party libraries. I could sign/harden everything, run tests and pass, and absolutly fail notarization because of a 3rd party library that doesn't meet one of the requirements above.

The simplest way to do that is of course to submit it for notariation. But do I actually want to create a notarization record for that 3rd party using my credentials? Uh, no.

Do I want to wait until I'm ready to release before I discover that a 3rd party library I rely upon that I took a security fix is missing codesigning?

Or that is has some identified malware?

Or they had a regression in their pipeline and it isn't built against the correct SDK?

No.

As I said, it is really unreasonable if Apple expects every enterprise developer to build an internal system that attempts to do what notarization does.

> undocumented support for xml output. I don't know how anyone discovered that; there is no mention of it that I can find at developer.apple.com. for those watching this thread, --output-format xml should be added to the command line. If you can find an official reference, that would be welcomed.

Undocumented? Run "xcrun altool --help" or "man altool"

> Hundreds of other develpers I've spoken to are in the same camp as me.

Hundreds, eh?

> I'm not sure the size and scope and complexity of the apps you build

hehehe...and you never will. 😉

> It is completely unreasonable to expect every enterprise app company to attempt to do what notarization does in their build pipeline.

Yes, exactly. That's why notarization shouldn't be there.

> do I actually want to create a notarization record for that 3rd party using my credentials? Uh, no.

It's Apple, not Virus Total. Your notarization failures aren't made public. You don't have to worry about self-taught "internet security researchers" using your Notarization submissions in their libel campaigns against your company.

> Do I want to wait until I'm ready to release before I discover that a 3rd party library I rely upon that I took a security fix is missing codesigning?

You should probably review how codesigning works and perhaps how your bundles are being constructed. You should be re-signing the entire bundle as part of your Notarization process. But the hardened runtime is a requirement for Notarization. Testing the hardened runtime is something that should have already happened. Notarization is not necessary for that.

> Or that is has some identified malware?

> Or they had a regression in their pipeline and it isn't built against the correct SDK?

> No.

> As I said, it is really unreasonable if Apple expects every enterprise developer to build an internal system that attempts to do what notarization does.

Notarization is not a service for developers. It is a requirement. It is part of Apple's overall platform security that it provides to its users. If you think there is a serious risk that malware is going to infect your systems and only be detected by Notarization, then Notarization is the least of your problems. The same is true for 3rd party products that are unreliable but you have nevertheless integrated into your system without proper testing.

Notarization is only ever triggered by a download that attaches quarantine attributes to a file. Until you get to that point, then you don't need it. You should be testing your software internally before distributing it to the general public. It is your own responsibility to scan your network for malware. It would be a shame if Windows users learned that Apple's Notarization was your only company's only malware check.

All that being said, if you still want to integrate Notarization into your build pipeline, then do it. It isn't difficult. It is many times easier than anything you've said about your existing build pipeline. To return to your original questions... A command line tool with documented XML output is not difficult to use. I really don't see the point of demanding an interface that is more difficult to use. As far as a test endpoint goes, you can always create an additional developer account and use it just for testing notarization. Given your concerns about malware infecting your build pipeline, it would probably be a good idea to keep your public-facing credentials on a separate, locked-down network.

I'm not sure why you latched on to malware. I didn't say that I had a concern with my companies scanning or other network security policies. I said that notarization also scans for malware. And I said that ingesting any 3rd party library could cause your package to be un-notarizable for one of 6 different reasons.

How exactly would you test an open source 3rd party component like Electron for code-signing, or that it meets minimum SDK requirements, or is hardened? Did you write code for your build pipeline that does that before you upgraded to the latest version?

My point is that apple has done that. They've built the tooling that does exactly that; except that I don't want to notarize a 3rd party; my security team says using my companies credentials for signing their code is muy no bueno.

Apple has conflated the testing of an app to meet notarization requirements with the actual notarization. If you give a release requirement, great, I want to meet that requirement, but give me a way to test for that requirement before I release.

I'm not sure why you latched on to malware.

You were the one who brought it up, twice. And you mentioned that, prior to Notarization, you were distributing 3rd party executables that you didn't know about. So, yeah, your mentioning malware twice and distributing unknown binaries did make me think about malware. Guilty as charged.

How exactly would you test an open source 3rd party component like Electron for code-signing, or that it meets minimum SDK requirements, or is hardened? Did you write code for your build pipeline that does that before you upgraded to the latest version?

It sounds like you are talking about build flags. It doesn't matter, at all, whether or not your 3rd party open source software is hardened or not. You apply that flag when you do the code signing. What matters is whether it works, and works correctly, with said hardened runtime. Most things work fine, but some funky things don't. You have to functionally test the software first. That's not what notarization is about.

I don't want to notarize a 3rd party; my security team says using my companies credentials for signing their code is muy no bueno.

You are the one distributing the software. It is your responsibility. I'm not saying your security team is wrong. It sounds like they don't want to stamp their seal of approval on all of this software that, in some cases, you don't even know about. I can't say I blame them for that.

Apple has conflated the testing of an app to meet notarization requirements with the actual notarization.

No. You are the one who did that. If you don't like Apple's platform or security requirements, you are under no compulsion whatsoever to build for that platform.

1. Use "altool" to notarize and check notarization status. There is an option for the tool to output XML as its results. This is an XML Property List that has a well-documented format and should be parseable easily.
2. Use "spctl" to verify notarization results and check the process' error level returned.

I've put together a shell script implementing the full packaging and notarization flow. You can directly integrate this into a pre-existing build system or modify as needed. Have a look at the script to see how to parse notarization tools' results.