Hey folks, my name is Luqi and I work at Apple with several other folks on osquery efforts. We're very interested in seeing official support of osquery on ARM become a reality and my understanding is that you folks are very much interested in it as well. We recently learned that folks at AWS are willing to provide engineering resources and compute credits to help with this goal, specifically CI for osquery on ARM. (Thank you AWS for the generous offer!) Would you all be interested in a meeting to discuss how do we make this a reality? I'm in no way familiar with the development process in osquery land but maybe we can target official support of osquery on ARM for 4.8.0 release?

affirmative, I can be a point of contact for community, although you're in good hands with @Ali Saidi

I'd be happy to attend a meeting regarding this, however others you've mentioned are more qualified. Perhaps consider me a backup?

I think @Marcello Golfieri was also tracking this; and yeah it would be cool to schedule a meeting with the tagged people 🙂

Yes @Marcello Golfieri is also working on this from the AWS side, happy to help

Thanks for the tag Alessandro. Hey @Marcello Golfieri, didn't realize you're here as well 😛

Hi folks! I'm super psyched for folks help. I'm in the midst of child bedtime, but I generally have east coast availability.

The benefit i see from another CI is just that they’re already doing the lifting for setting up the infrastructure so we don’t have to focus on that but it requires two CI setups.

I wouldn't mind to have a second CI to maintain if that's the best tool for the job (I haven't looked into how the GitHub Actions runner perform on ARM64, so refer to @seph for this)

@seph and @alessandrogario is something like this tenable: https://github.com/machulav/ec2-github-runner it seems to have very few moving parts

I'd love to see us keep to 1 CI just to limit the spread of the codesigning keys. I trust y'all to make the best decision though.

The codesigning workflow we have prepared will remain on GitHub Actions, so it wouldn't be affected by a second CI (we just need to be able to download the artifact and we are good)

@theopolis the trick is dealing with fact that given it’s a public CI service testing every PR someone can send a PR that tries to read a secret on the machine or something similar that have to be managed. The services that offer managed runners deal with these issues for us.

I don't think we have any secret on the public CI, we have moved everything in a separate private repository that only the TSC can access to launch the final packaging and codesigning process

I can look at

ec2-github-runner

though the current thing I’m playing with is also pretty similar.

The thing you’re currently playing with looks pretty good @seph. If we really want a single CI seems like a good way forward and we should just pile on make it work.

@Ali Saidi that makes sense, I can try to set up that runner workflow in a test repo and intentionally land a shell into the runner to see if secrets are exposed.

you need the secrets to register with github when the service starts initially, but then i assume they can be deleted (except for how to stash the output).

Would it be helpful if folks from AWS built a PoC that kicks off osquery tests on EC2 Graviton with

ec2-github-runner

?

@Ali Saidi That matches my understanding.

@seph has been using something around https://github.com/envoyproxy/ci-infra which is another starting point

Okay, I just pushed my current work in progress to https://github.com/osquery/infrastructure/pull/7 It is very much a draft.

Got it. Maybe folks from AWS can build on top of https://github.com/osquery/infrastructure/pull/7 and fill in the gaps?

Yes, I’d love that. Though I would want to be pretty clear in what’s happening and coordination lest we step on each other.

(But my vote is always for the simplest and safest solution to start out, then we can iterate and consolidate if needed)

It’s different axis of simple. I think either we put complexity into an AMI to manage a runner. Or we put complexity into maintaining 2 CI systems.

For sure, I think we can coordinate here to avoid stepping on each other's toes @Ali Saidi @Paul Roberts @Marcello Golfieri what do y'all think ^?

I’m not opposed to using AWS codebuild either — mostly I’m trying to do what I think has less general overhead? Are there macOS and windows options for codebuild?

We're open to the community's feedback. If AWS can make things easier to help automate the ARM builds then we're willing to help.

Absolutely. Amen to that

should we create a channel for discussing this further?

I’d say just use #infrastructure or this one