I used to be a big security advocate, but this is not security. It just defines an additional, yet indirect effort by Apple to lock other players out of the app game. The only good news is that they have still provided a mechanism for the end user to turn the requirement of that “feature” off.
11 of our largest clients are seriously examining Windows and Linux for large scale Mac replacements for FY 19 just because of things like this compounding the issues that heir IT teams had to deal with in the moves to 10.11 and 10.13 already.
You can’t notarize your apps in XCode. The process described in the Twitter messages is horrible.
And you can’t notarize your apps anyways, because all of us need at least some time of backwards compatibility with older versions of macOS. You would need a special version of Xojo and of the plugins that use system functionality AFAIK. I’m not very deep into these topics but this is my understanding.
Yes and no. Yes, it’s “optional” right now. But with the 64bit warning we have seen again that Apple likes to scare users. Who knows what stupid message Apple will show to the users when the app is not notarized?
I’ve been paying attention from the sidelines on this new “security” mechanism, I don’t see that it will be enforced soon, I actually expected the App Sandbox to be enforced outside of the App Store by now.
Once the dust has settled and the complete process has been revealed, then I attempt to implement it into App Wrapper.
Here is what seems to have worked for me for a Xojo app distributed via a signed DMG.
Open the Application Loader developer tool in Xcode. Log in to your developer account and check the box to remember the login so a keychain entry is created. This allows you to skip entering your password in subsequent steps.
Code sign your app with the hardened runtime option (you may need entitlements if you are accessing any protected resources). For example:
[quote=400940:@Tim Jones]I used to be a big security advocate, but this is not security. It just defines an additional, yet indirect effort by Apple to lock other players out of the app game. The only good news is that they have still provided a mechanism for the end user to turn the requirement of that “feature” off.
11 of our largest clients are seriously examining Windows and Linux for large scale Mac replacements for FY 19 just because of things like this compounding the issues that heir IT teams had to deal with in the moves to 10.11 and 10.13 already.[/quote]
I know this is a necro’d thread, but here’s the deal with notarization. When you distribute through the app store, Apple scans your app for certain behaviors and automatically rejects before going to a human for review. The Developer ID program is good, but has no such protection. Malware can be signed and distributed outside the app store. Notarization combines the two. Users get the benefit of binaries that have been pre-scanned by Apple, while developers don’t have to distribute via the app store.
It’s not about locking anybody out. Well… except for malware developers.
[quote=410599:@Christoph De Vocht]Yeah, I also read it somewhere else. This is rumoured for macOS 10.14.1 , but my guess it will be for 10.14.2
Guess Sam has some work to do with AppWrapper. ;-)[/quote]
I don’t think that soon. 10.15 or 10.16 is more likely. There’s too many legacy apps to make the switch that quickly. You should start preparing your apps for the possibility, but it’s not “sound the alarm” stage yet.
[quote=410605:@Jeff Tullin]Sounds like a lot of work.
I have several commercial apps.
One comes in 3 flavours and a demo
I have been known to release an update per month.
7 notarisation sessions a month?
Only you can best decide how to adapt your strategy, but maybe it makes sense to consolidate where possible? Rather than that one app coming in 4 editions, maybe the differences get handled by licensing so you only need to make a single build per update? Just an idea.
If Apple is going down this path, then we have to adapt. That’ll be easier for some than others.