I just stumbled across the "Unable to enumerate all disks" problem launching a VM on an VMware ESXi host. Looking for the solution to this problem proved inconclusive, but eventually I found both reasons:

• not all delta-chains of snapshotted disks had been properly reassambled!
  • that's probably a bug which was triggered by an after-the-fact setup change done by me (converted disks to independend-persistent after snapshots had taken place). It's probably best to always clone the drives when changing your mind.
• not all snapshot references had been properly cleaned up in the VM's .vmsd file - this also seemingly means that the drive references therein cannot be enumerated!

Note that a vim-cmd -d trivia vmsvc/power.on <vmid> command didn't produce any useful log!

It seems the IETF Tools are mostly gone now, but I needed msglint to validate a bug in Ristretto… and found it on GitHub: msglint

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).