Introduction

As we experiment with secure enclaves, it seems more and more clear we're going to need to maOS entitlements. Which, as I understand it means launcher needs to, at least partly, be in an app bundle.

What's an app bundle

While app bundles are most commonly the full fledged macOS applications, they can be much simpler. As I understand it, at the very core they can be a directory, with an Info.plist and the existing macho binary stashed in the right place. This represents a fairly simple approach, and can live along side the rest of the pkg files.

This is the same minimal approach osquery took in osquery/osquery#7263. That PR isn't directly applicable -- it's all cmake, but it has some context.

Launcher and app bundles

For launcher, I see two paths. There's an interesting long term idea about replacing the pkg with an Application. But I don't think we should do that today. So instead I think theres a simpler path.

Today, we install as (And this includes the updates):

$ tree /usr/local/kolide-k2/ /etc/kolide-k2/
/usr/local/kolide-k2/
└── bin
    ├── launcher
    ├── launcher-updates
    │   ├── 1663913195
    │   │   └── launcher
    │   ├── 1665814654
    │   │   └── launcher
    │   ├── 1666157432
    │   │   └── launcher
    │   └── 1666416716
    │       └── launcher
    ├── osquery-extension.ext
    ├── osqueryd
    └── osqueryd-updates
        ├── 1660753700
        │   └── osqueryd
        └── 1660840403
            └── osqueryd
/etc/kolide-k2/
├── installer-info.json
├── installer-info.plist
├── launcher.flags
└── secret

Instead, I imagine we'd do something like:

$ tree .
.
├── bin
│   └── launcher -> launcher.app/Contents/MacOS/launcher
└── launcher.app
    └── Contents
        ├── Info.plist
        ├── MacOS
        │   └── launcher
        └── embedded.provisionprofile

Autoupdate

I think the trickiest part here, is going to be in solving how this works with autoupdate.

There are several potential issues:

1. There is a bunch of logic around how launcher finds the newest version of itself, this will need to be updated
2. The autoupdate code that untars launcher probably assumes it's a single binary, and not a simple directory
3. To preserve compatibility, this probably needs to happen on a different path. An older launcher pulling down a newer app won't know how to unpack or find it. So this means we'll need to name things differently in notary, as well as storing them separately on the filesystem. (But this is great, as we can probably move to using a flag value)