RapidWeaver 8.x sandboxing issue on Mojave

I’m posting this here as it likely affects plugin development more than anything.

Starting in Mojave, sandboxed applications which send Apple Events (i.e. use AppleScript) must provide a human-readable explanation of its use. This is to better provide context when the system shows dialogues which are used to obtain user consent, and without it, the prompt will never be shown (and all Apple Events will fail). This doesn’t affect users running previous versions of macOS because this “hardened” security practice is not in place.

The solution is pretty simple: apps need to add a value for NSAppleEventsUsageDescription in their Info.plist. This can be done without any modifications to code, and its value can be pretty generic (i.e. Some RapidWeaver plugins use AppleScript to function.) This value is only read when a plugin actually tries to send Apple Events, and is only shown once if they do. It’s very unintrusive.

Would it be possible for this to be added to the next minor update for RapidWeaver?

I’m afraid I can’t create a truly engaging addon for Emporter.app if I’m not able to share data between Emporter and RapidWeaver.

Thanks!

(cc @tpbradley @dan)

1 Like

Hey @mikey

No probs, I’ll get that into the next release.

Cheers!

Thank you so much! I can’t wait to show you what I’ve been cooking :smile:

Awesome, looking forward to it :+1::tada:

Hey @dan and @tpbradley,

I created a sandboxed application this afternoon to see if there was anything else that might need to be configured to make Emporter and RapidWeaver become best friends and I found another issue. I’m starting to really feel like a diva… :pensive:

In short, a new entitlement would need to be added to allow RapidWeaver to script Emporter. There’s a section about this in Apple’s Documentation Archive, aptly named Enabling Scripting of Other Apps.

Would this be something you’d be willing to add?

If so, please let me know so I can add the proper access groups to Emporter so we can follow their best practices… we might even earn a few gold stars from Apple. :star_struck:

I haven’t run into these issues before because the integrations I’ve made have been for apps that live outside the sandbox… I’m sorry for the hassle.

Thanks!

Edit: If there’s anything I can do to help keep this painless on your end, please let me know. I’d be happy to send you an example plugin bundle to assert the behavior

Hey Mike,

That sounds fine to me, let me know what key/access groups you want and I’ll add it in.

Cheers

1 Like

Awesome! I’ll update Emporter’s scripting definition to use access groups and push an update to the App Store. I’ll first get it working in my sandboxed playground and let you know the keys… I expect I’ll be able to do this by tomorrow.

Thank you!

Hey Tom,

I managed to get it working after some blood, sweat and tears. I’m not sure which is worse: the Apple Scripting API or the AWS APIs :upside_down_face:

I’ll need to publish a new version of Emporter on App Store Connect before it will work for release builds, but here’s what a simple entitlements plist would look like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.scripting-targets</key>
	<dict>
		<key>net.youngdynasty.emporter.mas</key>
		<array>
			<string>net.youngdynasty.emporter.external-app</string>
		</array>
	</dict>
</dict>
</plist>

I’ve been able to use these entitlements locally without a problem. I don’t think we’ll have to worry about “temporary entitlements” as long as the new version of Emporter is live before the next minor update to RW.

I’ll go ahead and take care of this by next week at the latest, but if you had a beta planned I can rush it out. I seem to have some luck with the review team and I usually get an approval within 24 hours.

Have a good weekend!

1 Like

There’s a new build of 8.2.1 out with support for plugins to access Apps Events. Give it a whirl!

@tpbradley has all the details on this if you need more!

Thanks @dan! Unfortunately, it still doesn’t quite work because of the other entitlements needed (see above). I inspected the entitlements of the 8.2.1 build and it looks like those extra bits aren’t there yet.

I may have been too late to the party :slight_smile:

Thanks!

Hey @tpbradley, do you know when you might have a chance to add those extra entitlements? I’m actually stuck without them, but I know you must have more pressing things in your pipeline. No rush, just wanted to follow up with you!

Yes! We’re literally about to release the RW8.3 beta with the entitlements - watch this space

1 Like

@mikey here you go! http://forums.realmacsoftware.com/t/rapidweaver-8-3-20766b-developer-alpha/27178/2

1 Like

@dan @tpbradley Thanks for the quick turn around! It seems to be working. Yay!

1 Like

@dan @tpbradley Hey guys, I may have spoke too soon… it seems like there’s one more entitlement to add before we’re good to go: the Apple Events Entitlement.

If I understand correctly, the specifics we added earlier are only used if com.apple.security.automation.apple-events is true and there’s a value for NSAppleEventsUsageDescription in the Info.plist file for RapidWeaver. It seems like the Apple Events Entitlement is the only thing missing.

I’m sorry for the hassle. I haven’t come across these issues myself because my code signing certificates match my own apps.

Please let me know if there’s anything I can do to help… the plugin is so close to being ready! DM me if you want me to send you a debug build to help chase down the last issue.

Cheers

@mikey yup, we’re on it. We’ll get it added to 8.3 - due for release next week (hopefully).

Could you email a debug build to tom@realmacsoftware.com and dan@realmacsoftware.com :+1:

Cheers
Dan

I’ve DMed you guys so I can setup provisioning profiles for the debug builds. I’ll email you copies once I’m able to add your Macs to the device list!