> 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?
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.
> 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?
> 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.