Please Help Me Understand Remote Kernel Extension Code Signing

[Michael Crawford]

Kernel extension signing is more complicated than signing a user-space
executible. Apple issued me a kext signing certificate. It works when
I build from the Xcode GUI or with xcodebuild.

Reading The Fine Manual could get me where I want to be, but whenever
I try to sign my driver my head spins.

I'm asking you to hold my hand. I'm not proud.

I'm configuring a remote build box for my client. I've gotten
everything other than code signing to work. If I log in to the GUI
then run my "build_all" script, codesign presents a GUI that prompts
for my password. If I ssh in, codesign will fail.

I think what I to do is:

$ security unlock-keychain ...
$ codesign ...
$ security lock-keychain ...

I can figure out how lock and unlock my key chain; it's the codesign
command line that confuses me.

Here's what xcodebuild does:

/usr/bin/codesign --force --sign
84208E9C30B70E303186BAF330554E82E1891492 --requirements =designated\
=>\ anchor\ apple\ generic\ \ and\ identifier\ \"$self.identifier\"\
and\ ((cert\ leaf[field.1.2.840.113635.100.6.1.9]\ exists)\ or\ (\
certificate\ 1[field.1.2.840.113635.100.6.2.6]\ exists\ and\
certificate\ leaf[field.1.2.840.113635.100.6.1.13]\ exists\ \ and\
certificate\ leaf[subject.OU]\ =\ \"444JK52Q93\"\ )) --timestamp=none
/Users/build/BuildBox/FL2000/trunk/IOProxyVideoFamily/Release/IOProxyFramebuffer.kext

I attempted to copy the above command line then paste it into the
Terminal but so many parentheses lead the command to fail:

