Codesign node binary for macOS

[raphaelokon]

Hi there.

I recently had a quick chat with @MylesBorins via 🐦 who encouraged me to post the issue here.

Tools like Little Flocker reports node with an invalid Developer ID whenever I run it on my machine. So I checked the node binary with codesign -vvvv $node_bin to see if it is code signed – which returns code object is not signed at all.

Is it possible to have the macOS Binaries signed by a Developer ID? I know that the .pkg/.tar.gz are signed, but would be great to have another layer of confidence.

I found this two issues in relation: https://github.com/nodejs/node/issues?q=codesign

[gibfahn]

I assume this would be something we could do for at least windows as well?

[mscdex]

@gibfahn I thought Windows binaries already were being signed, hence the 'nosign' command-line option for vcbuild?

[gibfahn]

Yeah okay, we are signing both the node.exe binary and the .msi installer. Didn't realise we were doing both.

[raphaelokon]

@gibfahn That's cool. I just saw this here in the Makefile – does that mean that the macOS installer is getting signed as well? just checked it myself, and indeed the .pkg seems to be signed when inspected with pkgutil --check-signature

[raphaelokon]

If I can do anything to push this forward please let me know.

[gibfahn]

It looks like the package signing on macOS is done by the two scripts linked to from the Makefile as you pointed out. osx-codesign.sh signs the binary, and osx-productsign.sh signs the pkg file.

Are you sure the binaries aren't signed? I ran codesign -dvvv ./node on a node binary I built locally, and I get:

➜  codesign -dvvv ./node
./node: code object is not signed at all

If I run the same thing on a node binary from the pkg or the tar.gz, I get:

➜  codesign -dvvv `which node`
Executable=/Users/gib/.nvm/versions/node/v6.10.0/bin/node
Identifier=node-55554944ea42999f6a9f32508a5ebb5ac25b716a
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=240350 flags=0x2(adhoc) hashes=7506+2 location=system
Hash type=sha256 size=32
CandidateCDHash sha1=9834f282795fc5294e7cdadf1481e85765a1a0fd
CandidateCDHash sha256=529de940acb145410eb799453cf00243f79b1f49
Hash choices=sha1,sha256
CDHash=529de940acb145410eb799453cf00243f79b1f49
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=0 size=12

I guess cc/ @rvagg as he seems to be the only person to have ever touched those files.

[gibfahn]

Also cc/ @nodejs/platform-macos

[gibfahn]

I didn't actually install the pkg (don't want to mess with the multiple versions of node I have installed already), I just did:

curl -O https://nodejs.org/dist/v6.10.1/node-v6.10.1.pkg
pkgutil --expand node-v6.10.1.pkg nodepkg
cd nodepkg/local.pkg
tar -xf Payload
codesign -vvvv bin/node

Output:

➜  bin codesign -vvvv ./node                                       ~/nodepkg/local.pkg/bin
./node: valid on disk
./node: satisfies its Designated Requirement

[raphaelokon]

@gibfahn Thanks for the detailed response. Yeah, running codesign -dvvv actually gave me the same output as yours.
Not sure why then, but Little Flocker still tells me that the 'Code Signature Invalid'. Tracking it down a bit … it seems like its SecStaticCodeCheckValidityWithErrors returns a err​Sec​CSSignature​Invalid error.

[raphaelokon]

According to the Code Signing Guide this test mimics what macOS Gatekeeper does

→ codesign --verify --deep --strict --verbose=2 `which node`

Expected and actual result:

./node: valid on disk
./node: satisfies its Designated Requirement

So maybe this is just a local issue with Little Flocker.

[raphaelokon]

I am reopening this issues because I have done some more tests and been monitoring this.

I downloaded the node-v7.9.0-darwin-x64.tar.gz, unzipped it and ran

→  codesign -dvvv ./node
./node: code object is not signed at all

When downloading the node-v7.9.0.pkg and running

pkgutil --expand node-v7.9.0.pkg nodepkg
cd nodepkg/local.pkg
tar -xvf Payload
cd bin
codesign -vvvv ./node

→  bin codesign -vvvv ./node                                      
./node: valid on disk
./node: satisfies its Designated Requirement

There seems to be a regression here or the .tar.gz is not being codesigned at all.

Any clues? Can you test it this way as well @gibfahn?