Perform DSA signature verification in SparkleUpdateInfoProvider

[groob]

Recently, the Handbrake download was compromised to distribute a version of known malware.

Would it be possible for AutoPKG to check for the known, bad version of this software or is this out of scope?

Edit: the download was fixed, so this issue is more of a FYI for anyone that updated handbrake recently.

[gregneagle]

Would this not be covered by the VirusTotal postprocessor for those interested?

Sent from my iPhone

On May 6, 2017, at 12:15 PM, Victor Vrantchan [email protected] wrote:

Recently, the Handbrake download was compromised to distribute a version of known malware.

Would it be possible for AutoPKG to check for the known, bad version of this software or is this out of scope?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[macmule]

Hi folks,

So, I wonder if we could add a DSA signature check somehow to the Sparkle processor?

With Sparkle, you can sign an update. Within the AppCast.xml there is the DSA, as per:

sparkle:dsaSignature="MCwCFHIJEtiUSy0wRy5TjzXQmvYOTdDvAhQROkC8f7z+qF5FaY18aY3wWDPjFg=="

An app bundles info.plist should give details to the name of it's public key name, which is round in the /Resources folder within the app bundle:

<key>SUPublicDSAKeyFile</key>
<string>dsa_pub.pem</string>

FWIW, these examples were taken from AutoCasperNBI.. but Handbrake has the same.

[macmule]

if the DSA sig can be calculated via AutoPkg, I can test creating an app & invalidating the DSA

[timsutton]

I remember looking at this possibility when first working on the SparkleUpdateInfoProvider, and it was before there was already an established pattern of using the CodeSignatureVerifier processor as part of a download step. Now that this is commonplace, it seems reasonable to mount a DMG or read a file from an app's resources bundle.

It seems reasonable to me that if the code to do the signature verification could be done using no additional Python dependencies and work on all supported versions of macOS, then this could be worth doing as yet another validation of the download.

One way to implement this would be to implement the same verification code that Sparkle does (using CommonCrypto and PyObjC), or perhaps even better would be to use the pyobjc library support for dynamically adding your own bridgesupport metadata and actually load the Sparkle framework included with the app. The advantage is that you avoid re-implementing the verification code, and the disadvantage is trading one instability for another - relying on a method provided by the Sparkle framework whose signature may change subtly in different versions. Either way there are some concerns here to make it so that this works consistently across different OS versions and/or bundled Sparkle frameworks.