Channels
android_tests
apple-silicon
arm-architecture
auditing-warroom
aws
carving
code-review
community-feeds
core
darkbytes
doorman
ebpf
eclecticiq-polylogyx-extension
extensions
file-carving
fim
fleet
fleet-dev
fleetosquery
foundation
fuzzing
general
golang
goquery
infrastructure
jobs
kolide
linen-dev
linux
macos
officehours
osctrl
plugins
process-auditing
querycon
queryhub
random
selfgroup
sql
tls
uptycs
vendor-feeds
website
windows
zeek
zentral
zercurity
Title
s
seph
08/25/2021, 12:58 AMI think there are two packaging things I’d like us to do before 5.0 goes stable. So, I’ve set a 5.0.1 milestone to hold those. This way we can cut a 5.0.0 release/tag for the beta. Note that I do not expect 5.0.0 to ever become stable, but instead to serve as a fresh iteration point. I know there are folks excited to test it
m
Mike Myers
08/25/2021, 5:11 PMLet's not add anything that delays 5.0. We can create a signed standalone
osquerydJust a reminder, we originally discussed 5.0 immediately following 4.9, but it has now been more than a full release cycle
◦ Plain macOS signed osqueryd binary: so we'll add a codesign step in the GitHub action
◦ We are fixing the default service paths on Linux and the documentation to reflect that
That's it and we can tag 5.0 right?
No new wishlist items added before this release, that's what I want us to commit to
s
seph
08/25/2021, 5:31 PMWe always intended to distribute a signed bare osqueryd. But we didn’t realize it wouldn’t work this way until we tried 🙂
I think:
1. we should cut a 5.0.0 today.
2. I don’t expect it to become stable
3. I think we should aim for a 5.0.1 or 5.0.2 as stable.
4. But I’m sure people want to start playing with 5.0.0
TBH I’m not sure I feel like there’s much wiggle room for me on any of those?
m
Mike Myers
08/25/2021, 5:37 PMI feel like we can do the two things today from your 5.0.1 milestone
then it just becomes 5.0 unless there's osmething wrong with it
s
seph
08/25/2021, 5:37 PMSure. But I’m kinda assuming we’ll find some bug. It’s a lot of churn.
Would you rather we cut a 5.0.0 now, and then itearated and planned on a 5.0.1, or for me to hold off and we can cut a 5,0.0?
(Note that Stefano disagrees with something in that milestone, and he may be right)
m
Mike Myers
08/25/2021, 5:38 PMI just talked to the guys and they really think the two tasks can be knocked out today
then a 5.0 tag would be good
s
seph
08/25/2021, 5:39 PMYes. I’d bet any of the cmake folk can handle the bare osquery one in a couple hours
But what would you prefer? Cut a 5.0.0 now, or hold till tomorrow?
I may not manage release notes today. But I think they can merge post
m
Mike Myers
08/25/2021, 5:40 PMBug discovering: that's entirely possible, my goal is just to keep the release from creeping any further. 5.0 checklist (notes) can be done after the tag, right?
Prefer to cut a 5.0 today but I was going to say later today, we have two PRs to merge that are in progress
s
seph
08/25/2021, 5:41 PMWe’ve done the changelog both before and after. Downside to after, is that it doesn’t show up in any built packages. Downside to before is that it’s more work 🙂
I’m going to be surprised if there are no bugs that merit another release in this line. So I see an early 5.0.0 as a way to get testing turned around faster. But I think you’re the person feeling the most urgency. so I can defer to you
m
Mike Myers
08/25/2021, 5:42 PMI can try to help with that then. It's a two step process, first you auto-gen from commit comments and then we clean up / add details right
s
seph
08/25/2021, 5:43 PMYes. And the tooling to auto gen is checked in and documented. Mostly, I’m trying to get another thing done for kolide this afternoon.
m
Mike Myers
08/25/2021, 5:46 PMWell we need at least the PR to unbreak service paths in Linux from Stefano, then we can tag 5.0 whereupon it'll have working pre-release packages for people to test. Changelog and the additional GH Action for signing the standalone osqueryd on macOS will go in before a 5.0.1 tag.
s
seph
08/25/2021, 5:47 PMAnother service path bug? I know I merged one PR for that.
I’m pretty happy to cut 5.0.0 whenever you feel like you want it. And I’m expecting we’ll need a 5.0.1
s
Stefano Bonicatti
08/25/2021, 5:47 PMhttps://github.com/osquery/osquery/issues/7277 it's this issue, the code part
m
Mike Myers
08/25/2021, 5:47 PMStefano said he had a documentation PR for the path changes
s
seph
08/25/2021, 5:48 PMdocs can land in 5.0.1
m
Mike Myers
08/25/2021, 5:48 PMok, then it sounds like we can tag 5.0 now? Stefano it's fixed in code, just not in documentation?
s
Stefano Bonicatti
08/25/2021, 5:48 PMwe haven't updated any paths in the code.. and so service files internally are referring to the wrong paths for osqueryd, plus a couple of other incorrect default paths. What we have fixed yesterday was where CMake was installing those service files.
m
Mike Myers
08/25/2021, 5:49 PMok — then holding off on 5.0 tag until later today
s
seph
08/25/2021, 5:49 PMSounds like we should wait
s
sharvil
08/25/2021, 5:49 PMI think Stefano means these files: https://github.com/osquery/osquery/blob/master/tools/deployment/linux_packaging/deb/osqueryd.service
s
seph
08/25/2021, 6:12 PMhttps://github.com/osquery/osquery/pull/7276 should sneak in before we go really stable too. (Another breaking change)
s
Stefano Bonicatti
08/25/2021, 6:17 PMThere will be other breaking changes soon after 5.0, because it's stuff we didn't manage to do now; I don't see it as a 5.0 blocker. If we can sneak it, fine, but I wouldn't stop for it.
s
seph
08/25/2021, 6:18 PMThere will be other breaking changes soon after 5.0, because it’s stuff we didn’t manage to do nowDo you have something in mind? We generally try really hard not to break things
s
Stefano Bonicatti
08/25/2021, 6:21 PMI'm really trying to make a difference between things that will break osquery and things that might/will break something for the customer using it.
I don't want to delay this release; spec changes or similar can be delayed, we already did that anyway.
So I wasn't meaning anything that would break osquery.
Ok let me rephrase; there are other things that we know we want to do that will maybe break stuff for the customer if merged (meaning the customer has to change something). I know we sort of called 5.0 as the breaking changes release but we didn't got all of them there; It's fine, we have inserted other breaking changes on other versions anyway. I don't want to stop a release for them.
s
seph
08/25/2021, 6:28 PMI think I’m mostly in alignment. That PR specifically, was originally just going to hide some columns. But if it squeeks in, we can drop the columns and option.
But I kinda don’t want to drop options randomly, we’d instead just noop them.
So I think it’s all about code cleanliness.
Anyhow…. Draft changelog. I didn’t wordsmith at all yet. https://github.com/osquery/osquery/pull/7284/files