Improve security for validating archives

[zorgiepoo]

Sparkle extracts zip, tar, and dmg archives before validating the archive and validating the Apple code signing identity of the app contained inside the archives. This allows key rotation which lets a developer change their EdDSA signing key or their Apple Code Signing identity. Key rotation has been used by developers when losing keys or transferring ownership.

However there can be exploits in extracting archives themselves. We can increase security by always validating archives before extraction. Any updater that validates the downloaded archive ought to really do this (validating the archive provides better security than only validating the app contained inside it after extraction). We will still allow key rotation but only through code signed disk images.

This proposal means that we now check the Apple code signing signature of disk images, and only accept zip or tar archives that have been signed with Sparkle's (Ed)DSA keys. If the Apple code signing identity of the disk image does not match the original app to be updated, we will check its EdDSA signature. Key rotation will not be possible with zip or tar archives anymore.

To support validating the code signing identity of a disk image matches the host app, we will need to write a custom code signing requirement that tests the disk image is Apple issued, Developer ID signed, and has a matching Team ID as the host app. We will need to ignore the code signing identifier of the file.

For external (out-of-app) updaters, we may need to carve out a legacy path to continue allowing updates using the old policy for apps using older versions of Sparkle.

This also means that we will move towards recommending serving code signed disk images, rather than zip files, for updates. Historically disk image files have been hacky and slow to extract. However the next release (2.7) should make disk image extraction efficiency (with modern compression/formatting options) and fine-grained progress reporting on par with zip files. And it turns out there are cases where zip files are actually not well specified and less reliable to extract (e.g. #2544, #1691) -- not to mention they are worse for avoiding issues relating to App translocation which impact updating through Sparkle.

I think we will continue to keep a deprecated / log warning for apps that don't use EdDSA signing. There are several reasons for this: to support local development/testing which often may use a non-Developer ID certificate, support more efficient updates via delta updates, better safety/fallback in case the Apple signing certificate needs to change, avoiding code signing checks in the framework to determine update validity.

This is all agnostic to serving over HTTPS (our strongest line of defense still). Even today, a successful exploit would need to first compromise a developer's server.

Now I will need to test this to see if it can be done.

TLDR; better validation security in exchange for:

• No longer allow updating zip or tar or non-signed disk image files without using (Ed)DSA signing (this has already been deprecated by Sparkle)
• No longer allowing key rotation for tar and zip files, but will allow rotation for signed dmg files (in extreme cases where keys are lost or ownership transferred)