It’s so frustrating that automation and command-line is treated as almost second-class citizenship on macOS.
You know how I log into a remote server securely without ever entering my password? I enter the command "ssh" and the server name. Why the hell isn’t notarization implemented, effectively, as "notarize appname.app" where all the details are resolved securely, just as magically, to your developer keys?
Yet if you upload something to the App Store, you understand Apple’s backwards mindset completely. The whole concept of a 6-step wizard that you have to CLICK through, EVERY time, for EVERY update, confirming stupid little things that should be in a config file, means that Apple has no idea how this stuff really ought to work. And that means that Apple must not use this themselves. They have to have some secret, simple, tolerable process internally which is why they never improve the tools that literally everyone else must put up with.
Shameless plug: I created xcnotary [1] to make command line notarization quite a bit less painful. It will poll the service and block for completion, return a non-zero failure code for CI, and will even audit your app for some common code signing issues prior to uploading it to Apple.
Shameless plug of my own: Last month I shared a post sharing a few thoughts on secure software redistribution, notarization, safe updates, and so on: https://henvic.dev/posts/cs-security/
> It’s so frustrating that automation and command-line is treated as almost second-class citizenship on macOS.
Sure, they're horrible, but I look at it as Apple generously creating jobs for engineers. I had a full-time job as a build engineer specializing in navigating the Lovecraftian nightmare of iOS build automation. Sure, they could've made it easy, but instead they chose to help transfer large sums of money from my family-friendly multinational megacorp employer to me. I returned the favor by using some of that money to buy their products.
This is a hilariously weird response to a valid criticism.
"Yeah, internet-outages are horrible. And sure, AT&T could fix that. But instead they chose to help people to disconnect from time to time and focus more on their families, which is overall the biggest contribution a company can make to society and should be rewarded by buying more of their services"
I keep seeing this kind of other-worldly self-defense only related to Apple. Positioning a brand as an element of the users' personal identity is truly an impressive thing...
A year or so back I wrote a little ffmpeg concatenation helper to make a friend's life easier. It was an OK shell script but it needed a config file to list all of the files that needed concatenation, and I wanted to just make a GUI that would let her add and reorder files to a list, then generate a temp file with the list (ffmpeg required the list to live in a file for some reason) and fire off the ffmpeg command to concatenate them both with and without sound.
This is apparently like a DEFCON 0 type operation to perform on a Mac requiring two guys in white lab coats to turn keys at the same time at opposite ends of the room, because there was no way to even ask for the permission to run the command if I remember right. It ended up being a case where I would be spending a ton of time to get more functionality than the command line script, so I quit. Plus it was one of those one plane ride projects.
Unless you wanted to submit this to the Mac App Store, you could have just turned off sandboxing. With that off, the only permission required would be Catalina’s permission dialogs when any app first accesses various folders (Documents, etc.), and those are automatic without needing any code in the app to request them.
I thought I could locally, but it crashed on her machine which makes me think I did it wrong. I could have kept at it but I think one debugging session on her computer would have wiped out any time savings she would have realized.
Exactly! The primary purpose of the `altool` for notarization is probably to do so in an automated manner, but it will not block while waiting for notarization. So to make this part of automation, nearly every developer needed to add polling loops and parse the response to figure out if it was done! The proper text to wait on also isn't obvious nor documented; if the status says "Package Approved" it may not even be complete yet.
Further, the first version would write status to standard error. Clearly a mistake, Apple did fix this in a future version... which of course broke everyone's automation around it. My polling script now logs the tool's stdout and stderr just in case.
No, it's one well documented command line tool called signtool. I've used it quite extensively and it has never failed me in an unexpected way.
I can't report much good about the Apple signing side. In the end we put that into a VM because different xcode versions will produce vastly different signatures for no obvious reason, and the older ones were more widely compatible.
You know how I log into a remote server securely without ever entering my password? I enter the command "ssh" and the server name. Why the hell isn’t notarization implemented, effectively, as "notarize appname.app" where all the details are resolved securely, just as magically, to your developer keys?
Yet if you upload something to the App Store, you understand Apple’s backwards mindset completely. The whole concept of a 6-step wizard that you have to CLICK through, EVERY time, for EVERY update, confirming stupid little things that should be in a config file, means that Apple has no idea how this stuff really ought to work. And that means that Apple must not use this themselves. They have to have some secret, simple, tolerable process internally which is why they never improve the tools that literally everyone else must put up with.