For a concrete example, consider the case where the server is compromised and an attacker wants to insert malware. HTTPS does nothing at all to help, here. The attacker has control over the server and can make it serve whatever it wants, and since the server still has its normal certificate and key, the attacker's malware-infested code will show up just like legitimate stuff would. If the code was signed using a key that isn't kept on the server (normally a code signing key will be kept on a developer's computer, and often protected by a password so it rarely exists in memory unencrypted) then the attacker can't force the server to serve malware that will be accepted by downloaders.
And to take this even further, you have the option of keeping the key on a machine that is completely disconnected from any network. In addition, this machine could use a Hardware Security Module to further increase the security of the signing key.
Not to also mention, MITM attacks on the actual SSL connection.
Serving over HTTPS isn't a valid package signing strategy.
The AMO cert is pinned in Firefox. If you MITM the connection, Firefox will refuse to connect to it.
HTTPS provides a secure connection, in theory, but what if AMO is itself compromised? They are just a 3rd party host for the EFF's extension, after all.
HTTPS or not, the only way to check that the code you get from AMO is the same code the EFF gave AMO, is to check it against the EFF's signature.
Without cert pinning here's also the problem of the attacker convincing some browser-trusted CA to issue an SSL cert for addons.mozilla.org, then MITMing you with that.
(And with 600+ trusted roots, many of which are owned by various governments, against state level attackers an ssl connection's claim of authenticity has to be considered very close to worthless...)
In the case of Firefox connecting to addons.mozilla.org, there is cert pinning.
(In retrospect, it's such an obvious thing for them to do - I don't know why I didn't assume it was likely enough to be implemented and check before I posted that...)
All they need is an authorised certificate.
More people should be aware of SSL Strip and how to protect yourself against it.
Not in the case of Firefox connecting to AMO, because it uses a pinned certificate for that.
I perform HTTPS interception on all out-bound traffic on my network and I don't recall making an exception for AMO, and I have a number of add-ons installed. Though, it wouldn't be the first time I've forgotten about something like that.
If a mirror isn't updated, the user is eventually warned during updates:
> E: Release file for http://mirrors/debian/dists/wheezy-updates/Release is expired (invalid since 1h 20min 30s). Updates for this repository will not be applied.
It mostly negates the need for https mirrors for authenticity, although many still offer it. To my knowledge, most projects with mirror networks operate similar to this.
[1] e.g. https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates... has the pseudo-header Valid-Until: Tue, 02 Dec 2014 20:50:35 UTC
RPMs are usually signed directly.
The reason you sign packages is to ensure that the file you want and the file you get are actually the same. If you have a secure connection to the trusted host of said file, you don't need to worry about that.