Comment 24 for bug 1878234

My opinion on the issues raised by Fiencio and Peng Tao fits in one sentence: when you have a big hole in your ship, you first plug it, and only then discuss how to repair the rest of the ship.

This bug is extremely serious. It *presently* allows any remote user to reboot any host in a cluster, install malware, erase its filesystem, or worse.

So now is NOT the time to discuss the sex of angels, certainly not on a private bug. I will simply not engage in such discussion at the moment. We should do that after plugging the hole, and we should do that in public.

The question right now is whether my patch plugs the hole or not in systems that either install the default or existing configuration files. That's the only relevant question. If it does, then just get the thing in, warn existing users via a CVE, and get production systems patched in the wild as quickly as possible.

Then, AFTER THIS IS DONE, we can discuss later, on the mailing list, if we want to remove regexps, if there is any serious security risk for other options.

That being said, I will quickly address Peng Tao's and Fidencio's objections.

- Peng Tao: I disagree with your point 1. The reason I discovered the hole is precisely because I was about to construct a similar mechanism, only to be told it existed already. We can debate why this is necessary on the mailing list.

- Fidencio: We can also debate on regexp. It is a very secondary part of the patch, specifically the test in the "regexpContains" function. So easy to change later if there is a consensus. Right now, I'd argue that it absolutely does not matter, because the default is an empty list, so whether you use the default config or some existing config, you don't allow these annotations. Annotations being off by default, the hole is plugged unless a sysadmin ignores the warning and explicitly adds a somewhat hard to discover option. In short, I made the hosts safe by default, and right now, this is what matters.