A few weeks ago I had problems with provisioning profiles for some macOS programs, so I deleted/revoked a bunch of certificates and provisioning profiles and started from scratch. (Everything seems to be working for me)
Unfortunately, a co-worker had two programs on his machine that were built with the old, test provisioning profiles with the revoked certificates, and it seems this may be preventing him from deleting the system extensions.
The apps have been deleted, but that does not delete the system extensions. I installed a new program that programmatically (tries to) uninstall the system extension, but it doesn't seem to work either.
When he reboots his computer, macOS pops up a window showing that the extensions may be malware. If he clicks "Show in Finder" and then tries to delete the system extensions from the Finder, he gets the message:
The operation can't be completed because you don't have permission to access some of the items.
Is it possible to delete the old system extensions that were installed with the old provisioning profiles? Are there multiple files that need to be deleted (e.g., the system extension and a .plist file somewhere)?
Post
Replies
Boosts
Views
Activity
I have a macOS SwiftUI app with a secondary window that should be opened/displayed if a certain condition occurs. The logic that detects the condition is inside a Swift class.
I see lots of examples where opening a window is done inside another SwiftUI View using something like
struct ContentView: View {
@Environment(\.openWindow) var openWindow
var body: some View {
...
Button("Open window") {
openWindow(id: "secondWindowId")
}
}
In my case, the logic that detects the condition that would prompt the opening of secondWindowId is in a Swift class (not a SwiftUI View).
Is there a standard way to open the window identified with "secondWindowId" from inside a Swift class?
I have an app that installs an endpoint system extension, and I have the app notarized.
I can install the endpoint system extension and enable Full Disk Access fine on
Ventura, Apple Silicon
Sonoma, Apple Silicon
But I cannot enable Full Disk Access on
Ventura, Intel
In System Settings, when I try to slide toggle switch on to enable full disk access, the toggle slides right back to off.
In previous development versions, I could enable Full Disk Access on the Intel machine.
Any idea why I cannot enable Full Disk Access on Ventura/Intel for my endpoint system extension in my notarized app?
One additional observation, the name displayed in the Full Disk Access section is different between the Apple Silicon and Intel Macs.
On Apple Silicon, only the final part of the Bundle ID is shown in Full Disk Access:
endpointagent
On Intel, the full Bundle ID is shown:
com.MyCompany.MyApp.endpointagent
Don't know if it matters, but I thought I'd point that out.
I have an endpoint system extension that monitors exec system calls. It works fine, but I have to follow a very specific order when installing it.
When I (the user) click to install, I get the option to open System Settings. There, I am presented with an option to "Allow" the endpoint application.
If I:
(1) click "Allow"
and then
(2) enable full disk access
The application runs but doesn't get exec events.
Console shows the error message
Failed to open service: 0xe00002d8: Caller lacks TCC authorization for Full Disk Access
Even after enabling full disk access (after allowing the extension to be installed), I do not get the exec events.
To resolve this, I have to uninstall the endpoint system extension and reinstall it.
(Note: If I first grant full disk access and then allow the endpoint system extension to be installed, everything works fine, but I suspect most users will now follow this happy path.)
Is there a way to smooth this out, so that once full disk access is granted, the endpoint system extension gets events without needing to uninstall and reinstall the endpoint agent?
I would like to release a Mac app through the Mac App Store that is free.
However, I would like to add new functionality in a future software update that is enabled through an in-app purchase.
I reviewed the App Store Review Guidelines, and I did not see any prohibitions to this approach (initially free, later add new functionality enabled by an in-app purchase).
If anyone knows of any rules or policies that I missed that would prohibit this, I would appreciate a heads up on it.
Thanks!
I am adding unit tests to an existing SwiftUI project, and I've discovered the main 'App' struct's init() function is being called automatically before the individual test functions are run.
(1) Is this expected behavior?
(2) Is there a way to disable the App struct's init() from being called when running unit tests?
In my use case, the App struct's init() does some initialization, including network activity, that I would prefer not happen during unit tests.
Below is simplified version of what I am seeing beginning with the App struct:
import SwiftUI
import os.log
@main
struct MyTest2App: App {
init() {
os_log("===== In MyTest2App.init() =====")
}
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
Here is an example of a struct that I want to exercise in a unit test:
import Foundation
struct Foo {
var name: String
var count: Int
init(name: String, count: Int) {
self.name = name
self.count = count + 1
}
}
Here is a unit test file:
import XCTest
final class MyTest2Tests: XCTestCase {
override func setUpWithError() throws {
}
override func tearDownWithError() throws {
}
func testExample() throws {
let foo = Foo(name: "Apple", count: 3)
XCTAssertEqual(foo.count, 4)
}
}
Here is part of the output console. The first line is the output from the App struct's init() function:
2023-09-27 10:41:26.798791-0700 MyTest2[66138:9429362] ===== In MyTest2App.init() =====
2023-09-27 10:41:26.869966-0700 MyTest2[66138:9429362] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/yg/vfstql350kqgzp17lmh11jg80000gn/T/com.ennetix.MyTest2/com.ennetix.MyTest2.savedState
...
I have a network system extension that sends flow records to my GUI app, and I saw an unusual string (%awdl0) appended to the local and remote IPv6 addresses in flow records from the UniversalControl program on my Intel iMac Pro.
fe80::f42d:14ff:fe38:7db7%awdl0
fe80::18d7:9bff:feae:2e32%awdl0
Any idea why the suffix is appended to the IPv6 address and what it means?
Here are more details about the event:
{
"localPort" : "56604",
"socketProtocol" : 6,
"version" : 0,
"programLastComponent" : "UniversalControl",
"localName" : "fe80::f42d:14ff:fe38:7db7%awdl0",
"time" : 716847716.50096297,
"socketType" : 1,
"remotePort" : "57968",
"socketFamily" : 30,
"procInfo" : {
"path" : "\/System\/Library\/CoreServices\/UniversalControl.app\/Contents\/MacOS\/UniversalControl",
"lastComponent" : "UniversalControl",
"teamId" : "",
"signingId" : ""
},
"timeStr" : "2023-09-19T20:21:56Z",
"remoteName" : "fe80::18d7:9bff:feae:2e32%awdl0",
"pid" : 667,
"webHost" : "",
"webUrl" : ""
}
And here is the flurry of flows reported including their ports:
I have an app that uses Apple's Endpoint Security system extension to collect a number of events including authentication events.
I've noticed AKD (Apple Keychain Daemon?) generates fail authentication events when I unlock my Mac with either Touch ID or password. I don't think I've ever seen it succeed.
Does anyone know what AKD is trying to authenticate and why it is failing?
Should I mask these out from being shown, or are there cases where AKD authentication will matter?
Hardware: MacBook Pro with M1
OS: macOS 13.5.2
Device is configured stand-alone (not a managed device)
I ran into a strange situation (bug?) today trying to resize the relative height of two views in a VStack on macOS. I accomplished this by inserting a thin rectangle between the two views and applying a DragGesture to it. It works fine... until it doesn't. It takes a lot of changing of the view heights before I hit the bug, but if I drag & release enough times, I will eventually hit it.
At some point, the code goes into an infinite loop and the program effectively freezes. os_log() is showing the .onChange value.height continuously flip flopping between -0.25 and +0.25.
I found a kludge/work-around. If the onChange's absolute value is less than 1, I don't update the frame hight. Then the code runs like a champ.
Am I doing something wrong? Is this a bug I should file?
Here is the SwiftUI test code:
import SwiftUI
import os.log
struct ResizableViews: View {
@State private var height: CGFloat = 200
let minHeight:CGFloat = 30
let maxHeight: CGFloat = 400
var body: some View {
Group {
VStack (spacing: 0) {
Rectangle()
.fill(Color.blue)
.frame(height: height)
// The draggable rectangle/handle
Rectangle()
.background(Color.gray)
.frame(height: 10)
.gesture(
DragGesture()
.onChanged { value in
os_log("CHANGE \(value.translation.height)")
// abs() > 1 is a kludge to avoid infinite loop
// with value changes flipping between -0.25 and
// 0.25
if abs(value.translation.height) >= 1 {
let tmpHeight = height + value.translation.height
height = min(max(tmpHeight, minHeight), maxHeight)
}
}
.onEnded{ value in
os_log("END \(value.translation.height)")
}
)
Rectangle()
.fill(Color.red)
}
}
}
}
Here is the console output showing the value.translation.height flip flopping between -0.25 and +0.25.
Hardware: MacBook Pro with Apple M1 Pro
OS: Ventura 13.5.1
I have a regular GUI-based app that communicates with an Endpoint System Extension installed by another app.
Both the GUI app and Endpoint System Extension have the same Team ID and are part of the same App Groups.
But I still need to do one of the following to the GUI-based app to allow it to communicate with the Endpoint System Extension over XPC:
Disable the sandbox
Add com.apple.security.temporary-exception.mach-lookup.global-name to entitlements
For some reason I thought there was another way to resolve this. Am I missing anything?
(My goal is to allow an app distributed through the Mac App Store to communicate with my Endpoint System Extension if it exists, and I am worried about the "temporary-exception" entitlement needed to support this.)
I ran into a strange problem during development this morning. When trying to install my Endpoint and Network System Extensions (something I was able to do yesterday, and many times before), my Mac is prompting me to enable Kernel Extensions.
Right before this happened, I had problems deleting the previous version of the apps from the /Applications folder (it took many tries). This too was unusual.
After agreeing to allow the installation of my Endpoint System Extension, I was greeted with this previously unseen message and button:
When I click "Enable System Extensions...", and I am greeted with this alert:
I also ran into this problem when trying to install my Network System Extension.
Anyone have any idea how I screwed up my system?
Anyone know how to return it to normal behavior?
System: Mac Studio 2022
OS: Ventura 13.4.1
(I'm thinking of re-instaling Ventura this evening; would prefer not to)
If I distribute an app through the Mac App Store that includes a Network Extension that must be installed (and getting the user's permission in the process), and later I submit an update to the app (although no changes to the network extension piece) through MAS, will the user need to re-install the Network Extension?
That is, does updating an app with that has a Network Extension remove the previous Network Extension from the system?
I noticed jq (installed from Homebrew) has an ad hoc signature and is rejected by spctl but runs fine. I don't remember ever being prompted by my Mac as to whether this binary should be allowed to run.
I repeated the experiment with another binary (aescrypt) downloaded from Homebrew.
Should Gatekeeper prevent these binaries from executing until I intervene?
Is there any online documentation explaining the conditions that allow some binaries that are rejected by spctl and have no signature chain rooted at Apple to execute?
(Or am I just not understanding how to use Gatekeeper and spctl?)
codesign analysis:
% codesign -vvd /opt/homebrew/bin/aescrypt
Executable=/opt/homebrew/Cellar/aescrypt/0.7/bin/aescrypt
Identifier=aescrypt
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=545 flags=0x20002(adhoc,linker-signed) hashes=14+0 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none
And checking spctl analysis:
% spctl --assess -vvv /opt/homebrew/bin/aescrypt
/opt/homebrew/bin/aescrypt: rejected
IIRC, when Apple introduced the new Network Extension and Endpoint Security system extension architectures, apps with Network Extensions in their bundle had to be distributed through the Mac App Store, whereas apps with Endpoint Security extensions could not be distributed through the Mac App Store (or vice versa).
I can no longer find language on such restrictions.
Can I distribute an app with both a Network Extension and an Endpoint Security extension in the same app bundle via the Mac App Store?
Looking at the certificate chains for various binaries (using Apple's APIs or codesign --vvd) shows several patterns for the common names.
I am wondering why some code has the structure
Apple Root CA
Developer ID Certification Authority
Developer ID Application: Google LLC (EQHXZ8M8AV)
while others have the pattern
Apple Root CA
Apple Worldwide Developer Relations Certification Authority
Apple Mac OS Application Signing
Note, the second pattern does not include an organizational name.
Why is there a difference?
Is the second pattern an older pattern and the first (with the organization name) the new pattern?
(There are other certificate patterns like for Apple's binaries and development code I am testing)