10/20/2021, 11:55 PM
could someone review/provide feedback for 1 or more of the PRs i opened at:https://github.com/osquery/osquery/pulls/puffyCid https://github.com/osquery/osquery/pull/7261 - amcache/registry parser https://github.com/osquery/osquery/pull/7260 - jumplist parser https://github.com/osquery/osquery/pull/7259 - UAL support for macos https://github.com/osquery/osquery/pull/7258 - FSEvents parser https://github.com/osquery/osquery/pull/7160 - PE, MACHO, ELF parser support thanks!
4:48 PM
Just wanted to bring this up again Any feedback would be appreciated Thanks
11:09 PM
Would it be possible to merge 1-2 (or All šŸ˜‰ ) Of the PRs mentioned above before the next release or two? Or if anyone has feedback that would be great I think these features r pretty cool and I think others would like some of them as wellšŸ™ƒ
3:03 AM
Just bumping this up again Just wondering if anyone has any feedback or comments for any of the 6 PRs opened above


12/01/2021, 8:49 AM
I would be inclined to not accept the following PRs, but I am waiting for at least @zwass and @seph ā€¢ https://github.com/osquery/osquery/pull/7261 - amcache/registry parser ā€¢ https://github.com/osquery/osquery/pull/7260 - jumplist parser The following PR needs some additional work on constraints, to prevent the table from returning too much data and cause the worker to get killed. @zwass && @Stefano Bonicatti talked about this during the last office hour. It seems appropriate to implement a mandatory WHERE clause to filter by time https://github.com/osquery/osquery/pull/7259 - UAL support for macos After M1 is merged, I'll do a second code review and update/regenerate LIEF (https://github.com/osquery/osquery/pull/7160) FSEvents: Similar to the UAL PR, it must implement a WHERE clause to make sure it does not return too much data
8:55 AM
I also think that code should generally be split in two parts, one doing the parsing into a structure and then the second part generating the rows based on pre-parsed data


12/01/2021, 2:09 PM
That's disappointing to hear šŸ˜¢ The raw registry table is probably the most important of the PRs I've opened Mainly from an investigation perspective, its one of the 3 artifacts that r pretty much required in order to do a comprehensive investigation Ual adding a WHERE clause makes sense it does return alot (maybe a WHERE clause for log level and/or timestamp?) I'm not sure if fsevents should require a WHERE clause? If using osquery for investigations it needs to be able to pull back large amounts of data (full file listing, all event logs/UAL, all registry keys for all users So from an investigation perspective u would want to pull back everything It would be great if all of the PRs could get merged Especially raw registry parsing There r many EDR tools available that can already parse jumplist/raw registry so it would be great if osquery can also do it to