Proof was in description. Maintainers claimed that problem wasn't related to image but rather to infrastructure, so we changed the base image to prove that infrastructure was totally fine. Also i personally don't actually care that much if issue with this particular image is resolved, we switched to bitnami one for the time being (and will build our own one from sources when we have time to do so). It's more of a warning for other companies/people to check for the same problem.
The claim, not proof, was in the description. The maintainer is responsive and asks for details to reproduce. You keep ignoring the questions. "We sandboxed the entire VM using VM-level settings." Great, tell the maintainer what kind of VM you used and how it was configured. Without the maintainer will give up, close the issue as not reproducible and move on.
The maintainer is just closing this issue and all related with his own network-"hacking" theory without proving it by himself and having 0 arguments supporting it in the first place.
I started this discussion with arguments in favor of postgres BINARY being compromised. No mentions of network were at the start of dicussion except for the botnet control server which obviously isn't the cause because the connection wasn't incoming but outgoing.
You haven't provided proof either, haven't answered followup questions about the setup and aren't willing to work with the maintainer. The issue will surely be closed.
I provided all the data he needs to prove my theory (in previous linked issue) and his theory (in this issue). And now i'm the bad guy. Really?
BTW, specific VM settings doesn't matter for the purpose of issue replication, the problem is guest-OS isolated, but maintainer just denies it.
I know that using public docker images is a problem by itself, but this one is "official" in Docker Hub ...