08/05/2021, 1:16 AM
This seems like a bug?
osquery> select version, build_platform from osquery_info;
       version = 4.9.0
build_platform = 1
or similar on Linux?
1:23 AM
on mac:
osqueryi --line 'select version, build_platform, build_distro from osquery_info;'
       version = 4.9.0
build_platform = darwin
  build_distro = 10.12
1:24 AM
I had to go back to 3.3.2 for a sane looking result on linux, but it's still not what I'd expect:
docker run --rm -it dactiv/osquery:3.3.2-ubuntu20.04 osqueryi --line 'select version, build_platform, build_distro from osquery_info;'
       version = 3.3.2
build_platform = ubuntu
  build_distro = xenial
Stefano Bonicatti

Stefano Bonicatti

08/05/2021, 10:31 AM
It seems a stringification issue which only appears on Linux clang for some reason..
10:32 AM
I see that too now. OSQUERY_BUILD_PLATFORM is a define preprocessor used to set that value and is passed to the compiler as
, then it’s used in code as
r["build_platform"] = STR(OSQUERY_BUILD_PLATFORM)
10:32 AM
STR should stringify it
10:45 AM
oh I see now..
is a macro too, so instead of expanding to the string linux, it also expands that macro and the result is 1
11:19 AM
So yeah, this is fixable by having CMake generate a file which contains C++ code with the correct strings in it and without using macros, since it gives this issue. Something like:
const std::string kOsqueryBuildPlatform = @OSQUERY_BUILD_PLATFORM@
and then that OSQUERY_BUILD_PLATFORM it’s actually a CMake variable that is substituted using
11:21 AM
CMake could also try to detect the platform specifics, since right now we hardcode values instead
11:40 AM
actually nvm, even simpler fix for now is to use
and then remove the stringification, since it’s already a string (otherwise it would print
12:32 PM
I've also opened an issue here: https://github.com/osquery/osquery/issues/7253. I think that with the 2 build systems conversions there has been a confusion on what build_platform and build_distribution should represent too.