SUPublicEDKey from generate_keys fails NSData initWithBase64EncodedString

[devonhub]

Everything looked good moving from the old DSA SUPublicDSAKeyFile usage to SUPublicEDKey until I actually tried to run my app. Sparkle fails to initialize and displays an alert stating, "The update checker failed to start correctly." After stepping through the code, SUSigningInputString() fails trying to create an NSData object from the SUPublicEDKey string value. decode() returns SUSigningInputStatusInvalid.

I must be missing something simple here but after stepping through the code, it seems pretty clear ... NSData (and therefore Sparkle) does not like the SUPublicEDKey string from generate_keys. wth?

[zorgiepoo]

Likely the format of the key is wrong, what does it look like in your Info.plist?

[devonhub]

The following is the output from generate_keys, which as instructed from the console output, is copied into my Info.plist

<key>SUPublicEDKey</key>
<string>cwzHFjcbP+WBG9+CxCnVWUxPgH/zqJnLYNaFTtlEVNg=</string>

That string value results in a failure in decode() to create NSData from an expected base64 encoded string.

At first I thought maybe Sparkle didn't like that my Info.plist still had the old 'SUPublicDSAKeyFile' key/value in the Info.plist, so I removed that DSA properties (i.e. SUPublicDSAKeyFile and SUExpectsDSASignature). But after stepping through the Sparkle init code I discovered it was the failure in decode() with the string from 'SUPublicEDKey' generated by Sparkle's generate_keys.

Our of curiosity, I generated a ed25519 key pair with ssh-keygen. If I take the public key generated from ssh-keygen (68 bytes) and place it in SUPublicEDKey in the Info.plist, Sparkle likes that value and decode() executes successfully and Sparkle starts up without error. That presents a new problem though. Unfortunately, Sparkle's sign_update tool with the '--ed-key-file' does not like the private key from ssh-keygen. sign_update fails with an error that it was not able to decode the base64 key data. If I turn the block of text in the ssh-keygen generated private key into a single string of data (348 bytes long) with the standard '---BEGIN * PRIVATE KEY---/---END * PRIVATE KEY---' lines removed from the top and bottom, Sparkle's sign_update tool initially accepts that as an input file, and doesn't give me the base64 decode error, but instead spits out this error ...

ERROR! Imported key must be 96 bytes decoded.  Instead it is 258 bytes decoded.

(same output error occurs if I try to pass the private key into sign_update using the -s option).

If I leave the BEGIN/END lines in the private key generated from ssh_keygen, Sparkle's sign_update --ed-key-file gives me the base64 decode data error.

So here's where I'm at ...

• Sparkle will NOT startup with a SUPublicEDKey string value created by Sparkle's generate_keys.
• Sparkle will startup with a SUPublicEDKey string created by ssh-keygen.
• Sparkle's sign_update will NOT succeed with a SUPublicEDKey string created by ssh-keygen.
• Sparkle's sign_update will succeed with a SUPublicEDKey string by Sparkle's generate_keys.

What Sparkle wants as a public key is conflicting with what it can use to sign an update package. grrr

I've got to be missing something simple going on here because I'm pretty sure that if Sparkle's implementation of ed25519 had problems, more developers would be writing about this. Sparkle's supported ed25519 for many years now. This has got to be something in my environment. I'm building with Xcode 14.3 on macOS Ventura 13.2.1 (22D68). I haven't tried any of this on an older macOS version.

[zorgiepoo]

<key>SUPublicEDKey</key>
<string>cwzHFjcbP+WBG9+CxCnVWUxPgH/zqJnLYNaFTtlEVNg=</string>

This key works fine for me using Sparkle 2.4 and does not fail to decode. Can you double check the output of your Info.plist in your generated app bundle? (Check the built bundle).

Sparkle does not support generating EdDSA keys using other tools. The process for doing that "correctly" is more complicated than what you're trying. Check #2298 for more info.

[devonhub]

thanks for the replies, Zorg
The SUPublicEDKey string value above was copied from a build app bundle. While debugging, I'm running in a built app bundle.
I'm using Sparkle 2.0 though. I'll update to 2.4 and see if the problem goes away.

[zorgiepoo]

if you're in the debugger you might also be able to see what string it's decoding. It should not differ from our machines.. I don't recall there being any fixes regarding this from 2.0, but probably worth a try.

If you can share the bundle (not sure if you can) I can also take a look.

[devonhub]

I updated to Sparkle 2.4 and re-generated keys, carefully copy/pasted the given SUPublicEDKey string into the Info.plist and viola!, Sparkle starts up without complaint. I still had the breakpoint set in decode() and the alloc and init of NSData from the SUPublicEDKey string succeeds without any problem. I even went back to my old public key and pasted carefully pasted it into my Info.plist and Sparkle starts up just fine.

I reverted my changes and started over with the previous Info.plist, generated a new key pair, and then re-applied Info.plist changes It's working just fine and after re-signing the update packages with the new private key, and the full Sparkle update process completes without any problems.

What changed since last night? I'm not sure. I had walked through decode() several times and the NSData alloc init was failing before. The new key pair is working today.

Thanks for your patience.