# osquery office hours 2022-06-21

YouTube Link: https://youtu.be/Z4eUU8yhRNg

## Announcements and Highlights since the last meeting
* 5.3.0 is stable. We should tweet about it
* Sharvil presented at Mac Dev Ops. Video coming soon

## Any Questions / Issues / PRs people want to discuss?

The intent of this section is to provide a clear time for community members to bring up _anything_.

Broad questions? Bugs? Deployment questions? Blocked PRs?

## `scheduler` -- option to make it work on wall clock

### Background

For scheduled queries, the interval time is, seconds since the osqueryd has been running before the scheduled query will be executed. This means that scheduled queries run every N of osquery uptime (+/- some drift), and there is no precalculated time when a query runs.

The current implementation of this at a high level is that on startup, we grab the unix epoch and store it in memory. We advace the tics and `if (current_time % interval == 0)` then we execute the scheduled query.

There are some drawbacks to this: if osquery restarts, the interval resets. This can lead longer than expected intervals or even queries that *never execute* at all, because osquery restarts before the interval. For workstations that are sleeping this can make it unpredictable how often the queries actually run.

### Proposal

Wanted to get everyone's thoughts on this and having an option to make scheduled queries run on more of a wall clock approach instead of ticks (osquery uptime)

One option is to store the `last_executed_time` (`osquery_schedule` table already saves this), and use that to schedule the next query execution at `(last_executed_time + interval)` Question -- does success of unsuccessful change this?

The other approach could be: store the osquery startup unix epoch in RocksDB, use that to calculate intervals and drift.

### Discussion

Anyone know why we do it this way. Should we just change the scheduler behavior? There's hesitency to change it without notice. So maybe a option, and then we can change the default in the future?

seph thinks this is interesting, and good, as it will aligning with user expectations. To that end, something off `last_executed_time` feels straight forward.

Some oddness around how splay and temporality works
* The simple case will cause clumping around machine wake
* This may be a bit weird for short interval queries, consider splaying on percentage?
* Unclear how this effects evented stuff
* We want to avoid multiple queries clumping

## `osquery.io` schema documentaion issues

Misdocumented tables:

* `secureboot` table is implemented in Linux and Windows and the table spec is marked `linwin`, but the website shows it's available for all platforms

* Bunch of other tables (`lxd...`) are marked as `posix`, but only implemented on Linux -- okay to move the spec/implementation from `posix` to Linux only?

* `example` table is included in the osquery.io schema docs, perhaps we should exclude this from the docs

Documenting `constraint` and `user_context`:

A lot of tables have costraints on columns, this is not exposed easily in the documentation. What would be the best way to do this? Have an `attribute` in the table spec file?

Similar to above for user context. It would be nice to have this documented

Deprecating tables that are not used or not testable as working

* `carbon_black`
* `atom_packages`

There's broad agreement in improving the table schema. And updating the website javascript as we can.

## deb_packages regression on the 'name' column

The recent refactor happened on the internal dpkg helper functions has introduced a regression, breaking the contents of the `name` column by appending the package architecture at the end. The following PR fixes the bug: [#7638 - deb_packages: Do not display arch info in the package name](https://github.com/osquery/osquery/pull/7638)

## A new osquery release

Two of our libraries have security vulnerabilties. These don't impact us directly, but some users cannot deploy osquery without a green dashboard. There's some tension here between helping people get osquery deployed, and not feeling like osquery releases are being driven by some meaningless checkbox.

This specific need is driven by some merged PRs (https://github.com/osquery/osquery/pull/7629 and https://github.com/osquery/osquery/pull/7628) that update dependencies, and silence dependency audit tools' alerts.

This dovetails with a desire to have more releases.
* What if they were monthly?
* What if they were automated?
* Counter point -- having codesigning manual is a nice catch in case we merged something sketchy. How do we cover this?

General consensus is that we should cut a 5.4 on July 1, and try to be more frequent.

## Releasing the osquery security audit by Trail of Bits

Trail of Bits completed a security audit of osquery core, and the sponsor would like to publish the report. We want to circulate the report amongst the maintainers first and get a private channel on osquery Slack about the disclosure.

General consensus for:
* Private slack channel
* Trusting ToB on what needs to be fixed before release vs after
* Having this report land in the osquery docs after ToB releases it. (If they can)
* GitHub advistories as needed

## Look at old PRs

_(If there's time, we've been trying to re-visit old PRs)_

[Reverse Sorted List of PRs](https://github.com/osquery/osquery/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc)