How is this sample intended to be used?

[amomchilov]

The README states:

As such this sample is not a template and is instead written in a modular way which should make it easy for you to add portions of this code to your project as desired.

This repo doesn't export a Swift package, so the only way I see to use it is to copy out chunks of code into our own projects. Is that the intention?

[jakaplan]

Yes that was the intention.

[amomchilov]

What do you think about library-ifying it (I would love to help with it)? There's a lot of great stuff here (the helper monitor, uninstaller), and I'm always a bit worried when I copy code (instead of using a package where I can be automatically notified of changes and apply updates/security fixes when necessary)

This sample also some really great detailed error-handling, that I think would be nice to build right into Blessed. However, it looks like it relies on the EmbeddedPropertyList package, which Blessed doesn't depend on (should it?).

[jakaplan]

I don't want to make this entire project a package (for example I don't think it'd make sense for AllowedCommand to be pulled into another project). I've already carved out large portions of this into the Blessed, SecureXPC, and EmbeddedPropertyList frameworks; I'm certainly open to converting more portions of this into one or more Swift frameworks.

[jakaplan]

This sample also some really great detailed error-handling

Do you mean the UI updates in the updateInstallationStatus function?

SwiftAuthorizationSample/SwiftAuthorizationApp/ViewController.swift

Lines 107 to 216 in 20795e9

	func updateInstallationStatus(_ status: HelperToolMonitor.InstallationStatus) {
	DispatchQueue.main.async {
	// 8 possible combinations of installation status
	if status.registeredWithLaunchd {
	if status.registrationPropertyListExists {
	// Registered: yes | Registration file: yes | Helper tool: yes
	if status.helperToolExists {
	self.installedField.stringValue = "Yes"
	if let installedVersion = status.helperToolBundleVersion,
	let bundledVersion = self.bundledHelperToolVersion {
	if bundledVersion > installedVersion {
	self.installOrUpdateButton.isEnabled = true
	self.installOrUpdateButton.title = "Update"
	self.installOrUpdateButton.action = #selector(ViewController.update)
	let tooltip = "Update to bundled helper tool version \(bundledVersion.rawValue)"
	self.installOrUpdateButton.toolTip = tooltip
	} else {
	self.installOrUpdateButton.isEnabled = false
	self.installOrUpdateButton.title = "Update"
	self.installOrUpdateButton.action = nil
	let tooltip = "Bundled helper tool version \(bundledVersion.rawValue) is not greater " +
	"than installed version"
	self.installOrUpdateButton.toolTip = tooltip
	}
	} else {
	self.installOrUpdateButton.title = "Install"
	self.installOrUpdateButton.action = #selector(ViewController.install)
	self.installOrUpdateButton.toolTip = nil
	}
	self.uninstallButton.isEnabled = true
	self.versionField.stringValue = status.helperToolBundleVersion?.rawValue ?? "unknown"
	self.runButton.isEnabled = true
	} else { // Registered: yes | Registration file: yes | Helper tool: no
	self.installedField.stringValue = "No (helper tool missing)"
	self.installOrUpdateButton.isEnabled = true
	self.installOrUpdateButton.title = "Install"
	self.installOrUpdateButton.action = #selector(ViewController.install)
	self.uninstallButton.isEnabled = false
	self.versionField.stringValue = "—"
	self.runButton.isEnabled = false
	}
	} else {
	// Registered: yes | Registration file: no | Helper tool: yes
	if status.helperToolExists {
	self.installedField.stringValue = "No (registration file missing)"
	self.installOrUpdateButton.isEnabled = true
	self.installOrUpdateButton.title = "Install"
	self.installOrUpdateButton.action = #selector(ViewController.install)
	self.installOrUpdateButton.toolTip = nil
	self.uninstallButton.isEnabled = false
	self.versionField.stringValue = status.helperToolBundleVersion?.rawValue ?? "unknown"
	self.runButton.isEnabled = false
	} else { // Registered: yes | Registration file: no | Helper tool: no
	self.installedField.stringValue = "No (helper tool and registration file missing)"
	self.installOrUpdateButton.isEnabled = true
	self.installOrUpdateButton.title = "Install"
	self.installOrUpdateButton.action = #selector(ViewController.install)
	self.installOrUpdateButton.toolTip = nil
	self.uninstallButton.isEnabled = false
	self.versionField.stringValue = "—"
	self.runButton.isEnabled = false
	}
	}
	} else {
	if status.registrationPropertyListExists {
	// Registered: no | Registration file: yes | Helper tool: yes
	if status.helperToolExists {
	self.installedField.stringValue = "No (helper tool and registration file exist)"
	self.installOrUpdateButton.isEnabled = true
	self.installOrUpdateButton.title = "Install"
	self.installOrUpdateButton.action = #selector(ViewController.install)
	self.installOrUpdateButton.toolTip = nil
	self.uninstallButton.isEnabled = false
	self.versionField.stringValue = status.helperToolBundleVersion?.rawValue ?? "unknown"
	self.runButton.isEnabled = false
	} else { // Registered: no | Registration file: yes | Helper tool: no
	self.installedField.stringValue = "No (registration file exists)"
	self.installOrUpdateButton.isEnabled = true
	self.installOrUpdateButton.title = "Install"
	self.installOrUpdateButton.action = #selector(ViewController.install)
	self.installOrUpdateButton.toolTip = nil
	self.uninstallButton.isEnabled = false
	self.versionField.stringValue = "—"
	self.runButton.isEnabled = false
	}
	} else {
	// Registered: no | Registration file: no | Helper tool: yes
	if status.helperToolExists {
	self.installedField.stringValue = "No (helper tool exists)"
	self.installOrUpdateButton.isEnabled = true
	self.installOrUpdateButton.title = "Install"
	self.installOrUpdateButton.action = #selector(ViewController.install)
	self.installOrUpdateButton.toolTip = nil
	self.uninstallButton.isEnabled = false
	self.versionField.stringValue = status.helperToolBundleVersion?.rawValue ?? "unknown"
	self.runButton.isEnabled = false
	} else { // Registered: no | Registration file: no | Helper tool: no
	self.installedField.stringValue = "No"
	self.installOrUpdateButton.isEnabled = true
	self.installOrUpdateButton.title = "Install"
	self.installOrUpdateButton.action = #selector(ViewController.install)
	self.installOrUpdateButton.toolTip = nil
	self.uninstallButton.isEnabled = false
	self.versionField.stringValue = "—"
	self.runButton.isEnabled = false
	}
	}
	}
	}
	}

