➜  osquery git:(macos_app_bundle_package_data) pwd
/Users/sharvil/code/osquery/build/package_data/opt/osquery

➜  osquery git:(macos_app_bundle_package_data) tree
.
├── bin
│   ├── osqueryctl
│   ├── osqueryd
│   └── osqueryi -> osqueryd
└── osquery.app
    └── Contents
        ├── Info.plist
        ├── MacOS
        │   └── osqueryd
        ├── PkgInfo
        ├── Resources
        │   └── osqueryctl
        └── embedded.provisionprofile

5 directories, 8 files

@directionless this creates a simple app structure alongside the other package_data

Updating the packaging repo next

Can we have it so that the osqueryd binary is only installed into the app bundle?

Can we have it so that the osqueryd binary is only installed into the app bundle?

I'm good either way, but I want to note that if we do that, end users will not be able to get a bare signed osqueryd. Only the app bundle. (Moving the binary out invalidates the signature)

Can we have it so that the osqueryd binary is only installed into the app bundle?

Yeah, we can just remove the earlier install directive here

But as per @alessandrogario's comment, I am keeping most of package_data consistent across platforms, but just dropping the app bundle alongside on macOS. I am also good either way

Where is the signature data stored when you sign an app bundle?

Is it possible to sign the binary, then sign the outer app bundle?

Is it possible to sign the binary, then sign the outer app bundle?
Yes that is possible. You probably want to have identifier org.osquery.osquery for the app bundle, and org.osquery.osquery.daemon for the binary.

Where is the signature data stored when you sign an app bundle?

Is it possible to sign the binary, then sign the outer app bundle?

For the .app bundle it's stored in _CodeSignature/CodeResources inside the app bundle, this gets created when codesign is run. For the binary it's stored inside the Mach-O segment

Is it possible to sign the binary, then sign the outer app bundle?

yep, @directionless already did that

Is it possible to sign the binary, then sign the outer app bundle?

I don't think so. I think the outer signature overwrites the inner. Using one of the app bundles from a CI build (ignore the notarization errors)

# Existing sig, invalid in app bundle, valid outside it:
$ /usr/sbin/spctl -a -vvv  --ignore-cache osquery.app/Contents/MacOS/osqueryd 
osquery.app/Contents/MacOS/osqueryd: code has no resources but signature indicates they must be present
$ cp osquery.app/Contents/MacOS/osqueryd osquery-one
$ /usr/sbin/spctl -a -vvv  --ignore-cache osquery-one 
osquery-one: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: OSQUERY A Series of LF Projects, LLC (3522FA9PXF)

# signed app bundle, valid inside but not outside:
$ codesign -s "3522FA9PXF" --force --entitlements /tmp/pd/control/osquery.entitlements   --options runtime -v --timestamp osquery.app
osquery.app: replacing existing signature
osquery.app: signed app bundle with Mach-O thin (x86_64) [io.osquery.agent]
$ /usr/sbin/spctl -a -vvv  --ignore-cache osquery.app/Contents/MacOS/osqueryd 
osquery.app/Contents/MacOS/osqueryd: accepted
source=Notarized Developer ID
origin=Developer ID Application: OSQUERY A Series of LF Projects, LLC (3522FA9PXF)
$ cp osquery.app/Contents/MacOS/osqueryd osquery-two
$ /usr/sbin/spctl -a -vvv  --ignore-cache osquery-two 
osquery-two: invalid resource directory (directory or signature have been modified)

I'm not sure how many people want a bare macho binary. My gut sense is that that's only something wanted by some vendors. I'm willing to ship both, or just the .app

Notarization is for apps, so spctl -a should fail when checking the binary outside of the notarized app folder.
However, the codesign -dvvv on the binary should be valid even if copied outside to another location.
Vendors could copy osqueryd from official releases inside their own app bundle and get it notarized.

To summarize, if you release just the notarized osquery .app, it should work for everyone, as long as the binaries inside are code signed as well.

Notarization is for apps, so spctl -a should fail when checking the binary outside of the notarized app folder.

No, this is not correct. macho binaries, when then have the quarantine bit set, also must be notarized. My example showed notarization errors, because I didn't want to submit them to apple and wait for the test case. The plain signature was enough to show what was happening.

I don't think the codesign -dvvv output is easy to read, and IMO tends to mask errors. But the -vvv output:

$ codesign -vvv osquery-one 
osquery-one: valid on disk
osquery-one: satisfies its Designated Requirement

$ codesign -vvv osquery-two 
osquery-two: invalid Info.plist (plist or signature have been modified)
In architecture: x86_64

Does this need the sha from osquery/osquery-packaging#11 ?

Does this need the sha from osquery/osquery-packaging#11 ?

Yeah, I can change it here, give me a minute.

As I just commented in slack:

So, conclusion from office hours:

1. We should ship a signed .app. This is what should be in the pkg. This is the expected and common path
2. There are some folks who use bare macho binaries. Both Kolide and Fleet, for example. While both of us can sign binaries ourselves. I think there’s some value in shipping an osquery signed one. Specifically because I’m seeing some other vendors ship modified osquery binaries and claim it’s stock. So I want a better chain of custody,
3. A shipped, bare, macho binary should not be in the pkg, and should not be an obvious download from the downloads section of the website. It is very much an advanced tool, akin to the debugging symbols.

I’m not sure what that means for the existing PRs sharvil has in flight. I’m not sure osqueryd should be in package-data/opt/osquery/bin/osqueryd, since that should be the symlink. I think there’s some nonsense to work through