There is a 5.9.0 beta. Builds up at https://github.com/osquery/osquery/releases/tag/5.9.0

There's a small bug in

homebrew_packages

in 5.9.0 where the version is reported as the name of the package instead of its actual version. I think it's because the path changed to no longer have a

/

at the end (around this code). cc @Marcos Oviedo I'm guessing that is from this PR? Otherwise things seem to be working well! Great to see crashes reported and info about RSRs on Ventura now

@seph whenever you get a chance, can you please accept the new and updated terms and agreement on our osquery apple developer account (I have access but only the account owner can accept the new terms), thanks!

There is a 5.9.1 build. This includes the homebrew fix. https://github.com/osquery/osquery/releases/tag/5.9.1

Have folks tested 5.9.1? I’ve had it running in Kolide’s beta fleet without problems. Anyone else? (@zwass @Marcos Oviedo?)

I have begun clicking buttons to promote 5.9.1 to stable

Hello, osquery agent security question here Is there a way how to make data from osquery extension is available only to one application that uses osquery agent / fleet and make sure that other applications that use osquery agent cannot use it?

I saw that Apple Silicon hosted runners for GitHub Actions is in a "public roadmap" moved to Q4 https://github.com/github/roadmap/issues/528

Website updated. Release notes updated.

hello guys, I want to know that Live query and Schedule query do they maintiain different queue and does LIVE query have more priority than SCHEDULE query ? and if yes then if any live query come does SCHEDULE query get preempted or it is like that SCHEDULE query will execute but for next query, osquery will Prioritize LIVE query over SCHEDULE query

Hi everyone, this is just an heads up. I believe

osquery::InternalRunnable

(as other places probably) is affected by clock adjustments (for sure on Windows, not sure on other platforms). Found this bug that basically say

std::this_thread::sleep_until

and

std::this_thread::sleep_for

implementation are based on a

system_clock

rather than a

steady_clock

. On top of it possibly other functions are affected such as:

std::condition_variable::wait_for
std::condition_variable::wait_until
std::condition_variable_any::wait_for
std::condition_variable_any::wait_until
std::future::wait_for
std::future::wait_until
std::recursive_timed_mutex::try_lock_for
std::recursive_timed_mutex::try_lock_until
std::shared_future::wait_for
std::shared_future::wait_until
std::shared_lock::try_lock_for
std::shared_lock::try_lock_until
std::shared_timed_mutex::try_lock_for
std::shared_timed_mutex::try_lock_until
std::shared_timed_mutex::try_lock_shared_for
std::shared_timed_mutex::try_lock_shared_until
std::timed_mutex::try_lock_for
std::timed_mutex::try_lock_until
std::unique_lock::try_lock_for
std::unique_lock::try_lock_until

shocked

Our builds are running out of disk on the AWS runners. https://github.com/osquery/osquery/actions/workflows/self_hosted_runners.yml @Stefano Bonicatti Did you fix this last time?

@seph There's a tag,

5.9.0.a

which is causing failures for the Windows builds on the latest commit (since the tag is there). Is that still necessary for tests or?

Hello, sorry for disturbing. I don't see a downloadable arm package for windows https://www.osquery.io/downloads/official/5.9.1 When will it be added, please?

Echoing it here: https://osquery.slack.com/archives/C08V7KTJB/p1696370043439059 And adding that we should maybe wait for https://github.com/osquery/osquery/pull/8052, but would really like if we could cut a pre-release this week, basically dropping the rest of the unfinished PRs (they all still need some work one way or another).

Micah and I have been working through a bug he found in

master

. https://github.com/osquery/osquery/pull/8037 introduced an issue. I was hoping we’d have a fix up today, but I think not. Worst case, I’ll back that PR out

@sephThe per row table call in a JOIN or the single constraint passed to the table per IN constraint, has always been the case since I remember. Although I know that we have functions to get multiple constraints per generate call, I never have seen them actually get more than 1.

I’m going to cut 5.10.0 as soon as CI on main is happy. (and I notice)

oops, I want to merge in

wifi_survey

as well. CI wait….

5.10.0 is cut. Waiting on CI there.

I can’t quite remember where I left the codesigning refactor. But I’ll try to drive signing with the new code. It’s at https://github.com/osquery/osquery-codesign/pull/43/files if people are up for looking

Hrm. Builds on main are failing. https://github.com/osquery/osquery/actions/runs/6437556025

5.10.1 exists, and there are packages at https://github.com/osquery/osquery/releases/tag/5.10.1 and the various test servers. It’s signed with the new workflow, I don’t think it’ll change anything, its the same code, just moved around

What’s left to get this marked as a final release?

It looks like the windows zip files didn’t get built. I’ll take a look

@seph for the JOIN, the sqlite logic to execute it is implemented as two nested for loops, and each table lands on the external or internal for loop based on the order in which the tables appear in the JOIN. The external table is already called only once, but then each row is used to call the internal table. I don't think this can be changed (for instance, having the external table collect all the constraint values, and then sending them all together).

Hey folks, @sharvil and I identified a potential issue with 5.10.1. The TL;DR is that when an osquery API manager triggers a config refresh, it can cause the file monitoring targets list to get kinda messed up and start monitoring all filepaths which causes a DB/logging blowup. What are the options for: 1. Waiting on the release until this is fixed or 2. Quickly pushing out a new release with a fix (but not waiting an entire release cycle to do so)?

hrm, something seems to be up with our

build_windows (Release, 64, windows-2019)

workflow

I’ve made a 5.10.2 to handle this ES FIM issue. There are binaries up at https://github.com/osquery/osquery/releases/tag/5.10.2

We can discuss whether to call 5.10.1 stable, or how to approach this in office hours, or here, I guess