If any osquery TSC member can approve these external contributor PRs, I have recently reviewed and tested: • https://github.com/osquery/osquery/pull/7156 • https://github.com/osquery/osquery/pull/7391 • https://github.com/osquery/osquery/pull/7407

👀

Y’all have a bunch of approved PRs hanging out. I think you could sweep through and merge them. I probably will eventually

My PR to bring back

kernel_panics

is not that big, but generating kernel panic logs is annoying so I've attached sample files so the reviewer can test or just check how they look. https://github.com/osquery/osquery/pull/7585

This PR is ready to be reviewed, thank you on advance https://github.com/osquery/osquery/pull/7598

Well, I thought I would try fix the issue that I posted about in #general:

tested on an apple silicon mac and an intel mac. it works.

Hi @seph! I've pushed the suggested changes to #7675.

I've got a small issue that I'd like to put a PR up for... I've got a fix working locally but would like to chat in here first to see if I'm on the right track (also hi, I'm new to osquery and not a cpp programmer, so be aware 🙂 ). The issue: file carve table gets broken when running in debug because a type assertion fails in the json tree construction A solution: change the loading code in carves.cpp to switch on type

diff --git a/osquery/tables/forensic/carves.cpp b/osquery/tables/forensic/carves.cpp
index 1fcdb25af..80929ad13 100644
--- a/osquery/tables/forensic/carves.cpp
+++ b/osquery/tables/forensic/carves.cpp
@@ -53,8 +53,10 @@ void enumerateCarves(QueryData& results, const std::string& new_guid) {
       r["time"] = INTEGER(tree.doc()["time"].GetUint64());
     }

-    if (tree.doc().HasMember("size")) {
+    if (tree.doc().HasMember("size") && tree.doc()["size"].IsInt()) {
       r["size"] = INTEGER(tree.doc()["size"].GetInt());
+    } else if (tree.doc().HasMember("size") && tree.doc()["size"].IsString()) {
+      r["size"] = INTEGER(tree.doc()["size"].GetString());
     }

     stringToRow("sha256", r, tree);

From reading more of the codebase and the database code it seems like there's some friction where the update functions only take strings and then it seems its up to casts elsewhere in the codebase to turn them into the right types

Hi @Andre Pinter I think opening an issue for this is a good idea. It's great that you've already got a possible fix. If you open a PR, point it to the issue, it should be reviewed after you click to agree to the contributor license agreement (CLA)

In cases where a greater amount of code is being considered, it's always a good plan to get explicit agreement on the issue and the approach before starting. Just so that you don't implement a big chunk of work that cannot be accepted for design or practical reasons

Hi folks! This is ready for review (CI now passes, was failing due to flaky tests): https://github.com/osquery/osquery/pull/7712

Would anyone be able to review this PR https://github.com/osquery/osquery/pull/7714

Does anyone know enough to review that PR? https://github.com/osquery/osquery/pull/7714 If the answer is no, we will have to self-approve it

I've ported forward some code for containerd events. Most of the original code is from @Stefano Bonicatti but I can fix any issues: https://github.com/osquery/osquery/pull/7751

Hi folks! The following two PRs are ready for re-review: 1. #7655: Fixes the current odd behavior + adds missing documentation for "discovery" queries in distributed queries. It also fixes the following two issues: #5260 and #7793. 2. #7712: This is for future-proof support of osquery downgrades. So that osquery doesn't break whenever a new version adds a column family to RocksDB and users need to downgrade osquery.

Hi osquery reviewers! I opened a new blueprint for making schedule epoch and counter behavior more consistent, to support periodic snapshots and stream alerting from the same differential rule: https://github.com/osquery/osquery/issues/7799 It has a couple PRs and draft commits for proposed implementation - curious what people think when you have time 🙂

Hello there, can anyone give a quick review to https://github.com/osquery/osquery/pull/7813, this issue is blocking/keeps failing our CI

There are a few lingering PRs from Fleet team members that could use some attention:

https://github.com/osquery/osquery/pull/7655 - @seph Do Lucas's answers work for you?

https://github.com/osquery/osquery/pull/7751 - @Stefano Bonicatti do you think you could take a look at this one?

https://github.com/osquery/osquery/pull/7712 - @Stefano Bonicatti do you think you could take a look at this as well? It's adapted from your idea.

https://github.com/osquery/osquery/pull/7821 - @thor this one is actually pretty new, but could you please lend a hand with your Windows expertise?

I have a new PR to add stats to distributed queries: https://github.com/osquery/osquery/pull/7870

This looks like a good candidate for 5.8.0: https://github.com/osquery/osquery/pull/7916. I could review it but I'm not very familiar with the relevant systems.

I think https://github.com/osquery/osquery/pull/7821#discussion_r1095282267 is ready to merge now, though I can't approve or merge it because of how I opened the PR (though didn't write any of the code)

Hi folks! I've tested this change and it works #7944. And the changes are simple enough and make sense.

Hi everyone, I have a draft PR up for a

windows_search

table that lets users query windows using CCommand via osquery. This is my first attempt at contributing to osquery and my first real foray into C++. Would love some preliminary feedback, just to validate my approach and ensure my code is in the ball park in terms of quality.

@Marcos Oviedo https://github.com/osquery/osquery/pull/7999