Prepare for autopkg Recipe auditing

Note: I am working on my next book ‘Automated Packaging for Apple Adminstrators’ and will cover this and other new features of autopkg v1.0 more in depth there. To pass the time until that book is published, get prepared with ‘Packaging for Apple Administrators’

A release candidate for autopkg v1.0 was released yesterday. As the version number implies, this is a big and important one.

Among a few other features, this release adds a new verb audit which checks a recipe and its parents for certain features which may have security implications. From the release notes:

New audit verb, used to output helpful information about any recipes that:

  • Are missing a CodeSignatureVerifier step
  • Use non-HTTP URLs for downloads
  • Supply their own processors and thus will run code not provided by AutoPkg itself
  • Use processors that may potentially be modifying the original software downloaded from the vendor

If you are hosting and sharing recipes, then there are a few steps you need to do to prepare for the release.

Once you have downloaded and installed the release candidate on your test machine, you can audit a recipe:

$ autopkg audit VMwareHorizonClient.download
    File path:        ./VMwareHorizonClient/VMwareHorizonClient.download.recipe
    Missing CodeSignatureVerifier

You can run audit against your entire repository with the find command:

$ cd ~/Library/AutoPkg/RecipeRepos/com.github.autopkg.scriptingosx-recipes/
$ find . -name '*.recipe' -exec autopkg audit {} ';' | open -f

This command pipes the output into TextEdit so you can review it better. You can of course pipe it into a file ( > audit.txt ) or your preferred text editor.

Then you have to work your way through the warnings.

Before you start working on fixes, you want to branch your repository, because some of the updated recipes may not work with older versions. You do not want to break your recipes until the final version of autopkg 1.0 is released. Remember to update the MinimumVersion value in your recipes.

There may be good reasons that you cannot fix all warnings. For example, there are a few products in my repository that aren’t signed by the developer, so I cannot add a CodeSignatureVerifier step.

I am not yet finished, but you can check out my branched recipe repository with the changes.

Here are a few notes as to what you may need to do:

Code Signature Verifier

Missing CodeSignatureVerifier

If the product you download is signed, you need to add a CodeSignatureVerifier Process to the download recipe. Read about this here: Using Code Signature Verification

Modifying Processors

The following processors make modifications and their use in this recipe should be more closely inspected:
        PkgCreator
        Copier

This warns of recipe processor that can change the content of what is downloaded. Of course in most cases this is intentional by the recipe author. However, the audit is merely warning you as a recipe user that you need to verify what is happening here.

As an author, you need to check if you can replace the common sequence of PkgRootCreator, Copier, PkgCreator with the new AppPkgCreator processor. This will not always be possible, but if you can this audit warning will go away (because AppPkgCreator does not change the content).

Insecure http URLs

    The following http URLs were found in the recipe:
        Input:
            DOWNLOAD_URL: http://download.ap.bittorrent.com/track/stable/endpoint/utmac/os/osx

Check if the software provider has secure https URLs instead.

Non standard Processors

    The following processors are non-core and can execute arbitrary code, performing any action.
    Be sure you understand what the processor does and/or you trust its source:
        Python3URLProvider

You will get this warning every time a recipe uses a Processor that is not part of the core processors provided by autopkg. If you use a custom processor to parse an URL and the version out of a website, you should check wether you can use URLTextSearcher instead.

Visual Studio on the Mac

At its heart, Visual Studio for Mac is a macOS counterpart of the Windows version of Visual Studio. If you enjoy the Visual Studio development experience, but need or want to use macOS, you should feel right at home. Its UX is inspired by Visual Studio, yet designed to look and feel like a native citizen of macOS. And like Visual Studio for Windows, it’s complemented by Visual Studio Code for times when you don’t need a full IDE, but want a lightweight yet rich standalone source editor.

Read more at MSDN

Introducing: Packaging for Apple Administrators

packagingcover-v1-0This is exciting!

