Mac Signing and from-scratch Perl

Who compiles their own Perl from source in the age of Fink and Homebrew?

Well, sometimes there is no way around to having the latest and greatest, and that means compiling from source. Just make extra sure to use a separate directory, and never overwrite your Mac's system Perl in /usr/bin. If you do, suffer dire consequences the next time you boot, and LWP's HEAD has just replaced the system tool head, because HDFS+ is case-ignorant by default. As you can tell, I am speaking from experience. But I digress.

When you freshly compiled a new perl using a prefix like /opt/perl, every single time you execute the new perl will add a line to your system.log file nagging about code signing like this:

Apr  3 19:12:56 xxxxxxx kernel[0]: CODE SIGNING: cs_invalid_page(0x103687000): p=96914[perl] final status 0x2000000, allowing (remove VALID) page
Apr  3 19:12:56 xxxxxxx kernel[0]: CODE SIGNING: cs_invalid_page(0x101cca000): p=96915[perl] final status 0x2000000, allowing (remove VALID) page
Apr  3 19:12:56 xxxxxxx kernel[0]: CODE SIGNING: cs_invalid_page(0x10be43000): p=96916[perl] final status 0x2000000, allowing (remove VALID) page

It will still work. But the first thing you do after a perl installation is to update your CPAN module. Every single test will start another Perl. You see where this is going. Most users don't notice, but I am all against having stuff appear in my system.log that is not necessary.

The easy way out is to tell your Mac OS X to permit downloaded code from any source. But that feels too permissive. Such a move would completely disable any security that was intended by code signing. I am no fan of opening the barn gates this wide.

A better way is to work with the code signing framework. But how to tell the gatekeeper that this compilate is OK, and should not be shouted at?

One way is to splurge $99 every year for a Mac OS developer account. The developer account will come with a developer identity that can be used for code signing. A developer account may be worthwhile for developers selling applications. The specific steps can be found elsehwere. However, I can be cheap.

Trolling the manual page for codesign, I noticed that it permits something called ad-hoc signing. Now, it appears as if the act of installing the Perl binary somehow messes up the signing it already received. In my case, when checking the installed version of Perl, I got:

$ codesign --verify --verbose /opt/perl/bin/perl 
/opt/perl/bin/perl: invalid signature (code or signature have been modified)
In architecture: x86_64

This tells me that the gatekeeper does not like something. So, I set out to fix it. Additionally, since I am using a libperl shared library, I thought to sign that one, too, just in case. That may have been overkill:

$ codesign -f -s - /opt/perl/bin/perl
$ codesign -s - /opt/perl/lib/5.20.2/darwin-thread-multi-2level/CORE/libperl.dylib

The first line ad-hoc signs the freshly installed perl, replacing whichever prior certificate it had. It had something, but that was somehow messed up. The second line signs the libperl shared object, which was not signed to begin with. Thus, it does not require the -f argument.

After the ad-hoc signing, my syslog.log file quieted down with regards to the gatekeeper complaining about Perl. And I didn't have to disable the gatekeeper.