Wednesday, August 6, 2014

Code Signing Signature v2

Twitter and IRC have been ablaze this morning with chatter about OS X signed apps in Yosemite DP5. First to reach my eye was the twitter post from Graham Pugh
Apple explains...

"Beginning with OS X version 10.9.5, there will be changes in how OS X recognizes signed apps. Version 1 signatures created with OS X versions prior to Mavericks will no longer be recognized by Gatekeeper and are considered obsolete.

For your apps to run on updated versions of OS X they must be signed on OS X version 10.9 or later and thus have a version 2 signature."

Not being a developer by trade, I wasn't concerned with the implications of version 2 signatures for signing apps as much as I was curious as to how many of the current apps we deploy could fail. I'm unsure, and won't bother to confirm until Yosemite GM is released, wether or not Apple will block our unsigned or version 1 signed applications from launching. My guess is no, but we will see.

Until we have a Yosemite GM to test against, I wanted to get a cursory look at the signature version of all our applications. To do this, I adapted the shell one-liner of dirkg from the IRC ##osx-server channel. The one-liner provides a number of applications that are signed with version 1, version 2, or none:

find /Applications /Applications/Utilities/ -maxdepth 1 -name "*.app" | while read a ; do codesign -vd "${a}" 2>&1 | awk '/version/ {print $3}' ; done | sort | uniq -c

While this command helped me determine we have over a hundred applications signed with version 1 signatures, it didn't tell me which applications.

Introducing "", my adaptation that prints out both the application path and the signature version. 

Apple's documentation also references the spctl command for testing applications signatures. According to Apple's documentation spctl will "check if Gatekeeper will accept your app's signature".  Test your applications on the latest Yosemite developer preview with the following command:

spctl -a -t exec -vv

Tuesday, October 22, 2013

Mavericks Install USB

For the past few iterations of the OS X installer, we've had to take a few steps to create a bootable usb install drive. While this process has not been difficult, it has had generated a few blog posts on the subject. Erica Sadun provides a write up of a common method used to create the external USB install here. Greg Neagle has developed a way to turn the installer into a package for deploying with other tools, which  can be found here.

In the early days of development on Mavericks, Apple changed the install app causing the previous methods to fail. Another set of blog posts emerged with details on the process, including how to copy a folder of packages after restoring the InstallESD.dmg. Dan Desilva provided this Tips and Tricks article to help others navigate the deluge of folders and create a working Mavericks install usb drive for developers.

Now, with the public release of OS X Mavericks, Apple has provided a tool to create an usb install drive. Located within the "Install OS X" we can find the tool "createinstallmedia". Here's the full path (Watch for line breaks on the copy/paste):
/Applications/Install\ OS\ X\ 

Running the tool in the terminal provides us this usage statement...

Usage: createinstallmedia --volume --applicationpath [--force]

Arguments--volume, A path to a volume that can be unmounted and erased to create the install media.
--applicationpath, A path to copy of the OS installer application to create the bootable media from.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.

Example: createinstallmedia --volume /Volumes/Untitled --applicationpath /Applications/Install OS X

This tool must be run as root.

The binary takes three arguments when it is run, including the volume to place the installer on, the path to the installer, and the option to create it without any confirmation.

I ran the tool and, after a few minutes, was greeted by an Install OS X Mavericks drive on my desktop. Needles to say, I was giddy! It was very painless and quick, a nice change to the process I was familiar with. I can confirm that the usb installer worked on my test mini, and have no doubts about it's abilities to install the latest fresh juice squeezed from Cupertino.

Now it's your turn. Find an old USB drive and slap it into the closest Mac with the latest 10.9 install app. Fire up your terminal and make your own, you don't really need 32 gigs of fish stick recipes, do you?!

sudo /Applications/Install\ OS\ X\ --volume /Volumes/FishStickRecipes --applicationpath /Applications/Install OS X

I love not having to open Disk Utility and copy folders around. This tool makes this admin very happy!

Wednesday, March 13, 2013

OS X Mountain Lion Screensaver at the Loginwindow

With the release of OS X Mountain Lion (10.8), Apple discontinued supporting custom slidesavers over the loginwindow. Prevously, on OS X Lion, we used an existing slidesaver and modified it to fit our needs as document here:

Moving ahead with Mountain Lion requires that we take another look at how we configure the loginwindow screensaver. If you're not interested in doing things using the Apple way, you may like the prepackaged solution provided by University of Utah called "10.5 Logout Saver Screen Preserver":

If you're still interested a way to use a folder of images as a screensaver for OS X Mountain Lion and you don't want to install extra XHooks stuff, keep reading...

The basic crux of the issue is that there is no GUI for configuring the loginwindow screensaver to use a folder of images. In fact, there isn't any documentation from Apple, that I can find, to configure the loginwindow screensaver. To configure the screensaver we'll have to use the System Preferences GUI and the terminal, so lets get started!

The first step involves configuring the screensaver inside a user account. This is the simplest of the steps and as such I won't go into much detail. You open the Screen Saver preference pane and select a folder of images to use. That's it, just remember to set the users screensaver back to whatever you would like it to be when you're done.