TL;DR: I wrote and self-published an iBook: “Packaging for Apple Administrators”. Go get it on iBooks!

Call it arrogance or hubris, but I have been pondering to write a book on Mac System Adminstration for a long time.

Personally, I have learned much from other people in the community and at work. I have tried to give back in a similar way in the various fora, on this weblog and by participating and presenting at conferences. But there is something about a book, even in digital form, where you can spend so much more time with a topic than a blog post or even a presentation can ever do.

However, there is always something else that seems more important. Usually a full-day job to pay the bills.

Recently, however, something happened. My wife got a wonderful offer from a university in Europe. We decided we could not pass up on that and moved the family back over the Atlantic. That gave me an opportunity to reconsider what I care about in my job and career. All along this there was this nagging voice whispering: “If you don’t do it now, you never will.”

So I started writing.

This iBook is an experiment on many levels.

I went down several dead ends. I have re-written, put aside, and discarded more than will be published in the end. I guess that’s normal. Some of the pieces which cannot or will not be used now, are ‘parked,’ hopefully to be used later. Maybe they will only serve as a reminder of where I came from and will be good for a laugh later on.

It is an experiment on wether I can self-publish a book on Mac management. If you are reading this, this part succeeded, at least. It’s a start.

I decided to self-publish on the iBooks store. This will allow me faster turnaround times for debugging. It will also allow me to keep the iBook up to date as I learn more on the topic (which I undoubtedly will) and when the OS and other tools get updated.

I also chose to make the book comparatively short. It has about a hundred or so iBook pages. This will make it easier to update it for the unvoidable bugs and errors and also to adapt the book to future OS upgrades. I also hope it will make more palatable to read and work through and a bit less daunting.

It is an experiment on wether self-publishing a book like this to an extremely niche market (Mac administration) is worth the effort and can pay my bills.

This book is the result of months and months of planning, writing, back-tracking and starting over. I also hope that what I learned in the past months means that I can write and publish a next book much faster.

Because of the experimental nature, I chose a well contained topic. There are many other skills and topics for Mac Administration that can and need to be addressed and that I hope to be able to address in the future.

The topic I chose for the first book is ‘Packaging.’

Using, analyzing and building installer packages is very fundamental to a system administrator’s job. Every management system relies on packages to deploy software, files and scripts to some degree.

Many questions on the different Mac Administrator fora is answered with “put it in a package” with the common reply of “yeah, I really need to learn more about packaging.”

This is your chance!

This book will guide from analyzing packages and their contents to simple projects where you build your own packages. In the end there will be some failry complex packaging projects. The examples chosen are ‘real-world’ projects from my work as a system administrator. Some of the projects should be useful for your deployment right away. I also chose the examples so they cover a spectrum of problems and can be adapted to other problems.

If you are just briefly aware of packaging and scripting in the Mac community, you will have heard of autopkg and AutoPkgr. Originally I had planned to cover these in the first book (and much more). But the sheer versatility, complexity and and power of these tools would have delayed this book even more than it already is.

I do hope I get the chance to write that follow-up book. And many more.

Now go, get the book on iBooks!

Get it on iBooks

SSH-installer

Mac System Administrators regularly have to build and test installer packages. One of the best ways to test a package is to install it on a virtual machine. You can then quickly revert the VM to a snapshot after the installation and try again.

Since most package building happens on the command line, the fastest way to copy and install a package is with ssh. You can use scp to copy the pkg file and then run the installer command in an ssh session.

Doing two separate commands over and over seemed quite tedious. so I built myself a short script that combined both. ssh-installer takes two arguments, the first is the remote host in the form [user@]hostname (user is optional) and the second in the pkg file you want to send and install. All other arguments will be passed into the installer command on the remote host. You will probably want to add -target / in most cases. I did not add the -target as a default in case you want to test installer’s other parameters.

This script is just a shortcut for a task I have to do several times while building and testing packages. It is not in any way meant to serve as a means of managing Mac clients. You really should use a decent management system for that.