Posts

Post not yet marked as solved
1 Replies
1.5k Views
In the latest beta of Ventura (and perhaps earlier versions) there is a section of the System Settings > General > Login Items pane called "Allow in Background". It appears that helpers (LaunchAgents/LaunchDaemons) that are installed by apps are listed here. As you can see in the screenshot below, I have 3 such items installed on my test system. The per User LaunchAgent for the Google Updater, the WireShark LaunchDaemon for the ChmodBPF script, and the LaunchDaemon for my userspace CoreAudio Driver (labelled "Metric Halo Distribution, Inc."). The WireShark and Google Updater have nice user identifiable names associated with them, whereas my Launch Daemon only has my company name associated with it. I don't see anything in the plists for Wireshark or GoogleUpdater that seem to specify this user-visible string, nor in the bundles the plists point to. How do I go about annotating my LaunchDaemon plist or the helper tool's plist so that the string in this pane helps the user properly identify what this Background item is for so that they don't accidentally turn it off and disable the driver they need to use our audio hardware? Obviously, we will document this, but just as obviously users don't always read the docs, and it would be better if the user just could make the immediate association that this Background item is needed for our CoreAudio driver.
Posted
by bjb.
Last updated
.
Post marked as solved
3 Replies
6.1k Views
Is there a way to get Xcode 13 to show file extensions in the Project Navigator? Actually in all the places that Filenames are shown in the UI (window title, pane bar, navigators)? Xcode 13 is hiding the extensions; for C++; Obj-C, and dext projects, that is very confusing because the extension is the only thing that distinguishes between multiple files with the same base name. Is there a hidden preference available to restore the old behavior?
Posted
by bjb.
Last updated
.
Post marked as solved
6 Replies
4.9k Views
I think I understand notarization:It sends binary to AppleApple performs automatic verificationIf verification succeeds, (and perhaps this is the wrong terminology) a Notarization Ticket is stored on Apple's serversWhen an end user goes to use the Notarized Binary, macOS requests a Notarization Ticket for the binary, and if this succeeds, then all is good. This, of course, requires a network connection on the end user's machine when the binary is (first?, always?) accessed. It seems pretty clear from the staple tool that the ticket is cached locally, so while it may be verified every time, it only needs to be downloaded once.Stapling is a post-process step that downloads the Notarization Ticket and attaches it to the binary (before distribution) so that the end user's machine can verify the Notarization without a network connection back to Apple being available at all.As of 10.14.5, kexts MUST be notarized in order to be loaded. Again, it is not clear if this verification is on every load, or only the first load.Now, you can staple binaries, and you can also staple the flat .pkg that is used to distribute them.The question that I am unclear on is:If I package my kext in a flat installer .pkg, and then submit the .pkg for Notarization, the Notarization service notarizes both the .pkg and the kext.If I staple the .pkg, does the Notarization Ticket that is stapled to the .pkg include the Notarization Ticket for the kext, or does the kext need to be stapled seperately? If it does need to be stapled seperately, then I would need to rebuild the .pkg after stapling, which would invalidate the Notarization ticket for the .pkg. So that would imply that I would have to re-notarize the pkg, and then staple the pkg.TLDR:Is the process (option 1):Create kextCreate pkgNotarize pkgStaple pkgor does it have to be (option 2):Create kextNotarize kextStaple kextCreate pkgNotarize pkgStaple pkgObviously, option 1 is more appealing if it works.
Posted
by bjb.
Last updated
.