https://github.com/osquery/osquery/pull/5893 one more time haha!

https://github.com/osquery/osquery/pull/5434 should be good for another review — CI failure looks like a pipelines connection issue on macOS, unrelated to windows changes in the PR itself

this should be good to go : https://github.com/osquery/osquery/pull/5972

@theopolis 6011 is unrelated with the tests refactor, it's for the format script; the issue mentioned is the Python 2 -> Python 3 update which was not fully complete (at least for the scripts we use right now).

Also, can I get an accept on the PR?

ok what do you think? https://github.com/osquery/osquery/pull/6026 I have another few ports underway, but I think I'll open them as individual PRs

https://github.com/osquery/osquery/pull/6038 plz!

If I could get a review on https://github.com/osquery/osquery/pull/5981 I'd be grateful -- Teddy has already very kindly taken the time to go over it a couple times and I've addressed the comments (and gotten it back to passing tests)

https://github.com/osquery/osquery/pull/5434 could use a merge when appropriate — it’s been approved but i know there’s a release window going on right now, just want to make sure it hasn’t been forgotten 🙂

(and https://github.com/osquery/osquery/pull/5371, the huge NTFS PR, is ready for another round of 👀)

So, let’s look at the rpm_package_files table. This table returns a list of all files in an rpm, or, in all rpms. Let’s allow a reasonable implementation. clearly there’s an index on rpm. It would be folly to return all data for all queries and let sqlite filter. But, a row needs more than just the rpm name to be unique. After all, an rpm has multiple files in it/ This leads to thinking the uniqness of the row is the rpm+filename. Though the underlying implementation presumably only takes rpm name in as a constraint.

Yes. But the words above don’t call out that reality.

I feel like we’re thinking about this 90degrees apart. I think about the underlying constraint implementation as being the main goal. You’re talking about the primary key generation as being the goal.

So if we start with that, a question is what option to set on a column that is unused by the underlying implementation, but needed for the primary key

Intruding again: Ok so this is the part I personally still miss. Because for me it doesn't convey how many times your table code will be called depending on the combination of options you give. For instance I look at

required

and I see that the goal is to have that column always passed to the table, so I add it to my "path" column (supposing I have a table that operates on paths), and I expect that my table code is called anytime

path

changes. But is that true? So I might be remembering wrong but if I have a query that has

WHERE path IN ("1", "2", "3")

I will receive only one call and one of those values no?

@João Godinho The integration test is meant to have the table use its logic, beyond also testing the schema, so if you mean filling the table with dummy data, no. That been said, if there’s a way to generate that data through launching commands, that’s fine, I would just call them in the test. But I think there might be a second issue. I’m not sure what’s missing but the Linux distro we run on the CI is running inside Docker; I would’ve expected to at least see one login from the Azure user into the Docker container, but.. yeah

@theopolis I'll have a look! oss-fuzz uses clang/libc++?

hey @farfella do you mind rebasing https://github.com/osquery/osquery/pull/6190 and then I can merge 🙂

Could someone take one last review at: https://github.com/osquery/osquery/pull/5539 I believe all issues have been resolved Once its merged I can update https://github.com/osquery/osquery/pull/5831 In addition once its merged I can open another PR that adds support for appcomapt/shimcache for windows Thanks!

Plz https://github.com/osquery/osquery/pull/6334

https://github.com/osquery/osquery/pull/6361, the Buck removal PR, just need another quick review/approval 😉. I rebased it on latest master and just changed the display name of the jobs (LinuxBuild Release -> Linux Release) etc

whomever has a moment • https://github.com/osquery/osquery/pull/6458 • https://github.com/osquery/osquery/pull/6461

also @alessandrogario, some great work here, reviewed by thor with some follow up questions: https://github.com/osquery/osquery/pull/6280

last but not least for this weekend, https://github.com/osquery/osquery/pull/6436/files <-- will take some macos familiarity and if someone can pull and test that would be helpful but not required

@alessandrogario looks good to go, https://github.com/osquery/osquery/pull/6280 I wanted to give you a final chance to test before merging (this is why I did not merge it myself)

hey folks, can I have a quick review of https://github.com/osquery/osquery/pull/6531/files as I am working on some follow ups and blocked on having that merged

I need some help with my open PRs • https://github.com/osquery/osquery/pull/6541 • https://github.com/osquery/osquery/pull/6539 • https://github.com/osquery/osquery/pull/6530 The last one is blocking me from more detangling / refactoring.

Plz https://github.com/osquery/osquery/pull/6557

A much smaller manual set of changes in https://github.com/osquery/osquery/pull/6590/files

The major goal is to implement proper testing, but I am also adding some additional fields that I feel like are missing; one of them is the 'referenced' column that tells you whether the extension is actually referenced by the profile or not. Additionally, it can also access extensions that are living outside the Extensions folder in the user directory