Notarizing Kexts?

Is there a guide as to how to notarize kexts?

My understanding is that there’s currently no provision for notarising KEXTs.

The above is wrong )-: See haikeeba’s post below.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Yes, you can notarize kexts, along with all the other software you distribute (apps, screensavers, nested pkgs, disk images, help bundles, etc.) You just upload the final archive that you plan to distribute to your users. The notary guide says:

You can notarize several different types of software deliverables, including:

• macOS apps
• Non-app bundles, such as kernel extensions
• Disk images (UDIF format)
• Flat installer packages

https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

While there isn't a separate notarization guide for kexts (kernel extensions), the standard instructions for notarizing from the command line apply to kexts or other builds not created by Xcode.

https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution/customizing_the_notarization_workflow

"While you can notarize a ZIP archive, you can’t staple to it directly. Instead, run

stapler

If you can't staple tickets to standalone binaries, archives (and so flat installer packages, disk images), why is the documentation claiming that notarization is possible for these items like for bundles?

My interpretation of that comment is that “binaries” is intended to mean “executables”. You certainly can staple tickets to other binary file formats, although only ones that have specific affordance for it (like installer packages and disk images). However, my recommendation is that you file a bug against the doc requesting that this comment be clarified.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

So for a collection of LaunchDaemons, LaunchAgents, End User apps and kexts that we distribute via a flat pkg file, am I right that the only thing that needs notorizing is the pkg file itself? Trying to do each individual component separately is too much of a burden on our release cycle.

Also, for the kexts, will notorization reject us if are using anything non-KPI internally. (Yes, we realise the dangers of going off piste into private kernel stuff.)

Also, for the kexts, will notorization reject us if are using anything non-KPI internally.

Notarisation is not App Review; its goals are to detect known malware and check that everything is signed correctly, not to ensure that the code follows the rules of the road.

Having said that, DTS has recommended that developers stick with public APIs (or KPIs) since long before App Review existed. Apple does its best to maintain binary compatibility for our public APIs, but we make no such guarantees for unsupported techniques. This is especially important for KEXTs, because any problem in a KEXT will take down the entire system.

I’m not sure what type of KEXT you’re working on, but I’m most familiar with NKEs and so let’s look at that as an example. Apple has publicly announced that we intend to deprecate NKEs at some point in the future. We intend to provide a migration strategy for the use cases that are covered by the current NKE KPIs. However, we can’t prepare a migration strategy for unsupported techniques, so if you were an NKE developer relying on such techniques then you could be completely broken by this change.

Ultimately this is a business decision that you have to make, weighing the short-term benefits over the potential long-term costs. The one thing I will say categorically is that, if you decide to use an unsupported technique, make sure you file enhancement request for a supported alternative. That way there’s some hope of us being able to provide you with a migration strategy.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

To answer my own question about notorizing a pkg file that includes a kext. It does indeed now seem to work in that my package file passes notorization. Stapling failed initially until I followed the instructions to use this on 10.13.6:

sudo killall -9 trustd; sudo rm /Library/Keychains/crls/valid.sqlite3

Where did you get this information about need to kill trustd and to remove the squlite3 db?

Is this safe to do? What impact would it have?

Thanks.
Devendra.

The information about

trustd

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Notarizing Kexts?

FYI, I’ve just created a new post, Notarising an Installer Package Containing a KEXT, that clarifies the relationship between KEXTs, installer packages, and notarisation.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for the extra info. From the 10.14.5 release notes, the preinstall script has an explicit test for 10.14.5 only:

if [[ `/usr/bin/sw_vers -productVersion` == 10.14.5 ]]; then
/usr/sbin/spctl -a -vvv -t install "$PACKAGE_PATH"; fi

So am I correct in assuming that the spctl call really won't be needed in Catalina, nor some possible future 10.14.6 release.

So am I correct in assuming that the spctl call really won't be needed in … some possible future 10.14.6 release.

That certainly seems to be the case. I had a look at the bug mentioned in the release notes (r. 50205533) and it’s marked as fixed in the 10.14.6 beta 2 that we’re currently seeding.

Of course, the proof of the fixing is in the testing (-:

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you for creating that document/post.

Is there a way to verify that a kext file has been notarized? Or command line executables for that matter?

It looks like `spctl -a -v` only works for app bundles, and `stapler validate` only works for pkg files.

Is there a way to verify that a kext file has been notarized?

If you’re on 10.15 beta you can check anything ‘signable’ using:

$ codesign -vvvv -R="notarized" --check-notarization /path/to/your.kext

I’ve not tried this on KEXTs but it’s worth a shot.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"