Now that you've selected the folder, two new files have been created for your user. These two files, named & (Where GUID is your machines ByHost identifier), hold settings that configure the "iLifeSlideshows.saver". The "iLifeSlideshows.saver" ends up being the replacement to your custom slidesaver from the previous OS. Instead of the system using your slidesaver, it uses the iLifeSlideshows.saver and looks for the aforementioned preference files to determine which folder of images should be shown. The System Preferences writes these preference files to /Users/username/Library/Preferences/ByHost/. Find them and copy them to /Library/Preferences now, I'll wait here.

So, now that we've got those two files moved to /Library/Preferences, you should rename them to remove the ByHost GUID. You will end up with file names /Library/Preferences/ & /Library/Preferences/ Lets take a look at these and modify them to our needs. 

To view the files we can use the defaults command. In the type this:
defaults read /Library/Preferences/
defaults read /Library/Preferences/ 
 Our first file "" shows this:

    CustomFolderDict =     {
        identifier = "/Library/Preferences/Slides/edu.psu.slides";
        name = "edu.psu.slides";
    LastViewedPhotoPath = "";
    SelectedFolderPath = "/Library/Preferences/Slides/edu.psu.slides";
    SelectedSource = 4;
    ShufflesPhotos = 1;
We can see that the preference file has the directory of images that we set in System Preferences. We can also see a few other keys are set. If you want to change the path to the slides, you could do so by editing the SelectedFolderPath and identifier under the CustomFolderDict. Hopefully we've got those set correctly and can move on. In my testing, I found that the SelectedSource key and CustomFolderDict were unnecessary. LastViewedPhotoPath is auto generated, so really the only keys needed are SelectedFolderPath and ShufflesPhotos. Your milage may vary.

The second file "" shows this:
    spansScreensKey = 0;
    styleKey = Classic;
The spansScreensKey, I assume, tells the screensaver to show on multiple screens. I've not yet tested this. The styleKey seems to be the way in which the photos appear. One of the alternate styleKeys is "Flipup". I'd like to collect more here, eventually.

Now that we've modified the two files from our user account, we need to tell the system to use the iLifeSlideshows.saver at the loginwindow, as well as how long to wait before doing so.
Check to see if you've already got a "" with this command:
defaults read /Library/Preferences/
Chances are you've not got one. That's fine, we can make one very easily. To configure the system to use the "iLifeSlideshows.saver", which will show our folder of images, we can use this defaults command:
defaults write /Library/Preferences/ loginWindowModulePath "/System/Library/Frameworks/ScreenSaver.framework/Resources/iLifeSlideshows.saver"
Careful of line breaks when copying and pasting, check before you hit enter!

Once we've got the correct screensaver chosen, we need to tell the system how long to wait before activating the screensaver over an idle logininwindow. Use this command with the number of seconds to wait:
defaults write /Library/Preferences/ loginWindowIdleTime 60
Hopefully it makes sense to you that this would set the loginwindow to show the screensaver after 1 minute. 

Now you can restart your machine and your folder of pictures should appear over the loginwindow after a minute of being idle! Try packaging the files and picture folder for making the deployment easier in the future.


Enable screensaver with these three preference files and a folder of images at /Library/Preferences/imagefolder/:

File: /Library/Preferences/
    loginWindowIdleTime = 4;
    loginWindowModulePath = "/System/Library/Frameworks/ScreenSaver.framework/Resources/iLifeSlideshows.saver";

File: /Library/Preferences/
    SelectedFolderPath = "/Library/Preferences/imagefolder";
    ShufflesPhotos = 1;

File: /Library/Preferences/
    spansScreensKey = 0;
    styleKey = Flipup;


Different StyleKeys:
  • Classic - Images appear centered
  • Flipup - Images flip into place in front of previous pictures

Tuesday, February 19, 2013

VMWare Fusion and system_profiler fail

One of the newest additions to my toolset is VMWare Fusion 5. While I've attempted to use VMs in the past for development and testing, I've never really liked the environment. It always seemed slow and difficult to manage when I attempted to bend it to my needs. Luckily, I've had plenty of spare Macs to test on when needed.

I decided to give the tool another shot, as I really think the rollback feature would be helpful when testing software packages. It certainly seems quicker to revert to a snapshot instead of re-installing the OS every time I need to test an installer.

I started my test of VMWare Fusion 5 by booting from a USB drive to restore an OS disk image. I followed this article from VMWare on booting from an external USB drive. Once completed, the machine rebooted as I expected. However, what I didn't expect was the failure of my first boot script to correctly install a few packages.

Looking closer at the logs, I noticed that my script used this line to set the internal drive variable "HD_Path", which is used to tell the installer command the path to install the packages to:
HD_Path=`system_profiler SPSerialATADataType|awk -F': ' '/Mount Point/ { print $2}'|head -n1`
(Side Note: The above command has always worked to get the internal disk of a Mac, even when multiple internal and external disks were present OR even if booted from a the network!)

Running the system_profiler command in the terminal of the virtual machine showed me why it failed. Because "system_profiler SPSerialATADataType" returns blank for virtual machines! I found a bug posted here from 2008 that discusses the problem, but does not provide a solution.

So, I may still try to find a place that using VMWare works for me, this doesn't seem to be it. I am not currently wanting to re-writing scripts just to take advantage of snapshots, although I may find it necessary eventually.

If you're in this spot, try using tools like 'diskutil list' and 'df' to get the disk lists.