On Fri, Jun 24, 2016 at 12:24 PM Chris Murphy <lists@colorremedies.com> wrote:

I'm not sure if this belongs in security@ or security-team@ so I've
just flipped a coin.

On macOS there are three distribution+security paths:
- unsigned, and the user is blocked from running the app by default
but they can disable this one time for that application installer or
for all installers
- dev signed, developer distributed
- dev signed, and Apple signed, App Store distributed

Dev keys are only available through the Apple Developer Program, and
only sign code through XCode. There is a way to sign code through a
3rd party but macOS treats it as unsigned, the user would have to use
the CLI to verify the signing of the binary.

There are details in here I'm not certain of, but there is a
qualitative difference in sandboxing of App Store distributed apps.
I'm not certain they can do privilege escalation. In order to image an
ISO to a USB stick on macOS I have to use 'sudo dd' to have the
privileges to write to a raw device.

As for compiling, I'm not totally certain it has to happen within
XCode on macOS, but the signing of the binary happens with XCode which
only runs on macOS. Primary development can happen elsewhere, but
eventually it gets built on Apple hardware, OS, and dev tools. A good
chunk of that is controllable by CLI.

I wonder if there's a way to ship this as a Docker for Mac container
instead? It's still beta, but uses HyperKit framework which is an
Apple provided library rather than depending on VirtualBox. So I'd
also consider evaluating this path since it may turn out to be the
path of least resistance for getting an initial tool on macOS.


Thanks for the info, it sounds like the macOS application really requires a Mac to build then as, at least in my opinion, Apple's signing process provides the users with the easiest workflow, and the highest level of assurance that the code is legitimate.

Can you also provide us information on the Windows build process?

Zach Oglesby