Verify integrity by hash if served by HTTPS, not by signature

[GamePad64]

Appcast is secure and unmalleable by definition, if served using HTTPS. So, we need to only protect enclosures. The simplest and robust solution is to use plain-old hashes.

Advantages:

• we do not need to store secret somewhere secure
• there is no chance to lose the private key
• verification can be performed without public key
• hash is reproducible, so hash(binary) yields the same result every time

Proposed syntax:

<enclosure sparkle:integrity="sha256-base64_encoded_hash">

This attribute has the same semantics, as Subresource Integrity in HTML, which is widely used for the same purpose, as signature in Sparkle, but implemented in more streamlined way.

Also, SHA2 algorithm family is CPU-accelerated, so the computation is easier, even on very old machines, also being more energy-efficient.

[kornelski]

There have been cases where application authors had their web servers hacked, but not their private machines. In these cases Sparkle's signatures have proven to be beneficial and prevented automatic spread of malware. I think that's important.

There have been proposals to sign appcasts themselves. #971 If appcasts were signed, then checksum in the appcast would suffice. Otherwise I'm afraid subresource integrity would not be sufficient against appcast replacement hacks. HTTPS protects transit, but not data at rest.

[GamePad64]

The case of hacked web servers is valid, but the code is already signed using Apple Code Signing, so the malware will have invalid signature anyway, so the user machine is already protected by Gatekeeper.
A more realistic case is transmission or i/o error, leading to bit errors in update packages, and hashsums work perfectly well here.

[kornelski]

HTTPS already prevents transmission errors. Apple Code Signing checks integrity too.

[zorgiepoo]

Appcasts are not generally trusted by Sparkle, servers can be hacked, app bundle code signing checks are not done with 100% integrity, so EdDSA is still needed, and signing appcasts in future might be nice (optional) future improvement.