I’ll write up a CHANGELOG later

It's the "security you need now" release, and we're setting 5.3 to follow it quickly with the planned increment of feature work and bug fixes

i see, thanks!

https://github.com/osquery/osquery/milestone/62 I've recreated the milestone

Preview of the 5.3 changelog • Everything from 5.2.3 • Documentation: Update the TSC members • Documentation: Remove mentions of FreeBSD platform support • Documentation: Pin Jinja2 ReadTheDocs dependency to 3.0.3 • Add windows/macOS support to npm_packages • Bug fix: move apt_sources and yum_sources tables to Linux platform only • Test tooling: Update profile.py for python3 • Flaky test fix: attempt to fix mdfind.test_sanity • Add homebrew paths to the python_packages table • Fix for gathering python packages from any user's Python installations • Mark wall_time column in osquery_schedule as hidden • Implement output_size for osquery_schedule table • Add new metrics and improve descriptions of existing ones in osquery_schedule table • Improved responsiveness behavior in osquery when connecting to broken osquery servers • Testing: Enable fuzzing and Asan on Windows, enable Asan builds on macOS • Testing: Fix the test_http_server.py --persist option • Fix watchdog not killing unhealthy worker/extension fast enough • Build: Update cppcheck to version 2.6.3 and skip analysis for third party dependencies • Fix osquery TLS connections to AWS kinesis when tls_server_certs is set • Set string size limit on thrift protocol factory • Testing: fix cpu_info test to ensure at least 1 socket, but not assume only 1 • Fix some warnings about unrecognized special characters • Fix third-party libraries flags leaking to osquery targets • yum_sources: Include the mirrorlist URL in the table output • Add third party libraries target • Fix parsing issue when a backslash is the last character on sudoers file line • Change the JSON of the results from an event scheduled query to an array • Build: do not run clang-tidy on third party libraries • Fix globToRegex truncating UTF16 characters

https://github.com/osquery/osquery/pull/7550 seems fine to me. Anyone have an opinion?

Thumbs for https://github.com/osquery/osquery/pull/7427 (It’s a tiny one, was approved, but typo changes invalidated the approval)

Website PR https://github.com/osquery/osquery-site/pull/246

Anyhow for ^^^?

Does anyone have a sense of where most of the resource utilization in osquery comes from when using event-based tables with a high volume of events? Is it in the RocksDB read/write?

Baring objections, I’m going to cut 5.3.0 very soon. I merged Stefano’s things. I see a couple of other low hanging PRs (#7593 and #7604) but it’s not clear to me we should hold much longer

It'd be nice just to get 5.3 out and start merging a bunch of 5.4 stuff

It’s been an hour. Good enough. https://github.com/osquery/osquery/releases/tag/5.3.0

Build exist at ^^^

@seph the 5.3.0 changelog is ready if you wouldn't mind approving/merging https://github.com/osquery/osquery/pull/7575

@zwass perhaps you can approve the 5.3.0 changelog https://github.com/osquery/osquery/pull/7575

Has the possibility of adding a disk usage channel to the watchdog been discussed? Because it surely affects the performance, and it feels like it's something Osquery must keep under control. I.e. https://osquery.slack.com/archives/C08VA3XQU/p1652310551730349

Can you say more about how you imagine it would work? If rocksdb starts using too much space, try to denylist the query? Restarting osquery wouldn’t free the space

I'm not thinking about space, which I don't consider impacts the machine's performance given the size of what Osquery saves. I'm thinking about IOPS and throughput because I think those can interfere with users or carry costs on production servers. I think it shall work as the CPU limit, but I don't have strong feelings about it. Probably it would be beneficial to shine a light on it.

ah iops makes more sense!

Nobody has reported a bug and osquery 5.3 has been in prerelease 15 days, does anyone have time to help make the rest of the 5.3 checklist tomorrow?

I pushed it to the Kolide beta fleet earlier today

Fleet's automated tests are working with 5.3.0.

I haven’t seen any 5.3.0 issues, And I assume by @zwass earlier message, Fleet hasn’t either. So I think that means we should push 5.3.0 to stable

I’ve kicked on a new release build, which should get pushed out to the S3 bucket.

Hosted repo updated. Github updated. I’ll see about getting a website PR up

Website deployed. There’s always a caching delay.

I believe this completes the non-PR aspects of the 5.3.0 release

Hrm. As I tinkering around m1 things, I think we made it hard. We have pretty comprehensive support for platforms. They’re in the schema, we expose a bitfield of them. Etc. But we don’t expose any kind of architecture info. It’s not in

osquery_info

. It’s not in the table schema. Etc.