My DSA signature won't verify... :-(

I performed the exact steps you just listed on Sparkle Test App, and it worked just fine (somewhat to my surprise—I don't test this too often), so it must be something a little more persnickety. A couple things to check:

1. Check your compiled .app. Is the .pem *really* in Resources?
2. Are you sure the bytes didn't get manged between ~/MyApp.tgz and the server? Long shot, I know, but try re-uploading.
3. Break in NSFileManager+Verification.m:109. Are the method parameters all non-nil? Are they what you expect them to be? Is there some kind of weird whitespace or encoding nonsense going on that's throwing it off?
4. Step through the scary function in NSFileManager+Verification.m not to see what's going on, but specifically to determine which "return NO" is being tripped.

Hi Andy,

Thanks for the response. I appreciate your time as I know it's hard to develop Sparkle on top of everything else you, then answer people's questions!

So I walked this through the debugger again paying closer attention to your long shot ("#2 Are you sure the bytes didn't get manged..."). As it turns out, I created and signed a '.tgz' file but the downloaded file in '/var/folders/5o/5oKqC0zqFFGAJye0lC2y0U+++TI/-Tmp-/MyApp 0.0 Update' has been gunzipped prior to the verification (NSFileManager+Verification.m:109). So it's just a tar file now and of course, the dsa signature from the 'tgz' file is not valid for the 'tar' file.

I set breakpoints where I thought might be likely candidates in SUUnarchiver.m and SUPipedUnarchiver.m but it's not breaking there before the verification. So, I'm probably looking in the wrong place.

So my immediate work around is to sign the '.tar' file before I 'gzip' it. I need to know though, if this is expected behavior?

Maybe the name change (and gunzip??) is happening in NSURLDownload download:decideDestinationWithSuggestedFilename: ??

If I breakpoint SUBasicUpdateDriver.m:112 the url is MyApp.tgz. Continue to a breakpoint in the download delegate method at SUBasicUpdateDriver.m:117 and passed in "name" is MyApp.tar.

Ahh! If only I'd read the documentation...

"If NSURLDownload determines that the downloaded file is in a format that it is able to decode (MacBinary, Binhex or gzip), the delegate will receive a download:shouldDecodeSourceDataOfMIMEType:. The delegate should return YES to decode the data, NO otherwise."

It seems Sparkle doesn't deal with shouldDecodeSourceDataOfMIMEType. Should this be logged as a bug or is it by design?

Excellent detective work, sir! You've found a bug! https://bugs.launchpad.net/sparkle/+bug/246469

What I don't understand, though, is why this doesn't break extraction. SUUnarchiver doesn't know how to extract .tars. It shouldn't be able to extract your update. Curious.

 

I wish to add my two cents to this.

I had the exact same problem. I generated keys and signature using the ruby script. Publish my app cast ran my test and boom : "The update is improperly signed." Darn, what did I do wrong. I followed example on this page, generating in the terminal new signatures and testing that I could sign and verify. It worked just fine.

So I decided to add some NSLogs to sparkle to see what was going on. Obviously the signature would verify, but by printing (using NSLog in - (void)downloadDidFinish:(NSURLDownload *)d method of SUBasicUpdateDriver) the downdoalded path, which looked like

/var/folders/61/61O4hMUu2RWrXE+1YsfL7U+++TI/-Tmp-/Sauvegarde 1.0.1 Update 42/Sauvegarde.zip

using the DSASignature which looked like

MEUCIHd6pYSoQiuPb0j9wypbd9m8dXqtKiVl3iT++3sCUL83AiEAsPDcPKPmU0oQ J21ktE4Y8zRV9MFJ95jfPoLOtymnQtg=

and openssl in the terminal I could still validate my signature !?!. What the hell is going on ?

I then ran "which opennssl" in the terminal and got

/opt/local/bin/openssl

HaaaHA ! That bloody port had reinstalled and superseded /usr/bin/openssl by its own version, which is incompatible with the bundled version.

Ok then, lets retry with /usr/bin/openssl to generate signature and verify them. Does not work ! Darn. I changed my environment variables to make sure that openssl calls /usr/bin/openssl. Does not work.

It turns out, I had to regenerate my keys after updating the generate_keys.rb script from

#!/usr/bin/ruby
["dsaparam.pem", "dsa_priv.pem", "dsa_pub.pem"].each do |file|
  if File.exist? file
    puts "There's already a #{file} here! Move it aside or be more careful!"
  end
end
`openssl dsaparam 2048 < /dev/urandom > dsaparam.pem`
`openssl gendsa dsaparam.pem -out dsa_priv.pem`
`openssl dsa -in dsa_priv.pem -pubout -out dsa_pub.pem`
`rm dsaparam.pem`
puts "\nGenerated private and public keys: dsa_priv.pem and dsa_pub.pem.\n
BACK UP YOUR PRIVATE KEY AND KEEP IT SAFE!\n
If you lose it, your users will be unable to upgrade!\n"

to

#!/usr/bin/ruby
["dsaparam.pem", "dsa_priv.pem", "dsa_pub.pem"].each do |file|
  if File.exist? file
    puts "There's already a #{file} here! Move it aside or be more careful!"
  end
end
`/usr/bin/openssl dsaparam 2048 < /dev/urandom > dsaparam.pem`
`/usr/bin/openssl gendsa dsaparam.pem -out dsa_priv.pem`
`/usr/bin/openssl dsa -in dsa_priv.pem -pubout -out dsa_pub.pem`
`rm dsaparam.pem`
puts "\nGenerated private and public keys: dsa_priv.pem and dsa_pub.pem.\n
BACK UP YOUR PRIVATE KEY AND KEEP IT SAFE!\n
If you lose it, your users will be unable to upgrade!\n"

I.E. just prefixing openssl with /usr/bin/ three times in the script. Now it works and my superduper app can update.

Maybe that is worth a line in the instruction.

I would like to follow Simon's notes. I have exactly the same problem. Simon's solution work fine for me.
I think if it different version of openssl with different default settings, there should be some arguments to override that settings and that is better be put in the scripts.
Thanks.