Command-C
Command-V
-bash: syntax error near unexpected token `('

Perhaps all I need is to add some quotes or backslashes to codesign's
command line.

(Reposted from:
https://stackoverflow.com/questions/50282921/please-help-me-understand-remote-kernel-extension-code-signing)

I Am Eternally In Your Debt.
--
Mike Crawford
Portland Custom Software Development
mi...@soggywizards.com
http://soggywizards.com

One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (Darwin-...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/darwin-drivers/darwin-drivers-garchive-96018%40googlegroups.com

This email sent to darwin-drivers...@googlegroups.com

[Daniel J. Luke]

On May 10, 2018, at 7:38 PM, Michael Crawford <mi...@soggywizards.com> wrote:
> Here's what xcodebuild does:
>
> /usr/bin/codesign --force --sign
> 84208E9C30B70E303186BAF330554E82E1891492 --requirements =designated\
> =>\ anchor\ apple\ generic\ \ and\ identifier\ \"$self.identifier\"\
> and\ ((cert\ leaf[field.1.2.840.113635.100.6.1.9]\ exists)\ or\ (\
> certificate\ 1[field.1.2.840.113635.100.6.2.6]\ exists\ and\
> certificate\ leaf[field.1.2.840.113635.100.6.1.13]\ exists\ \ and\
> certificate\ leaf[subject.OU]\ =\ \"444JK52Q93\"\ )) --timestamp=none
> /Users/build/BuildBox/FL2000/trunk/IOProxyVideoFamily/Release/IOProxyFramebuffer.kext
>
> I attempted to copy the above command line then paste it into the
> Terminal but so many parentheses lead the command to fail:
>
> Command-C
> Command-V
> -bash: syntax error near unexpected token `('
>
> Perhaps all I need is to add some quotes or backslashes to codesign's
> command line.

Looks that way.

The codesign manpage also says:

SPECIFYING REQUIREMENTS
The requirement(s) arguments (-r and -R) can be given in various forms. A
plain text argument is taken to be a path to a file containing the
requirement(s). codesign will accept both binary files containing prop-
erly compiled requirements code, and source files that are automatically
compiled before use. An argument of "-" requests that the requirement(s)
are read from standard input. Finally, an argument that begins with an
equal sign "=" is taken as a literal requirements source text, and is
compiled accordingly for use.

So, the easiest thing would probably be to put the requirements in a source file - then you don't have to worry about shell quoting.
--
Daniel J. Luke

[B.J. Buchalter]

> Here's what xcodebuild does:
>
> /usr/bin/codesign --force --sign
> 84208E9C30B70E303186BAF330554E82E1891492 --requirements =designated\
> =>\ anchor\ apple\ generic\ \ and\ identifier\ \"$self.identifier\"\
> and\ ((cert\ leaf[field.1.2.840.113635.100.6.1.9]\ exists)\ or\ (\
> certificate\ 1[field.1.2.840.113635.100.6.2.6]\ exists\ and\
> certificate\ leaf[field.1.2.840.113635.100.6.1.13]\ exists\ \ and\
> certificate\ leaf[subject.OU]\ =\ \"444JK52Q93\"\ )) --timestamp=none
> /Users/build/BuildBox/FL2000/trunk/IOProxyVideoFamily/Release/IOProxyFramebuffer.kext
>
> I attempted to copy the above command line then paste it into the
> Terminal but so many parentheses lead the command to fail:
>
> Command-C
> Command-V
> -bash: syntax error near unexpected token `('
>
> Perhaps all I need is to add some quotes or backslashes to codesign's
> command line.

I think you need to add double quotes around the entire requirement’s string (e.g. right before the ‘=' and right after the last
‘)’ )

[Scott Hannahs]

> On May 10, 2018, at 7:45 PM, B.J. Buchalter <b...@mhlabs.com> wrote:
>
>
>> Here's what xcodebuild does:
>>
>> /usr/bin/codesign --force --sign
>> 84208E9C30B70E303186BAF330554E82E1891492 --requirements =designated\
>> =>\ anchor\ apple\ generic\ \ and\ identifier\ \"$self.identifier\"\
>> and\ ((cert\ leaf[field.1.2.840.113635.100.6.1.9]\ exists)\ or\ (\
>> certificate\ 1[field.1.2.840.113635.100.6.2.6]\ exists\ and\
>> certificate\ leaf[field.1.2.840.113635.100.6.1.13]\ exists\ \ and\
>> certificate\ leaf[subject.OU]\ =\ \"444JK52Q93\"\ )) --timestamp=none
>> /Users/build/BuildBox/FL2000/trunk/IOProxyVideoFamily/Release/IOProxyFramebuffer.kext
>>
>> I attempted to copy the above command line then paste it into the
>> Terminal but so many parentheses lead the command to fail:
>>
>> Command-C
>> Command-V
>> -bash: syntax error near unexpected token `('
>>
>> Perhaps all I need is to add some quotes or backslashes to codesign's
>> command line.
>
> I think you need to add double quotes around the entire requirement’s string (e.g. right before the ‘=' and right after the last
> ‘)’ )

or use control-Command-V to escape the paste in terminal friendly manner.

[Garth Cummings]

Hi,

There's no need to specify the designated requirement. The default DR generated by codesign will be fine.

$ codesign -f -s "Developer ID Application:" mykext.kext

should be all you need.

—gc

[B.J. Buchalter]

> On May 14, 2018, at 6:54 PM, Garth Cummings <gcum...@apple.com> wrote:
>
> Hi,
>
> There's no need to specify the designated requirement. The default DR generated by codesign will be fine.
>
> $ codesign -f -s "Developer ID Application:" mykext.kext
>
> should be all you need.

Hi Garth,

Thanks! That’s good to know; it is hard to determine what is required and many of us default to copying what Xcode does, just to be safe…

BR,

B.J. Buchalter
Metric Halo
http://www.mhlabs.com

[Jim Wintermyre]

Wow, that massively simplifies the command line our automated tools use for kext signing!

Is this true for all versions of OS/codesign that can actually generate a valid kext signature (e.g. v2 resource envelope)? You know, in case certain unnamed developers out there might be running their build servers on older versions of OS X (gasp!)… :)

Thanks,
Jim

[Garth Cummings]

Hi Jim,

It should work everywhere.

The two things that make signing more complicated is if there's no valid bundle ID or bundles with nested code. Kexts rarely have those issues.

Note that Xcode will do this signing for you if you turn off Automatic Signing and select your Developer ID Application identity under Signing (Release).

For development builds we recommend not signing them but instead disable SIP on your test systems so the unsigned kext will load. That way, if a development build makes it into the wild somehow, it won't load for most users and it won't get confused with your actual production kext.

—gc