Closed strager closed 2 years ago
For macOS, I need an Apple developer account. This requires 2fac on my Apple ID, and I'm having trouble setting up 2fac. =\
For Windows, I don't think Microsoft has an option for them to notarize executables. Therefore, I'd need my own CA-signed certificate. Cheap certificates seem to be around 75$: https://cheapcodesign.com/codesigning/authenti-codesigning
One use case for code signing on all platforms: editor plugins can verify that ./node_modules/.bin/quick-lint-js
is really quick-lint-js and not some malware.
macOS code signing (codesign
)
Windows code signing (signtool
)
Linux has no de-facto executable signing.
Separate PGP signatures are common. We don't need the signature to be embedded into the executable.
For embedded signatures, there are several options, including:
(I didn't audit these solutions.)
Goal: Allow Vim plugin to use node_modules/.bin/quick-lint-js
.
Problem: Any npm package can create node_modules/.bin/quick-lint-js
. Also, any directory a user cd
s into might have node_modules/.bin/quick-lint-js
. node_modules/.bin/quick-lint-js
might not refer to a 'real' quick-lint-js.
Solution: Sign quick-lint-js with GnuPG. Have the Vim plugin verify the signature. The Vim plugin contains the public key. Problem: Need tools to verify GnuPG signatures. We could ask users to install GPG if they want this feature.
Solution: Sign with codesign
. Verify in Vim plugin.
Problem: Need tools to verify codesign
signatures. I don't know what this entails yet.
Solution: Sign with Authenticode. Verify in Vim plugin. Problem: Need tools to verify codesign signatures. Microsoft probably provides a C API. Can we access it from a Vim script? Maybe through Python?
Windows
Problem: Need tools to verify codesign signatures. Microsoft probably provides a C API. Can we access it from a Vim script? Maybe through Python?
macOS
Problem: Need tools to verify
codesign
signatures. I don't know what this entails yet.
I think that codesign
is installed on macOS by default. Xcode is not necessary. Therefore, I think we can reliably use codesign
to verify signatures.
I experimented with macOS code signing.
Question: Which of the following three methods for signing should we implement in the build system?
Problem: spctl
is rejecting qljs signed with my certificate from a self-signed CA. I don't know why:
Problem:
spctl
is rejecting qljs signed with my certificate from a self-signed CA.
I did get codesign
to verify the signature:
$ codesign -vvv -R="anchor trusted" build/quick-lint-js.signed
$ codesign -vvv -R="$(csreq -r='certificate leaf = "./dist/certificates/apple-dev.cer"' -t)" build/quick-lint-js.signed
(For some reason, I need a .cer, not a .p12, for file-based verification.)
I finally have a patch which makes CI sign executables.
However, I don't know how to make the signing secure (e.g. only for master
builds). I don't want drive-by PRs to steal the private signing key.
Perhaps we should sign during the build->release copy. That would fix security problems. But it would mean we're not testing signing on CI. (Maybe we could use a testing cert on CI?)
In commit 795efd95deb1b99585aa0d9874c877c1fe1cd04c, I implemented a build post-processing tool which invokes Apple's codesign
tool.
Commit 67358b99a8d16e18868d26545b723255a064a539 added signing for Windows .exe-s and .dll-s.
Commit 4158540a6eb393a66500d569ea31e7483f5459eb added signing for Linux executables and DSOs.
redo signing keys
Done in commit 455f110b51fd9fe3e2366189cb4ec6236cf4b46c.
editor plugins; source repo; etc.
Done in commit 5fa5003bf59319fb3da37397d29c23f64ebcd0d9.
Digitally sign the Windows and macOS executables we ship on npm.