Transferring signed packages over TLS only prevents the attacker from observing which particular packages are being updated, and that’s assuming the padding alone is sufficient to obscure identification by size.
Otherwise signing packages is actually preferred, because you can do it offline, so that hacking the server is not enough to push malicious code.
Not exactly true. If you as a malicious third person can MITM the http connection for updates, you can push an older signed package with known vulnerabilities.
Is it really that hard? Assuming you generate a public/private key, there's openssl RSA_sign and RSA_verify whose interfaces are pretty simple, clear and well documented. There's a difference between "I'm going to write a new way to do asymmetric encryption" which is really hard, and "I'm going to use RSA to verify/sign a binary" which is really easy. I'm seeing a tendency to say that crypto is hard for anything that has to do with crypto which is not the case. While erring on the side of caution is commendable, let's not push vigilance to the point where taking the hash of a file is considered hard crypto to get right.
You sign at the source with a private key, and you verify on the target with the public key. The trick is only someone with the private key can create a signature that the public key can verify.
The other problem is many people wont have pre-existing copies of the required private key available. If your attacker is in a position to MitM your download of a signed binary, they're probably also in a position to MitM your retrieval of the public key. SSL/TLS certainly helps there (at least the attacker then also needs to be capable of acquiring root CA signed TLS certs for the download site and any readily available PGP key sites. It wont slow the NSA down much - but it will help against the guy with the WiFi Pineapple in your local Starbucks…)
(Though with my overly-cynical hat on, I now just suspect you've only moved the problem to the previous update's authentication - and recursively back to the initial download. How do you protect against the initial download being MitMed and having an attacker's public key inserted - this is functionally the same as HSTS - if you can MitM the first visit you win...)
You need to trust something at some point, be it TLS session and the server you’re talking with, or an SHA csum you verify with a friend (or using PGP’s WoT), and even further the process(es) and person(s) responsible for actually signing the releases.
As for “moving the problem,” it is worth it. Because it’s easier to verify the origin of the software once, then for every update. If there’s a new vulnerability in TLS this will only affect new installations. Verifying (& signing) packages offline is much more anti-fragile.
The parent explained they might not trust verification on the target system. This might not necessarily be because the target is assumed malicious, but it may only have e.g. md5sum and not sha1sum available etc. (I'm obviously no expert... the hashing examples are just examples here)
I intended to suggest you could download it on a separate system which you do trust and verify it there. Then transfer it to the target system.
Otherwise signing packages is actually preferred, because you can do it offline, so that hacking the server is not enough to push malicious code.