Oh, sure, yes, absolutely, software updates is one of the cases where you probably just want an (asymmetric) signature. (And probably TUF.)
But my alternative suggestion also addresses that: in a model where you don't trust the host with the key but you do need to help it make a determination if a particular thing is valid or not, you could just go ask the server you got it from instead. Basically: the key doesn't have to live on the machine doing the validation.
I thought the point of doing validation locally with the key was mainly performance? You do this mostly to AVOID the round trip of having the 3rd party do the validation (sub-ms to do validation with a shared secret or rsa key; vs multi-ms and complexity for an HTTPS API call).
If you get a malicious update from a compromised update server and then ask said server if the hash you got is correct, you might as well just roll a dice. You'd need a pinned certificate (e.g. for HTTPS) to prevent MITM and thus asymmetric crypto anyway.
Partially yes. You don't need a pinned certificate, just working certificate validation. I am not suggesting you should never use asymmetric crypto: you should definitely use HTTPS. The question wasn't "is asymmetric crypto morally good or bad", it's "should I use asymmetric crypto in my code to do bespoke signing things". The asymmetric crypto in TLS is fine because you're not doing bespoke signing things: you're doing the most well-understood handshake + protocol on the planet.
Pinned or validated, you need to know that you can trust the server locally. I was just addressing the "ask the server you got it from instead. Basically: the key doesn't have to live on the machine doing the validation." part in your alternative, signatures seem kind of moot if you cannot verify the server is who it is supposed to be from the client's point of view. There's no benefit of signatures over any regular hash here, right?
Right. As I mentioned, you're just moving the signature from the blob itself to HTTPS, and if all you care about is validating a file you'd just make that a hash. Analogously to a SHASUM file, but the authentication coming from HTTPS/WebPKI instead of something ending in .asc.
One critical point is that the two servers do not have to be the same. You might distribute your files via a CDN like CloudFront (or if you're in the 90s and a Linux distribution, a ragtag team of servers that don't generally implement https). The server responsible for delivery can lie all it wants; the server responding if something is valid is what actually matters.
But my alternative suggestion also addresses that: in a model where you don't trust the host with the key but you do need to help it make a determination if a particular thing is valid or not, you could just go ask the server you got it from instead. Basically: the key doesn't have to live on the machine doing the validation.