[galad87]

I wrote a little sh script to notarize HandBrake two (or maybe three) years ago, and that's was it. It's not rocket science. But like every new thing, it required a bit of time to read the documentation and to understand what's going on.

The plugin issue described in the article is probably related to the hardened runtime, so it's unrelated to the actual notarisation process.

[lunixbochs]

This is my notary script for a DMG: https://gist.github.com/lunixbochs/0ceeb23be5c3d5c6748165e61...

   ./notary.sh notarize app.dmg
   ./notary.sh staple app.dmg

I store a password as a keychain entry named AC_PASSWORD. If you're running this in headless CI you should run a notarize command once interactively so you can tell keychain to always allow altool to access the password.

[Klonoar]

You can also opt to use API keys from Apple Connect in CI, which is what I do - less of a headache with Keychain.app.

[sorbits]

While you only have to update your build process once, you now have a noticeable delay for every single release build, and worse, a few times per year, your build will break because you haven’t signed Apple’s latest contract.

And for what? There is no way Apple can make it impossible to get malware notarized.

[Klonoar]

But your release build is not done constantly, and so you have to sign in and accept an agreement - neither of which is a big deal.

[hansvm]

> But your release build is not done constantly

Some people (are they the minority? probably?) cut release builds frequently enough for it to be a big pain point.

> and so you have to sign in and accept an agreement - [which isn't] a big deal

It probably is though. Have _any_ agreements you've accepted in the last, say, 5yrs not had blatantly overbearing or malicious terms?

[Klonoar]

If you're cutting release builds often enough that the extra minute or two is hampering your productivity, you may have bigger issues with software development.

[sorbits]

For me, it is generally > 2 minutes, and “release build” cover any build that leave your machine, e.g. nightly builds, beta builds, test builds to a specific user to track down some issue, etc.

Signing the agreement is also not just clicking “Agree”, you have to hunt for the contract online first. Last time I did this, their 2FA was down, so just logging in took me about a minute.

It feels like a lot of friction that serves absolutely no purpose, which makes it so extremely infuriating.

This is from the same company whose former CEO pressured a developer to reduce the boot time of the Macintosh (and got a 28 second speedup).

Yes, this stuff really matters to a lot of us!

[Applejinx]

I got all the Airwindows audio unit plugins notarized in about a week (that's several hundred distinct plugins), and used third party apps to do it (DropDMG and SD Notary)

The trouble I ran into was this: Apple wants the process to be a little mystifying as a barrier to people trying to find exploits within it, I think. I disagree: for instance, using a shell script and the Apple terminal tools is very much the Apple-intended approach, but integrating the third party tool got me sending code to Apple's servers quicker, and it's those servers that matter. I wasn't considered a significant developer to Apple, nor will I ever be, but I code open source software that's being adopted by other projects and used as an on-ramp for would-be DSP coders: my choices and attitudes matter.

Apple in the form of a key Gatekeeper dev had very specific intentions for me: I was strongly advised to use automatic code signing in XCode and use Terminal and a separate workflow to remove the incorrect cert that Xcode assigns, and put in the correct one (Developer ID Application, in this case).

Apple's defaults for an XCode application (written in Swift, because of course it is) and automatic signing, work perfectly first time for something like their example 'hello world' app. For any Audio Unit, this fails every time. You can set it correctly inside XCode from the start, using manual settings. I chose to do this.

Near as I can tell, I am expected to have a manager to whom I will turn over code, and who is the only one with a code signing ID, because as a lowly DSP coder I'm not expected to be allowed to put code out into the wild without supervision. There's a clear expectation that if I mattered, I'd either be the boss of (not necessarily trustworthy) coders, or I'd have a boss whose job it is to be more trustworthy and oversee my code in case I have a wild hair some day and code a bomb into things. I feel there's a resistance at Apple to putting the keys to distribution into the hands of untrustworthy people. Perhaps a belt and suspenders approach? I'm not convinced this is in any way a good thing, though.

Doing the code signing correctly, which is not the same thing as having an Apple-specified process, means every bit of code I generate gets checked for malware by an Apple process. This could save my butt if I got owned by some extremely clever second-level malware that tried to commandeer my XCode and build malware into everything I make. I get that there are also possible risks with having every executable sent to the mothership to be studied: if I competed with them, that's wildly anticompetitive and lets them decompile and pirate anything I do (given sufficient effort). I'm literally sending them all my work before anybody else ever runs it.

I feel that this type of risk (which I'm not convinced is a currently active threat) is better handled by government, regulation, and the law, than by forcing the software ecosystem to normalize running any old code from anywhere.

Doing Apple notarization the way Apple wants it done, should be a nontrivial factor in keeping Apple products from being a giant pile of malware, spyware, and user-manipulation in future. If you're able to do it properly (as in, get the code AUDITED, not 'do it only the way Apple says') the result is distributed plugins and applications that 'just work' the way they used to, but without the same level of risk to the end user.

I think it's worth the trouble to do this. The benefit is clear, and possible dangers of the approach belong to the legal sphere rather than being a technical reason to avoid code signing, or normalize having everybody avoid code signing on your behalf.

[tinus_hn]

Avoiding the type of malware that’s self encrypting and mutating to avoid detection seems like a significant goal. I don’t know if Gatekeeper achieves it though.