Add release engine for Sparkle

[ezekg]

Respond with an XML payload that follows the Appcast format. Requires #475, #476 and #477.

GET https://sparkle.keygen.sh/<account>/<product>/appcast \
  -d platform=darwin
  -d channel=stable
  -d filetype=zip

Depends on outcome of sparkle-project/Sparkle#1980.

[ezekg]

Here's the minimal required Appcast item schema:

<item>
  <title>{release.name}</title>
  <link>{product.url}</link>
  <sparkle:version>{release.version}</sparkle:version>
  <sparkle:channel>{release.channel}</sparkle:channel>
  <description>
    <![CDATA[
      {release.description}
    ]]>
  </description>
  <pubDate>{release.created_at}</pubDate>
  <enclosure url="{artifact.url}"
             sparkle:edSignature="{release.signature}"
             length="{release.filesize}"
             type="application/octet-stream" />
</item>

Channel should be stable => default, or left blank when stable.

[ezekg]

Sparkle, at least v2, does seem to send a useful user agent:

$(BundleDisplayName)/$(BundleDisplayVersion) Sparkle/$(SparkleDisplayVersion)

If we ever needed to use that to figure out how to respond, e.g. with an XML appcast when listing releases instead of JSON.

[ezekg]

Sparkle does support custom HTTP headers. This may be workable with an appcast that has relative URLs.

[ezekg]

If we automatically generated the appcast server side, then we’d need to allow an account admin to export their own private keys so that they can use it to sign their releases. We have to do this because Sparkle is eventually going to support signed appcasts, and if we’re generating them, we’d need the private key.

I don’t like this for 2 reasons though:

1. It puts risk on the account owner leaking their private key, which would compromise an entire account since license keys could now be generated and signed, and responses from us could be forged.
2. It merges publishing keys with account signing keys, and removes the inherent trust that the author is the only one in possession of the publishing keys. This adds risk.

To derisk 2, we could allow a separate publishing key to be provided to Keygen CLI.

[ezekg]

If we generate the appcast on behalf of the user, there's no way to set sparkle:minimumSystemVersion.

Another reason to not generate it ourselves and just let the publisher do it...

[ezekg]

What if we serialized a release's metadata as sparkle:* tags? May be worth looking into...

{
  "metadata": {
    "minimumSystemVersion": "10.11"
  }
}

Or simply serialize any metadata keys with a sparkle: prefix.