FSKit AppEx continious integration

Hi!

I'm developing an FSKit module and experiencing some troubles with test harness automation:

  • Registering an FSKit AppEx requires user intervention by clicking through a GUI.
  • Re-deploying a new build signed with a local certificate involves the same roundabout to re-toggle the registered AppEx in the Settings.

Are there any plans to improve developer experience in this regard?

Answered by DTS Engineer in 893509022

Are there any plans to improve developer experience in this regard?

I can't discuss our future plans; however, I will note that there are significant privacy and security concerns with most app extensions, and that's particularly true of a complex and powerful extension point like FSKit.

The Pluginkit command-line tool does provide some visibility into what's happening in the system, but that's the extent of what's currently available.

Having said that, I do have one comment here:

Re-deploying a new build signed with a local certificate involves the same roundabout process to re-toggle the registered AppEx in the Settings.

Are you referring to the "Sign to Run Locally"? If so, then the issue here is that local signing doesn't maintain a proper "relationship" between builds, so the system is forcing you to approve the build again because it appears to be an entirely "different" app. I don't think this will happen if you're using one of our signing methods. In that case, the system should treat the new build replacing the old build the same way it would treat any other app update.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Are there any plans to improve developer experience in this regard?

I can't discuss our future plans; however, I will note that there are significant privacy and security concerns with most app extensions, and that's particularly true of a complex and powerful extension point like FSKit.

The Pluginkit command-line tool does provide some visibility into what's happening in the system, but that's the extent of what's currently available.

Having said that, I do have one comment here:

Re-deploying a new build signed with a local certificate involves the same roundabout process to re-toggle the registered AppEx in the Settings.

Are you referring to the "Sign to Run Locally"? If so, then the issue here is that local signing doesn't maintain a proper "relationship" between builds, so the system is forcing you to approve the build again because it appears to be an entirely "different" app. I don't think this will happen if you're using one of our signing methods. In that case, the system should treat the new build replacing the old build the same way it would treat any other app update.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Are you referring to the "Sign to Run Locally"? If so, then the issue here is that local signing doesn't maintain a proper "relationship" between builds, so the system is forcing you to approve the build again because it appears to be an entirely "different" app.

I'm using a custom build system, not XCode, so the build pipeline calls codesign manually for ad-hoc signing.

I don't think this will happen if you're using one of our signing methods. In that case, the system should treat the new build replacing the old build the same way it would treat any other app update.

It's good to know, thanks! However, this approach still involves user interaction, which is not really suitable for a stateless CI executor...

I'm using a custom build system, not XCode, so the build pipeline calls codesign manually for ad-hoc signing.

You can use our certificate with codesign as well. This forum post describes the process for DEXT, but the process is basically identical for any extension (like FSKit).

However, this approach still involves user interaction

It's possible to configure things such that user intervention is required. That does have security implications (since the key can sign as "you"), however, if you generate a custom provisioning profile and development signing, you can reduce those risks.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

FSKit AppEx continious integration
 
 
Q