Beats MacOS Packages, distribute as pkg not tar.gz

[jasonslater2000]

Beats' macOS packages are distributed as a tarball (not a .pkg)

Tarballs are not ideal and a true installation package file (i.e. a .pkg file) is the preferred method of packaging software for distribution to macOS devices. Distribution of a .pkg file is ubiquitous across the macOS ecosystem and should be considered the "gold standard" for macOS applications (so much so that there have even been entire books written on the topic). While a tarball technically "works", it does not abide by canonical standards of macOS package installation for a few different reasons (one of which being that a tarball does not "drop" a package receipt -- a .bom file ["Mac OS X bill of materials (BOM) file"] and a .plist file -- within /private/var/db/receipts directory during/after installation). Package receipts are heavily relied upon by macOS administrators across the globe as they provide a means by which one can easily discern which packages are installed on a given machine, what the exact contents of that package were, the package installation date/time, as well as the package's PackageIdentifier and PackageVersion.

With the tarball-based packaging procedure in-use by Elastic today, we (administrators of large fleets of macOS devices; in our case, a fleet size of over 20k Apple machines) are not inherently afforded these bits of package metadata and, in turn, requires us to exert additional (and unnecessary) effort to accurately determine these attributes of Beat installations.

Going off of #1 above, it is common practice to both codesign and notarize a package before distribution to ensure that Gatekeeper -- one of macOS's native security measures -- does not flag the software as malicious as well as ensuring that a "quarantine bit" does not get associated to the binary.

To be fair, it seems that Elastic is currently codesigning and notarizing the executable binary within the distribution tarball:

Check for codesignature on metricbeat binary

$ codesign --test-requirement="=notarized" --verify --verbose ~/Downloads/metricbeat-7.10.2-darwin-x86_64/metricbeat
/Users/me/Downloads/metricbeat-7.10.2-darwin-x86_64/metricbeat: valid on disk
/Users/me/Downloads/metricbeat-7.10.2-darwin-x86_64/metricbeat: satisfies its Designated Requirement
/Users/me/Downloads/metricbeat-7.10.2-darwin-x86_64/metricbeat: explicit requirement satisfied
$

Check for notarization on metricbeat binary

$ spctl -a -vvv -t install ~/Downloads/metricbeat-7.10.2-darwin-x86_64/metricbeat
/Users/me/Downloads/metricbeat-7.10.2-darwin-x86_64/metricbeat: accepted
source=Notarized Developer ID
origin=Developer ID Application: Elasticsearch, Inc (2BT3HPN62Z)

Given that Elastic is seemingly already performing these codesigning and notarization processes on the binary, it should be trivial to implement this on a "true macOS package" (should Elastic decide to start composing Beats packages as .pkg files as I am suggesting).

[elasticmachine]

Pinging @elastic/agent (Team:Agent)