In case you are making macOS Installer packages and doing that since ages, you should take note of the following passage from the productbuild man page and revisit your Distribution files:

NOTE: On Apple Silicon, the macOS Installer will evaluate the product's distribution under Rosetta 2 unless the arch key includes the arm64 architecture specifier. Some distribution properties may be evaluated differently between Rosetta 2 and native execution, such as the predicate specified by the sysctl-requirements key. If the distribution is evaluated under Rosetta 2, any package scripts inside of product will be executed with Rosetta 2 at install time.

Although it seems awkward at first, this is indeed necessary - any "script" might as well be a binary instead which in turn might require Rosetta 2 (as it's probably not Universal, which is typical for old Installer packages).

In case you're creating the Distribution files manually, the options XML element has a hostArchitectures attribute which lets you specify the exact requirements.

Thanks to Randy Saldinger (Mothers Ruin Software) for letting me know

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 independent-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