The Volta application is installed on my MacBook Pro, running macOS 10.14 Mojave.
This app needs a kernel extension to function properly, and said extension does not have the proper code signatures. This means it's necessary to tamper with System Integrity Protection in order to load this extension.
In macOS 10.13 High Sierra, one could run
csrutil enable --without kext to partially disable SIP (loading unsigned kexts is allowed, but other protections remain in place). According to Volta's installation instructions, in Mojave one must fully disable SIP, leaving the whole computer unprotected because of one kernel extension.
For reference, this is the output of
kextutil -l applied to this extension:
$ sudo kextutil -l /Applications/Volta.app/Contents/Resources/Driver.kext Untrusted kexts are not allowed Kext with invalid signature (-67050) denied: /Library/StagedExtensions/Applications/Volta.app/Contents/Resources/0A012E5A-9F74-4E19-9195-535AD692A597.kext Bundle (/Applications/Volta.app/Contents/Resources/Driver.kext) failed to validate, deleting: /Library/StagedExtensions/Applications/Volta.app/Contents/Resources/0A012E5A-9F74-4E19-9195-535AD692A597.kext Unable to stage kext (/Applications/Volta.app/Contents/Resources/Driver.kext) to secure location.
And this is the output of running
codesign --display --verbose=4 /Applications/Volta.app/Contents/Resources/Driver.kext as suggested in Ricardo Anjos' answer:
Executable=/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver Identifier=com.gmathews.volta.driver Format=bundle with Mach-O thin (x86_64) CodeDirectory v=20200 size=345 flags=0x0(none) hashes=3+5 location=embedded Hash type=sha256 size=32 CandidateCDHash sha1=cbf1caa72d5071c35aa3c020d557a084e6e5a8c9 CandidateCDHash sha256=468cc8b2215b53445cb650c94a76413db62a4815 Hash choices=sha1,sha256 Page size=4096 CDHash=468cc8b2215b53445cb650c94a76413db62a4815 Signature size=4697 Authority=Developer ID Application: Gary Mathews (SFS8238QUB) Authority=Developer ID Certification Authority Authority=Apple Root CA Signed Time=26 Jul 2018 23:14:21 Info.plist entries=19 TeamIdentifier=SFS8238QUB Sealed Resources version=2 rules=13 files=0 Internal requirements count=1 size=220
Here's also the output for
codesign -v on the same file:
/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver: valid on disk /Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver: satisfies its Designated Requirement
I also followed the same process with the main executable as well as the helper application, and they all checked out (valid signatures, and the same authority and team ID).
I compared the output of
codesign to another random third-party kext in my computer, which runs fine without requiring me to circumvent SIP, and I couldn't spot any differences.
Moreover, Volta's FAQ page instructs the user on how to work around SIP, so it seems like a deliberate decision by the developer and not just a mistake.
I'm very bothered by this situation. As the legitimate owner of this machine, and having physical access to it, is there nothing I can do (short of fully disabling SIP) to whitelist this one kernel extension, assuming the developer can't sign the extension for some reason? I don't care if it entails entering cryptic commands in recovery mode, writing stuff to NVRAM or code-signing the extension myself, so long as I don't have to pay Apple $99 for the privilege.