https was a practical issue at one time but it isn't anymore. This RCE would be far less severe if all communication was over TLS as the attacker couldn't just sit on the wire between the client and the server. It would still exist with TLS of course, but you can't say that TLS "can [only] provide privacy". The correct solution would be to do both TLS and GPG signatures.

You cannot MITM a .rpm downloaded with yum/dnf or a .deb downloaded with apt because they verify the signature of the package as a whole before they even begin unpacking it, the entire reason a RCE exists here at all is because of an entirely broken signature verification mechanism. There is no need to protect against a MITM attack if you are verifying signatures correctly, because a modified package will be detected prior to installation.

Of course you can mitm it. You can supply old manifests and packages. You can send specially crafted rpms/debs that trigger bugs. Resource exhaustion via enormous packages is an option for embedded systems.

"the only reason this RCE exists is because of a vulnerability in apk"

The problem with this thinking is that it's always true, yet vulnerabilities keep on being discovered.

Https does nothing to protect you from a compromised or evil mirror. You cannot trust https at all in this context, you need to rely on signatures.

You have ignored what I wrote

It's astounding how many people in this thread seem to think that a compromised mirror or compromised certificate authority is somehow a comparable risk to plain old MITM.

It baffles me as well. A lot of comments either seem to imply that TLS and PGP cannot coexist in a package manager or that because HTTPS doesn't protect you from Mussad replacing your phone with a brick of Uranium so you die of Cancer, the security advantage does not exist...

Somehow the term "defense in depth" (aka "layers of security") has lost it's meaning.