Error when updating system extension

I'm currently observing a problem similar to this thread https://developer.apple.com/forums/thread/737334

The difference is that this is happening after updating a system extension.

Basically same error, sysextd complains it can not check that the system extension is notarized: macOS Error 3 + Error code=-67050.

I think macOS (Sequoia 15.3.2 or 15.7.2 if it matters) is wrong in this case for the following reasons:

  • when using spctl assess -t install, the system extension is reported to be correctly notarized.
  • when restarting the Mac, the updated system extension is correctly checked and staged.
  • if I run spctl assess before sysextd tries to check the system extension, it works.

I'm currently thinking of 2 reasons why the check does not work:

  • sysextd is somehow trying to work with a cached assessment that has become invalid after the system extension was updated.
  • macOS needs way more time between the update of the files and the request to update the staged extension. I tried adding a 5-second delay. This does not seem to work or at least reliably.

I tried just touching the system extension, no positive result. Unfortunately, in macOS Sequoia, it is not possible anymore to reset-default using spctl and see if it solves the issue, at least the next time the update is performed.

[Q] Is there some magic operation that would help macOS correctly check the notarization of an updated system extension?

Answered by DTS Engineer in 869232022

My response on that other thread still applies here. Can you reproduce this on a clean machine? Or are you only seeing this on specific Macs?

Specifically, I recommend that you run this test:

  1. Install your target OS in a VM.
  2. Take a snapshot of the clean VM for the benefit of future tests.
  3. Install your product as a user would.
  4. Update your product as a user would.

Does that reproduce the problem?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

My response on that other thread still applies here. Can you reproduce this on a clean machine? Or are you only seeing this on specific Macs?

Specifically, I recommend that you run this test:

  1. Install your target OS in a VM.
  2. Take a snapshot of the clean VM for the benefit of future tests.
  3. Install your product as a user would.
  4. Update your product as a user would.

Does that reproduce the problem?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I don't think the problem is coming from the macOS instance itself as the problem does not occur when the extension is updated using an installation package.

The problem only happens when replacing the system extension and its wrapper .app using basic NSFileManager APIs.

I diffed the 2 cases and there are no differences. Same files, same contents. And anyway spctl and codesign are happy.

I tried different macOS versions in VMs (14, 15). Same result.

What I'm also observing is that after updating the system extension using an installation package, just using the NSFileManager APIs is going to work fine when reverting to any version that has been previous installed via an installation package or updating to version that has been previously updated via an installation package.

This issue is related to notarization assessment not being automatically done by the OS.

[Q] Are there public APIs to assess notarization? There are private APIs (visible in the security open source code of the security library) but there does not seem to be public APIs.

Are there public APIs to assess notarization?

That’s tricky, because it depends on your definition of API.

The codesign tool has a --check-notarization operation that does that. See Testing a Notarised Product and the codesign man page. While that’s documented, I’m not a fan of using command-line tools as APIs.

The code signing requirement language has the notarized constraint. That’s not documented where it should be but it’s debatable whether that’s just because the parent document is stuck in the Documentation Archive.

Annoyingly, an equivalent constraint has not been added to the LightweightCodeRequirements framework. If you think that’d be useful, I encourage you to file an enhancement request for it. And if you do, please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

API != command line tool.

Not a fan of using command line tools either.

I have already a radar/feedback assistant ticket about this issue: 21381323

Error when updating system extension
 
 
Q