Hello all! I want to consult regarding this issue: https://github.com/osquery/osquery/issues/7298 This is an issue that depends on the environment (whether or not SELinux or other security products are present and blocking) I was thinking of resolving it without changing compatibility by applying a patch in librpm to dynamically check for getauxval in case we compile without that option (which we do for compatibility) Is that an acceptable solution to keep the product working without the need to apply special exceptions for it? Added code will look roughly like this: rpmrc.c964 #ifdef HAVE_GETAUXVAL rpmat.platform = (char *) getauxval(AT_PLATFORM); if (!rpmat.platform) rpmat.platform = ""; rpmat.hwcap = getauxval(AT_HWCAP); #else // Try dynamically if (!g_getauxval_initialized) { g_getauxval_func = (getauxval_t)dlsym(NULL, "getauxval"); } if (g_getauxval_func) { rpmat.platform = (char *) getauxval_func(AT_PLATFORM); if (!rpmat.platform) rpmat.platform = ""; rpmat.hwcap = getauxval_func(AT_HWCAP); } else { // Continue original rpmlib code }

If I understand right, this is a build time option? So it would require a custom build?

Yeah on one hand this is a build time option and we do not specify it because we want to support CentOS 6. On the other hand there are advanced system that conflict with that option.

Good to know you have cento6 machines. If you can say more, https://github.com/osquery/osquery/issues/7445 is somewhere to comment (I just made that to discuss desupporting centos 6)

Yeah, I understand. Does the CI test on CentOS 6?

I'd have to check, but I think everything runs on

ubuntu-18.04

(should be able to poke around the github workflows)

I think that long-term, we would like to introduce that support to librpm. Because what we're saying essentially is we want the support a portable instance of the librpm library, without needing to rebuild for each scenario. WDYT?

Is there a way to do that at runtime, not compile time? Generally though, I'd defer this to Stefano or Alessandro and see what they think. I'm sure they'll chime in eventually,

Yeah, the runtime way is the code snippet I provided. We just check for the symbol in runtime and use it if it exists

The one that feels like a bigger issue, is the

iptables

one. As I understand it, centos6 is keeping us from supporting the newer nftables

Let me try to dig into that, I have some experience with iptables

The issue is linked. 🙂

What seph is said is correct in terms of why dropping CentOS 6, but I would also add that it’s definitely a big maintenance burden, on the third party library side, when we have to generate their configuration, and on the toolchain side which has to support back to that version, which currently does but it’s a bit dodgy and incorrect, since we are using the wrong kernel headers versions. Fixing those, it then causes issue where we can’t easily use newer distributions and features. I think last time we sort of agreed that we wanted to have 1 year of intentional support after a distribution has gone fully EOL. CentOS 6 is really old.