Comment 27 for bug 1878234

> We're discussing the solution

Well, part of my concern is that I feel we are not discussing the solution I proposed as much as spending a lot of time imagining alternatives. That's what I referred to as bike shedding.

Should we spend time on

a) fact: does the patch prevents remote execution by default?

or

b) opinion: can we trust sysadmins with regexps?

c) opinion: should we allow annotations?

I say please focus on (a) for now. Discussions (b) and (c) are important, but they could happen in public once (a) is done and some patch is widely available. I don't mind at all if we patch over my patch to do all kinds of other things. It's just not urgent.

> Also, it's a Saturday night. You raised your question one day ago.

I assume you are talking about the CVE question? I remember asking it on Tuesday, which is how I learned about the process to follow. I asked again one day ago, because I want to be super-extra-duper sure that I'm not the one supposed to write the KCSA described in https://github.com/kata-containers/community/blob/master/VMT/VMT.md. According to the doc, the VMT is supposed to do it, and I'm not a VMT member. But maybe everybody assumes that since I reported it, I'm the one who would at least draft the KCSA?

Anyway, Kata is about "security". I'm not saying it, the project is claiming that. Top title on the web page: "the security of VMs". So you'd expect that a security hole that opens a root-access backdoor for remote execution would be a kind of "red alert, all hands on deck" situation where "Saturday" would not count as a valid counter argument ;-)

The project's credibility on the security front depends on how it reacts to such problems.

Anyway, it's Sunday for me now ;-)