Marcus Müller a.k.a. "Tethpub ZNeK"



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 emoji people:wink


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:

This gives:

$ osslsigncode sign -verbose -h sha256 -t -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

Height:165 cm
Weight:68.0 kg
Tattoos:not a single one
Piercings:not even that
Occupation:Independent IT contractor, Musician


Popular software
iTunesFS 2.0.0

⚽🇩🇪Deutschland-Ukraine (Benefizspiel)
Monday, June 12, 2023 18:00 CEST
(in 15 days)

Fortune cookie
Labor, n.:
One of the processes by which A acquires property for B.
-- Ambrose Bierce, "The Devil's Dictionary"
another cookie!