You verify against the signature that's in the current version. Now this may mean that you need to do stepped upgrades to versions that are cross signed to get new certificates. That or you have at least one https update method that gets a signing cert for the application.
And how do you ensure the integrity of “the signature that's in the current version”? Because live patching the signature in a program to force verification of an invalid payload is exactly how many software/game cracks work.
I mean, if you can't verify the integrity of the application you're already running then it's already game over. You're talking about downloading another executable and running it to life patch which is the exact opposite of what I'd suggest.
The currently running (trusted) executable downloads and verifies the signature of the binary. Then after verification you execute it. If your trusted binary is validating invalid data then you've already messed up somewhere.
Re-read the thread, because you're misunderstanding the threat model here.
The starting point was: an attacker has control over the system so that “the end user could be MITM'd already with a root certificate maliciously installed on their device”.
In that case, there's nothing “trusted” on your machine anymore and all bets are off. Doing signature verification in app instead of relying on HTTPS is security theater[1].
[1] or it could be “defense in depth” but that's an argument I'd only accept from someone who really understands what they're talking about, and only in a context where everything else being being done properly. Most of the time “defense in depth” is just an argument for the security theater.
