How Not To Go Insane In A Warehouse (or: replacing code signatures for fun and profit)

I spent most of last weekend in a warehouse in Carpinteria, spouting an ever more specific series of salty oaths and curses.

This isn’t – just so we’re on the same page here – the way that I normally like to spend my weekends. It’s terribly important to maintain a healthy work/life balance (particularly in These Trying Times), so keeping work and personal matters separate is important and a flagpole of mental health, and it’s vital to stay grounded and in touch with the people who are most important to you.

This is by way of saying that when I’m issuing salty oaths and curses on most weekends they are chiefly directed at my family, who are quick and open about returning them in kind.

Still, now and again the nature of honest toil involves going and working on a weekend, which is fine. A lot of substantive IT work gets done at hours when it’s less likely to cause massive disruption. Like most IT consultants, I’m no stranger to walking into a client office at 5pm and walking out at 8am the next morning. Or decamping to an onsite location for a weekend, for that matter. This is the nature of the gig; you can’t make fundamental changes to infrastructure while said infrastructure is being actively… infrastructed. It’s like repairing a car engine while the thing is hauling down the freeway. It can be done, but it’s not going to end well, there are going to be enormously destructive crashes that cost everyone a lot of money and time, and someone’s probably going to end up in the hospital.

So, last weekend should have been pretty straightforward. The migration from the client’s ancient and ailing Mac mini server to a nice, shiny new Synology NAS had been completed without incident – chiefly because Synology makes a solid, well-designed product – and all that was left to do was to install a remote access application on each Mac desktop so that the client could use their cloud-based accounting package. It was a simple matter of installing some applications, doing a little light configuration, then being home in time to sink a couple of cocktails replete in the general glow of a Job Well Done.

Except that, no, it wasn’t a simple matter. The remote access application flatly refused to launch on about half the Desktops for no discernible reason whatsoever. Same hardware, same exact operating system and patches, but while about half of them worked perfectly, the other half not only refused to launch but refused to even bounce in the dock.

This is unusual. Well-written applications either run just fine or give you some kind of polite-if-terse indication why they fail to do so. They don’t as a matter of course just sit there, unresponsive, glowering at you from the Dock while you wrack your brain and try and work out what’s wrong. A peruse of the showed an error message thus:

Termination Reason: Namespace CODESIGNING, Code 0x1

…which is the kind of thing that makes your blood run cold once you figure out what it means. Essentially, the program won’t run because the OS has decided that it either isn’t signed (see last week’s article on Gatekeeper) or because its signature is invalid. Downloading a fresh copy of the app from the Mac App Store made no difference, which pointed me in the direction of the OS thinking that the signature was invalid because anything you download from the App Store is, by the nature of the transaction, signed.

So, how to fix?

My first thought was that maybe – somehow – Gatekeeper on those Macs was somehow at fault. Other downloaded apps worked just fine, though, which rather scuppered that theory. My second thought was that maybe there was some issue with the app being flagged as damaged by the Macs, so I tried manually adding the apps to quarantine using xattr, like so:

sudo xattr -rd /Applications/Microsoft\ Remote\

(Spoiler – the app was Microsoft Remote Desktop).

Finally, I stumbled across the codesign command (installed as part of Xcode Command-Line tools). I’d run into it before while tinkering around with homebrew, and on reading the man page found that it had options for removing, altering, and replacing existing code signatures. Downloading the Xcode Command-Line tools can be done from the like so:

sudo xcode-select --install

The first move was to remove the existing code signature:

sudo codesign --force --deep --remove-signature - /Applications/Microsoft\ Remote\

Next, now that the existing signature has been removed, we can re-sign the app (using the --force flag to actually replace the existing signature and --deep flag to ensure that any sub-hosted code signatures are also replaced) by issuing the following command:

sudo codesign --force --deep --sign - /Applications/Microsoft\ Remote\

Thankfully, this worked like a charm, allowing all parties to return to their regularly scheduled weekend drinking. I mean families. Right? Right.

Leave a Reply

Your email address will not be published. Required fields are marked *