February 10, 2016

Techno Bits vol. 59: What If Packages Went Away Forever?

Good afternoon from London and the Mac Admins & Developers Conference, put on by Amsys at the St. James Theatre in the West End. We’re about halfway through the 2nd Day as this goes out, and I’m happy to report that this is a conference that I hope sticks around a good long time. It will definitely be back for another year in 2017, so start to register your interest and you can get 30% off for next year’s tickets

A Moment about Security

By now, you have read either 9to5Mac’s or ArsTechnica’s discussion of a major security flaw in the Sparkle update framework. You know that it affects anything running the Sparkle framework prior to 1.13.1 and definitely any package using an unsecured sparkle feed URI. An attacker in the middle, at that point, could replace the software you’d hope to have downloaded with Folgers crystals, or MacKeeper malware. Worse, the mere release notes contained in the upgrade information window, if transmitted insecurely, could reference a remote file and then instead of the latest update notes for Evernote, you might get some sort of weird puppy monkey baby hybrid.

This is bad.

Fortunately, the community is here to help you, and some nice folks, spearheaded by Allister Banks, has released a scripts called Extinguish that, through .mobileconfig profiles, will either force the update URL to SSL, or change the host name to 127.0.0.1 which will prevent updates from talking to the public internet.

Sparkle is one of those critical frameworks for the Mac that ends up many places because it is so easy to adopt, but the best practices guide for which is often ignored in favor of not paying $50/yr for a commercial SSL certificate. Yes, certs can be cheaper than that, and Comodo has a good $10/yr ident cert that is a solid offering for basic web hosting, and now Let’s Encrypt has a free option that you can integrate directly into your web hosting environment that will automatically renew your cert every 90 days.

This is a good time to stop and think about your security model. Are your client machines calling home to publicly accessible endpoints? Are they doing it in a way that is encrypted end-to-end?

Toward a Package-less Future

I had a conversation with someone in the pub this week, and that conference went like “What would happen if installer packages went away?”

I think that conversation is why I’m a little more hungover right now than I’d like to be. 

It’s entirely possible for Apple to make a single change in the OS and decide that only software that is signed by their development certificates would run on OS X, starting, say in OS X 10.13 in 2018. We would then have about two years to either sign every single package - a process that is not trivial, nor is it free - and that could spell some trouble for Mac Admins everywhere. 

Currently, I can think of several unsigned packages that I deploy on a regular basis. They include:

  • Gruntwork
  • Watchman Monitoring
  • Munki Tools
  • CreateUserPkg Users
  • Payload-free packages to deploy some settings scripts

If Apple were to move to signed packages only, there’s a future for the Mac admin using open source tools. We can all individually sign these packages through a central certifying authority with a $99 code signing cert from Apple. It’s a little arcane, but it’s doable.

But what if packages weren’t available at all?

Go ahead, open the liquor cabinet, it’s okay, I know it’s before noon, I won’t tell anyone.

How would that work? Well, deployment gets a lot more central, doesn’t it? Currently mobile device managers like Bushel, AirWatch, Casper, etc, can all place .app bundles, which all now contain all their own resources, and now the only way to deploy software is inside signed .app bundles dropped into the Applications folder.

If Server.app can create their very own version of the file system inside the .app binary and reference things that way, why can’t some other application do the exact same thing?

What’s the difference between .apps and .pkgs, from your perspective?

  • .apps store all their files within the bundle. You can’t put anything outside the bundle at that point. What needs that, really? Well, hardware appliances need to install drivers, and perhaps kernel extensions, so they can’t just be applications. Those are people that are going to have to spend time with Apple after this magical day to make sure they can put things into the OS in sane places.
  • .apps don’t interact with each other in the same way as non .app binaries. Due to sandboxing, applications can’t write to each others’ environments without granting entitlements.
  • .apps can’t do pre-install, pre-flight, post-install or post-flight scripts. But what are those for right now? Primarily fixing bad install practices, right? Sure, some places use them for licensing purposes, and some others do it to combine install with configuration. I suspect that any move that will require configuration of preferences will be accompanied by expanded support for the signed mobile configuration file change.

Right now, this is all a thought experiment, but there’s a very real possibility this will happen in 10.12 or 10.13, and I think we as an admin community need to begin to prepare for a world in which packaging is a past-tense activity. The good news is, this will stop applications like MacKeeper, or at least curtail their ability to royally mess up an OS X computer. Sure, some admins will refer to this as a “nerf computer” or worse, but this is the direction that Apple is going, and it’s past time we were ready for it.

Links To Read:

See you next week, assuming I survive the jetlag.