Post

Replies

Boosts

Views

Activity

Issue with current macOS 11.3 beta 3 - kernel extensions
Hi! Since current macOS 11.3 beta 3, a bug appeared that was also present on some previous betas :( When loading a kernel extension, if it's unsigned but explicity allowed on AppleKextExcludeList (the list where Apple stores old safe kernel extensions, like vmware ones, some filesystems, etc) fails to load. This is a problem for all of us that want to keep running some legit software with no equivalent under SystemExtensions frameworks. This is just an example of osxfuse present on allowed list by Apple, but happens with ALL kernel extensions on the allowed list (like turbo boost switcher one, vmware, etc). All works just fine with current 11.2 Big Sur release.., please, fix that in order to add again the check against that list present on /Library/Apple/System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist -- sudo kextutil -v ../Desktop/osxfusefs.kext Defaulting to kernel file '/System/Library/Kernels/kernel' Executing: /usr/bin/kmutil load --bundle-path /Users/Ruben/Desktop/osxfusefs.kext Error Domain=KMErrorDomain Code=29 "Authenticating extension failed: Kext com.github.osxfuse.filesystems.osxfusefs v2.6.1 in executable kext bundle com.github.osxfuse.filesystems.osxfusefs at /private/var/db/KernelExtensionManagement/Staging/com.github.osxfuse.filesystems.osxfusefs.HnEP4u/osxfusefs.kext: Authenticating extension failed: Bad code signature" UserInfo={NSLocalizedDescription=Authenticating extension failed: Kext com.github.osxfuse.filesystems.osxfusefs v2.6.1 in executable kext bundle com.github.osxfuse.filesystems.osxfusefs at /private/var/db/KernelExtensionManagement/Staging/com.github.osxfuse.filesystems.osxfusefs.HnEP4u/osxfusefs.kext: Authenticating extension failed: Bad code signature}
3
0
1.9k
Mar ’21
Big Sur kext loading all or nothing policy?
Hi there! I've already posted this through feedback assistant (FB8767409) but posting here also to see if there is anyone experiencing the same issue. It seems that now on big sur, when you try to load a kext, it builds a cache and checks all of kernel extensions available.., the problem is that if there is at least one that can't be loaded, then no one is loaded even when it's fine. Here it's an example. When tried any Big Sur compatible extension with Virtual Box also installed (not compatible so far), the log shown: Error: Error Domain=KMErrorDomain Code=1 "Unable to resolve dependencies: 'org.virtualbox.kext.VBoxUSB' names a dependency on 'org.virtualbox.kext.VBoxDrv', which was not found." UserInfo={NSLocalizedDescription=Unable to resolve dependencies: 'org.virtualbox.kext.VBoxUSB' names a dependency on 'org.virtualbox.kext.VBoxDrv', which was not found.} Even when this has nothing to do when the extension I want to load! :( Reproduced this with several kexts... All other kexts were loaded just fine only after removing VirtualBox kext.., weird :(, this shouldn't be happening and kmutil/kextutil should only check the kext requested by the user to be loaded. Thanks in advance for the feedback!
1
0
1.1k
Oct ’20
App defaults like userdefaults possible?
Hi there! I've searching around, but wasn't able to find any documented way of doing the following.... In summary, it's possible to have a similar api to NSUserDefaults, but to store app common defaults shared by all users? I know I can accomplish that by using custom plist, core data and so on, but I think it'd great to have a similar API like NSUserDefaults but to store common app defaults shared by all users..., Thanks!!
2
0
647
Sep ’20
Not notarised when including unsigned content
Hi!I've an app that has been notarised without issues until now (last time just some weeks ago). Now is being rejected because it includes an unsigned kext... but the kext is allowed to run and whitelisted at AppleKextExcludeList for years.I guess the notarisation process has been recently changed and is not checking that whitelist, but it should, since it's not taking into account this old kext that run without issues and has been doing so for years.Already opened a FB: FB7642485Is there any other way to continue distributing the app and notarizing under this new policy? Do I need to sign the app with the developer certificate instead of Dev ID? Any ideas?Thanks!
6
0
794
Mar ’20