Codesigning of Windows PE files was giving me headaches due to SignTool causing issues with signal handling in a remoting context. There's probably a way to solve them, but the question arose, "Why bother but instead sign the executables on macOS"?

Turns out it can be done:

• Code signing Windows apps on Unix
  • brew install osslsigncode
  • Timestamp server change

This gives:

$ osslsigncode sign -verbose -h sha256 -t http://timestamp.digicert.com/ -pkcs12 /path/to/cert.pfx -pass 'secret' -in /tmp/unsigned.exe -out /tmp/signed.exe
$ osslsigncode verify /tmp/signed.exe

Things to note:

• unfortunately osslsigncode cannot sign in-place (meh!)
• you don't really need a pkcs11 cert and handler, your existing pkcs12 cert might work as well
• bonus: this will work on any Unix flavor and isn't restricted to macOS

Turn off bracketed paste (at least on Linux):

$ cat ~/.inputrc 
set enable-bracketed-paste 0

After upgrading the Jenkins instances I stumbled across this problem on an old Ubuntu build agent:

using GIT_SSH to set credentials This is jenkins
Verifying host key using known hosts file, will automatically accept unseen keys
 > git fetch --tags --force --progress -- git@mulle-kybernetik.com:gs-build +refs/heads/*:refs/remotes/gs-build/* # timeout=10
ERROR: Error fetching remote repo 'gs-build'
hudson.plugins.git.GitException: Failed to fetch from git@mulle-kybernetik.com:gs-build
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:1003)
	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1244)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1308)
	at org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:143)
	at hudson.scm.SCM.checkout(SCM.java:540)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1217)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:647)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:85)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:519)
	at hudson.model.Run.execute(Run.java:1899)
	at hudson.matrix.MatrixRun.run(MatrixRun.java:153)
	at hudson.model.ResourceController.execute(ResourceController.java:107)
	at hudson.model.Executor.run(Executor.java:449)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- git@mulle-kybernetik.com:gs-build +refs/heads/*:refs/remotes/gs-build/*" returned status code 128:
stdout: 
stderr: command-line line 0: unsupported option "accept-new".
fatal: Could not read from remote repository.

As it turns out, the accept-new option is provided to ssh via the git plugin in order to accept yet unknown host keys (which supposedly makes life easier), but doesn't work for OpenSSH < 7.6.

The solution is to set GIT_SSH_COMMAND to ssh as an environment variable on the build node (via its configuration).

I had to migrate several Jenkins instances due to new Java requirements . All of these instances run on current FreeBSDs (13.1), so no problem on that side. The agents however need the same JRE as the servers which poses a problem for old (and outdated) build machines running macOS up to 10.13... I wasn't able to build a Java 11 version out-of-the-box on these, so I had to decommission them. For macOS 10.14 I got lucky: Microsoft (!) provides builds of various OpenJDK versions not only for Windows, but for macOS (and Linux) as well.

If you ever wondered if you can use an Apple M1 Mac Mini as a build agent for Jenkins by now, the answer is YES!

Homebrew (brew) does work reliable and it also has a bottle for java11 (java16 doesn't work!) that you'll need as the JRE for the agent.