[amomchilov]

Not a fan of that particular implementation style, but the general idea of a notification system for when the status of the connection (or the helper's installation status) is very useful, IMO.

I think this would fit well inside the Blessed package, but it as it stands today, it doesn't depend on EmbeddedPropertyList. What do you think about adding that dependency and adding status-related APIs to Blessed?

Imo without such features, using Blessed on its own feels like you're shooting blind-folded, with no way to check your work

[jakaplan]

What do you think about adding that dependency and adding status-related APIs to Blessed?

I do not want Blessed to have any dependencies beyond the macOS standard frameworks as it's only meant to be a Swift friendly wrapper around the Authorization Services and Service Management frameworks.

Imo without such features, using Blessed on its own feels like you're shooting blind-folded, with no way to check your work

I think it's equally as blind as using Authorization Services and Service Management frameworks directly.

The points you bring up are completely valid, but it's not the direction I want to take Blessed.

---

I have loose thoughts of publishing a framework called Unauthorized (actual name TBD) that'd make it easy to do many of the things the Authorization Services and Service Management frameworks no longer let you do with the non-deprecated API surface. It'd resemble what's being done here with a combination of file system monitoring and calling command lines tool as well as potentially invoking deprecated APIs. Essentially it'd exist as a "use at your own risk" companion to "Blessed".

[jeff-h]

I wholeheartedly agree with @amomchilov in #4 (reply in thread) — there's a lot of code in the sample which I have taken wholesale into my app, which makes me vaguely uneasy in terms of updates.

There's a bunch of code code for determining current state / installing / updating / uninstalling that I think will be in 100% of the use-cases I personally would have for these libraries.

@amomchilov have you had a chance yet to start a framework to achieve this? I'm unsure how much help I could be, but I'd certainly be willing to add another perspective if it's useful.

[amomchilov]

there's a lot of code in the sample which I have taken wholesale into my app, which makes me vaguely uneasy in terms of updates.

Same!

have you had a chance yet to start a framework to achieve this?

Kind of. When incorporating this into my app, I tried my best to keep this stuff in a separate directory that can be broken out into an SPM package. Unfortunately, there's a lot of code that ended up being tightly integrated.

I've become convinced that an umbrella wrapper framework is not the way to go. The reason being that a lot of my connection state monitoring code is intrusive into the handlers defined on the XPCClient. As a result, there's no real way to framework-arize that without essentially completely wrapping the SecureXPC APIs. This would be terrible because:

1. It would be a maintenance nightmare. All new features on the underlying SecureXPC implementation would need a corresponding change to the facade framework, to expose them.
2. It introduces a lot more closures an indirection, which could be a performance concern (at least in my use-case)
3. It's a leaky abstraction. The facade class would class the underlying XPCClient APIs, but all of this would just pollute user's stack traces, and generally make debugging and bug-reporting more difficult.

@jakaplan Having spent some time playing with this idea, I think I'd now totally recommend adding EmbeddedPropertyList as a dependency on Blessed, and integrating error-case-detection functionality directly into the framework. These packages are tiny, so I don't think there's much to be worried about as far as bloat and such.

If anything, this decreases (conceptual) bloat because EmbeddedPropertyList becomes a hidden implementation detail of Blessed. Whereas library users would otherwise need to explicitly import EmbeddedPropertyList and use it to detect issues in their mach service configuration, now they would just use Blessed and have it do this detection for them (hiding the existence of EmbeddedPropertyList).

How do you feel about this?

[jakaplan]

@jakaplan Having spent some time playing with this idea, I think I'd now totally recommend adding EmbeddedPropertyList as a dependency on Blessed, and integrating error-case-detection functionality directly into the framework. These packages are tiny, so I don't think there's much to be worried about as far as bloat and such.

When I last looked into this as part of the initial discussion, I wasn't enthused by the idea. My intention with Blessed was for it to be a "dumb" wrapper around the Authorization Services and Service Management frameworks that just makes them much friendly to use from Swift. The intention wasn't that Blessed was any better or worse than those frameworks aside from being Swift friendly.

I'm open to reevaluating this so long as the scope is essentially limited to generating more specifics errors than what's available in LaunchdError. I want to continue to keep Blessed a very focused library and also avoid any undocumented function calls or calling out to external processes like launchctl.

I don't have experience with publishing public Swift frameworks that depend on other frameworks. Do you know if the dependencies become publicly exposed to API users? I'd hope not unless explicitly re-exported in some manner.

If anything, this decreases (conceptual) bloat because EmbeddedPropertyList becomes a hidden implementation detail of Blessed. Whereas library users would otherwise need to explicitly import EmbeddedPropertyList and use it to detect issues in their mach service configuration, now they would just use Blessed and have it do this detection for them (hiding the existence of EmbeddedPropertyList).

This seems plausible in terms of improving error generation for Blessed; however, I do think direct use of this framework would be common. For example I suspect many application developers would want to directly use EmbeddedPropertyList to handle protocol versioning properly. Reading the version of the helper tool lets me know exactly what requests my helper tools are capable of handling and how they will handle them.

[amomchilov]

My intention with Blessed was for it to be a "dumb" wrapper around the Authorization Services and Service Management frameworks that just makes them much friendly to use from Swift. The intention wasn't that Blessed was any better or worse than those frameworks aside from being Swift friendly.

I'm open to reevaluating this so long as the scope is essentially limited to generating more specifics errors than what's available in LaunchdError. I want to continue to keep Blessed a very focused library and also avoid any undocumented function calls or calling out to external processes like launchctl.

Could I challenge you on this? I think it would be a real shame if it exposes a nice Swifty API that's pleasant to use, but is incomplete and requires 90% of API consumers to reinvent the same set of wheels (e.g. a lot of the code within this sample app).

Perhaps there should be opt-outs to allow people to opt out of excess file system IO, launchctl calls, etc. (if those turn out to be a performance concern for them), but I think the focus should be on covering on what most people would need most of the time, which I would certainly include launchctl-daemon-status-checking.

I don't have experience with publishing public Swift frameworks that depend on other frameworks. Do you know if the dependencies become publicly exposed to API users? I'd hope not unless explicitly re-exported in some manner.

The transitive dependencies aren't a total secret, e.g. they'll be pulled into a person's Package.resolved file, but the transitive dependencies' APIs don't get included unless they're manually explicitly included in your Swift file. (Unless you use the private @_exported attribute, which for example is how import Cocoa is able to act like import AppKit + import Foundation + import CoreData, all at once).

For example I suspect many application developers would want to directly use EmbeddedPropertyList to handle protocol versioning properly. Reading the version of the helper tool lets me know exactly what requests my helper tools are capable of handling and how they will handle them.

This seems like a reasonable thing to expose right as a property of XPCClient. E.g myClient.serviceVersion, with EmbeddedPropertyList acting as a behind-the-scenes impl detail

[jakaplan]

Could I challenge you on this? I think it would be a real shame if it exposes a nice Swifty API that's pleasant to use, but is incomplete and requires 90% of API consumers to reinvent the same set of wheels (e.g. a lot of the code within this sample app).

Perhaps there should be opt-outs to allow people to opt out of excess file system IO, launchctl calls, etc. (if those turn out to be a performance concern for them), but I think the focus should be on covering on what most people would need most of the time, which I would certainly include launchctl-daemon-status-checking.

I can see the value of adding EmbeddedPropertyList because it allows for generating considerably more detailed error messages. However, I can't say the same for launchctl. In what scenarios do you need to know the information launchctl provides? I included this in the sample because it made for a nice visual representation of the effects of installing, uninstalling, and updating - but in practice I haven't found any need for this. Basically, if I can't talk to the daemon then it needs to be (re)installed.

The transitive dependencies aren't a total secret, e.g. they'll be pulled into a person's Package.resolved file, but the transitive dependencies' APIs don't get included unless they're manually explicitly included in your Swift file.

Hmm, so does that mean that API users could then explicitly choose to do import EmbeddedPropertyList and it would work? If so that makes me think any breaking changes to dependent frameworks are breaking changes for the parent framework. This is admittedly rather hypothetical as I don't anticipate EmbeddedPropertyList getting many (if any) changes anytime soon.

This seems like a reasonable thing to expose right as a property of XPCClient. E.g myClient.serviceVersion, with EmbeddedPropertyList acting as a behind-the-scenes impl detail

I don't think it is because XPCClient has no idea where on disk the service lives (or even if it exists) while EmbeddedPropertyList operates on Mach-O binaries and has no idea what XPC services are.

[jeff-h]

@amomchilov — I fear I have a bit of a simplistic understanding of all these things based on my own specific use-case, so apologies for that, but I wonder if it would be sufficient to create a "BlessedPlus" which is simply an extension to Blessed, which incorporates the EmbeddedPropertyList dependency and provides the full set of code that many people are going to be needing when using all these packages together (taken largely from the current SwiftAuthorizationSample)?

@grigorye — I notice you're using just Blessed (ie without EmbeddedPropertyList or SecureXPC) in your project. Do you have any perspective to add to this thread?

[grigorye]

@jeff-h Ah, I missed this sample at all, while employing Blessed in the project. Give me some time - I need to educate myself around SwiftAuthorizationSample/SecureXPC/EmbeddedPropertyList. And thanks for letting me know, as otherwise I would not be aware of the existence of these things.

What I can say so far is that, I kind of implemented the version checking for the helper myself, as well as bundling the Swift runtime libraries for concurrency on macOS 10.15. It took really quite an effort to figure it out, and I'm still not satisfied with the result. If there was a framework that would help me with that, that would be a relief (I guess I'm looking at it now). What I, personally, would probably prefer not deal with is "big framework" that "does it all", rather to be able to work with several frameworks each of which focuses on a certain task "independently" - from my experience these things cause less problem because I, as developer, can easily modify the "glue" myself, without fighting with the framework.

Sorry, can't provide more thoughts atm, as my spare time is quite limited.