YouTube Link: https://youtu.be/qKTKktZ_tqo
Zach is going to talk at osquery@scale tomorrow, about eBPF and the future of osquery on Linux! If you don't have a ticket already, you are missing out!
Teddy is speaking!
We have github actions, but we have to protect the signing secrets.
The current mockup here involves a separate repo https://github.com/osquery/osquery-codesign
This is currently a private repo to reduce the likelihood of outside interference. seph is interested in having this become public.
Workflow (proposed, not all implemented)
- When started, gets tag from the input
- finds artifacts by tag
- downloads to working directory
- (signging should happen here)
- puts signed packages on the release tag
Package signing has some wrinkles -- We need to unpack, get the binary, sign, repack, sign. This might change later, but it's the manual process we do today, and we want to stick with what works.
Discussion about how we want to have a single packaging workflow, so that we can create non-codesigned packages and codesigne dones using the same workflow
We still need to create a developer profile for CI, so we can bake signing in. Also need to resolve whether the 'device ID' for a CI runner is static, because developer-signing requires a device ID to be pre-provisioned with Apple and added to the profile.
GitHub actions uses a docker container coming out of ToB. This installs packages similar to what's in the wiki, and in CI.
seph and Stefano are chatting about github docker registry.
We should be able to do this, but it'll need to happen on the docker images.
Kolide is running it in their beta fleet. No issues, so we're removing the "pre-release" tag, and declaring it stable.
Teddy asks if people can test osquery/osquery#6850 with more rpm based linuxes
Zach can look
We can set the SDK and minimum version separately.
We'd like to upgrade the minimum version, so that we can use the available
macros.
Our minimum is currently 10.11. But we need to update this because we need weak linking. It's worth noting that even testing on 10.12 is very hard, since we cannot easily
Using macOS 10.12 as the deployment target is needed for weak linking, for availability macros, for building the table that exposes the Unified Logging log, etc.
(If there's time, we've been trying to re-visit old PRs)