Appcenter: Support Sparkle EdDSA Signatures for Mac releases

[OskarGroth]

Describe the solution you'd like
App Center should add support for EdDSA signatures in the metadata for a macOS release.

Describe alternatives you've considered
Using the deprecated DSA signatures.

Additional context
Sparkle has deprecated DSA signatures in favor of EdDSA signatures:
https://sparkle-project.org/documentation/#eddsa-ed25519-signatures
App Center is still using the deprecated DSA signatures in RSS feeds for macOS Releases. As a result, after setting up Sparkle and App Center by their respective current documentation, my app is unable to update. The solution is a quick fix, and backwards compatible as both DSA signatures and EdDSA signatures can coexist in a Sparkle RSS feed: https://github.com/sparkle-project/Sparkle/issues/1360#issuecomment-461969149

[rgbworld]

Agreed this is a huge issue that should be relatively easy to resolve. I was about to submit my own own feature request and found this, so I'll add my request here.

Describe the solution you'd like
Please add support for Sparkle EdDSA signature. It nearly impossible to use the older DSA signature when building and deploying apps on recent versions of macos.

Describe alternatives you've considered
The only alternative is to build on macos 10.12 which is already several years old.

Additional context
Sparkle documentation clearly states that we should be using EdDSA.

Sign the published update archive with Sparkle’s EdDSA (ed25519) signature.
Sparkle before version 1.21 used to use only older DSA signatures, which are now deprecated.

Additionally, in order to use deprecated DSA signatures requires manually signing the release and using OpenSSL - which has been replaced with LibreSSL. So, it is nearly impossible to use the old signature. IMO, this should also be flagged as a security issue and prioritized.

[ahdbilal]

Thanks! We are adding this into our feature backlog. I will share more details here when there is an update!

[rgbworld]

Here are some details that my help move this feature along. I just completed building a macOS app that uses Sparkle.framework.

Supporting both the deprecated DSA signature and the new EdDSA signature in a single appcast.xml file requires that both sparkle:edSignature and sparkle:dsaSignature attributes be present in a single enclosure tag within the _appcast.xml_ file. Here's an example (with fake signature data).

<enclosure url="https://www.somedomain.com/appcast/MyAwesomeApp.dmg" sparkle:version="246" sparkle:shortVersionString="1.1" length="15554321" type="application/octet-stream" sparkle:edSignature="WULek#TCad+9kAqH2ZwJfaGmeVibqUYx" sparkle:dsaSignature="bXzXtawMAvofngcHWcmtZzPLaCkjqAtf"/>

Regarding the signing process, it is as simple as placing the .dmg and/or .zip file(s) into a folder and calling generate_appcast MyAppCastDirectory. This generates an appcast.xml file with an item node for each of the archives. The enclosure tag(s) will contain only the sparkle:edSignature attribute. The sparkle:dsaSignature attribute has to be manually created and inserted into the existing enclosure tag.

To create the DSA signature, each of the archives (.dmg and .zip) must be individually signed using the deprecated sign_update Sparkle tool. The old tool is located in the Sparkle package under Sparkle-1.23.0/bin/old_dsa_scripts. I renamed the old tool to sign_dsa_update to avoid confusion with the current tool - having the same name.

The sign_update tool wants a file, so I pull the private key data from my secure keychain and create a temporary disk file named priv_key.pem. Then I am able to call:

`/usr/local/bin/sign_dsa_update MyAppCastDirectory/MyAwesomeApp.dmg SomeTempDirectory/priv_key.pem`

Doing that with each of the archives returns the DSA signature for each. The only thing left to do is add (insert) the sparkle:dsaSignature attribute into the enclosure tag(s) with the corresponding signature data. In my automated script, I accomplished that using Nokogiri.

Given that required signature(s) are different depending on the release type:

• Transitional (containing both signatures)
• Modern (containing only EdDSA signature)

I would think that AppCenter will have to allow us to upload a DSA private key (and maybe the EdDSA private key). If there exists a DSA key for the app, then perform the additional signing and insert the sparkle:dsaSignature attribute. Maybe provide a checkbox to "Create Transitional Appcast" that will perform the additional steps. That would allow us to create either a transitional or modern appcast.

Whether or not the appcast contains one or both keys is very important because it must correspond to the binary. If it is a _transitional_ appcast, the binary has to contain a dsa_pub.pem file and a SUPublicDSAKeyFile in the apps info.plist file, along with the SUPublicEDKey. If it is a _modern_ appcast, it cannot contain the DSA key/file.

Hope that helps!

[OskarGroth]

@rgbworld Everything you just outlined is standard Sparkle setup and doesn't really apply to this issue. Note that Sparkle already works today with AppCenter using legacy DSA signatures. There is no need to (and you really shouldn't) upload private signing keys.

Literally the only change needed by the AppCenter team is to add a RSS attribute for EdDSA, and make sure it gets included in the AppCast. So going from:

  "metadata": {
    "dsa_signature": "string"
  }

To

  "metadata": {
    "dsa_signature": "string",
    "ed_signature": "string"
  }

That's it. Which one you use (dsa, edsa, or temporarily both) should be left up to the user.

[rgbworld]

Understood. I was simply explaining that when using both signatures it requires only 1 enclosure tag. It wasn't very clear to me after reading Sparkle docs. Additionally, the AppCenter team _does_ have to create the appcast, so I thought it was useful information. Provided the AppCenter team does as you said and updates the AppCenter API allowing us to set either or both metadata signatures, we would be golden.

[Jamminroot]

Hey @rgbworld @OskarGroth, im here with an update - work on edDSA support is now complete, and changes are deployed.
I'm closing the issue, but feel free to reopen it have you something to share.
Have a nice day!