What is the use-case here? Why not just rely on os_version table?

I want to know what osquery itself thought the platform was, and by extension, which table schemas would be present.

os_version.platform and os_version.platform_like are very different. Those derive from OS presented information, are somewhat incorrect, and can only be manually correlated. with the osquery platforms. Some examples:

• mac laptop: darwin,darwin -- No indication posix or bsd
• ubuntu server: Ubuntu,debian -- No indication of posix linux
• centos host: rhel,rhel -- No indication of centos, let alone posix or linux

@fmanco this information is critical to know when enrolling a device in TLS (in fact it is sent during the enrollment request for the remote TLS API).

Unfortunately there is no way to dynamically query this information later after the enrollment phase. It just seems strange that something so important to how Osquery identifies systems internally is actually not accessible through a virtual table.

+1
It would be useful.

But having a table all by itself for this also feels awkward. system_info, osquery_info ?

@fossam Mostly the columns felt better named in a dedicate table, than adding it elsewhere. Especially if the list of IsPlatform things grows. But, I'm happy to move it. Mostly I wanted the functionality, I'm less picky about where

This info in a dedicated table seems like overkill. Can you make this work with just the bitmask in osquery_info?

I could, yes. My thinking here was that it was easier to work with, and it becames self contained. I'm not sure the bitmask will be stable across versions.

Is this still info we want?

I would find this content useful, yes. It also feels like something we should expose.

I am agnostic whether to add this to a new table, or expand one of the existing ones.

Code should be mergeable.

Let's abandon this and go for a platform_mask column in osquery_info.