seph

> Purpose of this PR is to remove Linux's `disk_encryption` reliance on `block_devices`. We want a list of all block devices by name and a way to access their parent...

@Smjert I think you said you could review this PR this week?

> Do we think there are any table implementations that rely on this behavior? Any thoughts on a strategy to determine that? Feels unlikely. When I've brought this up previously,...

We talked about this briefly at Office Hours today. @Smjert suggest that incorrect loops should be relatively to audit for -- we can examine tables that have `getAll`. But I'm...

@Smjert You looked involved with https://github.com/osquery/osquery/issues/8254 any concerns?

I have not yet dug into this, but I've started hearing that there may be a 5.10.2 regression as compared to 5.9.1. And I see we upgraded in https://github.com/osquery/osquery/pull/8142 (so...

My understanding from slack is that this is pretty messy. - `libmagic` changes the db format occasionally - OSes ship `libmagic` and an associated database - If we were dynamically...

This one looks like we're just casting to a uint32. https://github.com/osquery/osquery/blob/8d9059f9140f114841669788348f298ba1a64203/osquery/filesystem/linux/mounts.cpp#L86 Not sure why, it looks like the underlying `statfs` is probably 64bit. Should be pretty easy to update all...

> If we cast to uint64 we will have to check the actual value before setting the row data, correct? As SQLite will not correctly handle anything greater than int64....

> Yes, I agree that `--extensions_require` doesn't seem useful for table extensions. I wouldn't want to specify it every time for every extension. If the tables are used for decorators,...