https://github.com/osquery/osquery logo
Title
s

sundsta

09/18/2020, 7:39 PM
I've noticed release build issues have popped up a few times. Is there any reason we don't just have the CI build it upon pushing a
vX.Y.Z
tag?
s

Stefano Bonicatti

09/18/2020, 7:51 PM
@sundsta Technically it's already building them at each commit of a PR or commits that land on master. The main problem was where to store them, although it should be possible to have some artifacts published/attached to a build result (which then expires in 1 month or so). I don't recall though how the access to it looked like, as in if it required to have an Azure account that's in our organization (ToB still handles the CI side). But then also signing is an issue and a WIP.
t

theopolis

09/18/2020, 7:55 PM
I would love for CI to build packages and publish them. There are 'broad strokes' happening that gets us closer to this, for example moving the repo and package hosting to an osquery foundation controlled AWS account (vs, previously hosted by Facebook). The next big step would be creating an Azure pipeline to publish to some temporary storage that we can inspect and iterate with. I am not sure if anyone is currently working on this. I would love to invest time since package publishing takes a considerable amount of my time right now.
s

sundsta

09/18/2020, 7:56 PM
You can store them in the azure pipelines artifacts, or you could also push them to a S3 bucket. We could also have automatic signing if everyone is OK with having the signing keys and their unlock pass phrases as secrets in the CI.
I have done similar previously for building Launcher in devops pipelines and then using the
package-builder
to create win/mac/linux installers. I didn't add a signing step at that time, but we have done this for some of our other tools and have documented how to automate it all
t

theopolis

09/18/2020, 7:58 PM
We could also have automatic signing if everyone is OK with having the signing keys and their unlock pass phrases as secrets in the CI
I am OK with this in practice but I would like to see some examples of how others do it. Do you know of other projects that do something similar?
Is there a .yml I can look at?
s

sundsta

09/18/2020, 8:00 PM
I don't have the documentation handy, but I can follow up early next week
👍 1
a

alessandrogario

09/18/2020, 8:14 PM
I think that for signing we were thinking about using a separate repo where only people that have access to the signing key can push
so there is no risk of having a malicious PR leak the key
for storing the packages, I think the biggest problem was getting the storage itself (I think @seph was looking into buckets we could use)
s

seph

09/18/2020, 8:18 PM
Storage we kinda have a story for now…
The couple of things that tripped me last time:
1. Azure makes me cry. Almost literally. It’s just intensely painful to work in. I did some initial work to try github actions, and got trippped on some tests failing
😂 1
2. cpack is hard for me to use. I’m not sure how to work through this one. Maybe just azure shoving things into s3, and then something else? I’m not really sure.
a

alessandrogario

09/18/2020, 8:20 PM
I did work with GitHub Actions for (exactly) two projects (not much experience, I know!). if you have a branch somewhere maybe we can help
The github side is trivial. The test failures are probably skew in VMs. I should revisit this.
Moving off ToB azure seems important, but not pressing.
And, TBH, I need to open this apple silicon dev kit.
:mind_blown: 1
s

sundsta

09/18/2020, 8:25 PM
For my understanding, what is ToB?
a

alessandrogario

09/18/2020, 8:25 PM
Trail of Bits!
:trailofbits: 1
s

seph

09/18/2020, 8:25 PM
Trail of Bits (the employer of several people here).
s

sundsta

09/18/2020, 8:26 PM
Ah, of course!
s

seph

09/18/2020, 8:26 PM
So I dunno. How would we setup cpack to do signing? Is it possible to split the build from the packaging? If so, we could shove the artifacts from the cmake build somewhere, and ingest them for a cpack sign?
s

sundsta

09/18/2020, 8:27 PM
Well, on Win/Mac signing is two parts. First, sign
osqueryd
, then you have to insert it to the MSI/PKG, and then sign the MSI/PKG. And of course notarize the PKG as well
s

Stefano Bonicatti

09/18/2020, 8:27 PM
Sure, packaging is a separate target and a separate CMake file which is in the end optional (just need to remove a line that includes it).
a

alessandrogario

09/18/2020, 8:29 PM
backstory, because it may seem weird we have the CI under ToB: after the Buck refactor we no longer had any CI here in the osquery repo. We made a fork to add back CI support with CMake which eventually landed here upstream
s

Stefano Bonicatti

09/18/2020, 8:29 PM
That wouldn't be a problem either. We can leave the packaging we have right now connected to the project, so that for test one can install unsigned packages. That can also output already a tgz which could be uploaded to this other place, where the second repo we were talking about manages eveything
s

seph

09/18/2020, 8:29 PM
From some playing around in github actions, it’s pretty easy to sling artifacts around. I expect similar
1
a

alessandrogario

09/18/2020, 8:30 PM
(due to the extension sdk)
also publishes packages automatically when pushing a tag
s

seph

09/18/2020, 8:31 PM
I could easily imagine a the azure builds pushing artifacts to S3 for general consumption, and then a separate job pulling for signing/packaging official things. Likely leaner if it’s all together in one place. But I ran into test issues.
Dunno, maybe I should revisit the github actions stuff, and we can try to get things moved? Porting the azure pipeline was pretty easy. (y’all did so much work is was easy)
s

sundsta

09/18/2020, 8:33 PM
@seph Probably helps that GitHub Actions is a Azure Pipelines clone with small tweaks 🙂
s

seph

09/18/2020, 8:33 PM
Yes. It’s a fork 🙂
I think better in some ways, not in others.
s

sundsta

09/18/2020, 8:35 PM
It's missing a few things things... most important to me is the lack of the ability to pull in Actions from internal/private repos within the same GH org unless you do some gross work-around using an access token for a user/service account
s

seph

09/18/2020, 8:36 PM
The packaging has similar vibes, The old docker repo you can push with the implicit token, but the newer container one requires manual token creation.
I assume it’s all beta and getting better :)
s

sundsta

09/18/2020, 8:37 PM
Yeah, it's getting better all the time. They added org wide secrets in May which made my life so much easier