# osquery office hours 2023-05-09
YouTube Link: https://www.youtube.com/watch?v=DOEFHJ0ZVxU
## Announcements and Highlights since the last meeting
* Marcos is a committer now
* Probably about time to cut a new release
## 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?
## Agenda down here
## Issue with the arm64 build
We should fork this. We need to update some parts.
https://github.com/osquery/ec2-github-runner now exists
## Handling Apple RSR versions
* We have two PR submissions for this. One uses the framework, the other parses the plists. What approach do we want?
- Sharvil thinks reading the cryptx plist is reasonable
- Stefano doesn't like a table that calls `select`, so if we use plist, we should use the plist helpers
- Mike points out the we often have endless issues with plists changing
- Jeremy says there are 2 APIs, and the legacy one has been stable ~forever, and there's a new one to add additional info
* Two approaches on table data too -- `extra` column name or squish together with the `version` column
- Sharvil points out that people parse `version`
- seph points out that `version` is documented as the display version, and we should match Apple.
- seph also thinks an `extra` column makes sense
* lets use the API
* we'll add an `extra` column
* `version` should match Apple (and gains `(a)`)
# Add the `cpu_usage` and `cpu_peak_usage` columns to the processes table
Stefano has been thinking about this, and there's a bunch of nuance and complexity.
The data there, doesn't match the watchdog. Which is confusing. So there's desire to create a single internal internal source of truth.
Discussion about how to create a timeline. How do we see a timeline of query execution vs cpu utilization.
Dovetails a little with questions about exporting things to prometheus. seph points out this raises the perpetual question about what is osquery. We're not going to really compete with full telemetry -- it's a different market. But we could reasonable expose what we have.
What if this data was in a table? It might be noisy, and a lot of events churn. What if it was a logger stream?
## Look At Open CVEs / Security Tickets
[List of Issues tagged with Security](https://github.com/osquery/osquery/issues?q=is%3Aopen+is%3Aissue+label%3Asecurity)
OpenSSL is floating in a backlog
libxml2, we might be effected. Maybe augeas, we should update it.
## 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)
* Windows ARM port: merged!
* Windows Search Table: EAV style, or not
* `dreamer-dead` has been submitting a bunch of small PRs. Marcos has been reviewing them