At a glance, it seems like your signature string is not properly encoded. The first bytes should be "MII" for a Base64 encoding of a DER-encoded signature.
Unfortunately I don't think I can make the usual IRC meeting tonight because I'm in France - let's try to meet on Monday instead? -Yan On 07/03/2014 07:36 AM, Red wrote: > Here's all of the test output on pastebin: http://pastebin.com/mYyw3WNW > The exact exception message I am getting is: > > Message: [Exception... "Component returned failure code: 0x80004005 > (NS_ERROR_FAILURE) [nsIDataSignatureVerifier.verifyData]" nsresult: > "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: > resource://gre/modules/addons/XPIProvider.jsm -> > jar:file:///Users/redwire/Developer/Sources/Projects/https-everywhere/test_profile/extensions/[email protected]!/bootstrap.js > -> resource://gre/modules/commonjs/toolkit/loader.js -> > resource://jid1-we5bqofc6sksmg-at-jetpack/https-everywhere-tests/tests/test-rsupdate-verify.js > :: exports["test update JSON signature validity"] :: line 78" data: no] > > On 2014-07-02, 10:05 PM, Yan Zhu wrote: >> On 07/02/2014 10:00 PM, Red wrote: >>> Hello everyone, >>> I've been working on writing some tests[1] for signature >>> verification and hashing using the unit testing solution Yan built after >>> we discussed some new ideas during our meeting last week, but have had >>> no success in getting signature verification working. I've been using >>> the nsIDataSignatureVerifier XPCOM component[2] to do this, using some >>> testing data and an RSA key pair[3] I generated just for testing. All of >>> my tests with hashing have worked perfectly well and are passing, but >>> for some reason my attempt at verifying the signature I created are >>> leading to an exception being thrown. I followed the process I outlined >>> in the update.json spec to create my key pair, an example update.json >>> file, and to sign the hash of the contents of update.json[4]. >> Could you post the exception that you're getting and the test output? >> >> -Yan >> >>> I've asked on both the #extdev and #jetpack channels of >>> irc.mozilla.org about this, and have scoured Google, Duck Duck Go, MDN, >>> and Stack Overflow for an answer to the question of what could cause >>> this behavior (and have referenced some code I found on github to >>> confirm I had hardcoded my public key and signature correctly), and >>> haven't turned up anything that brings me anywhere near a solution. So, >>> I come to you. As people who have worked on HTTPS Everywhere, are any >>> of you familiar with the process for verifying signatures, and could you >>> perhaps review my test to see if I've done something wrong? Are there >>> any alternative ways of verifying signatures (perhaps using an external >>> library) that might be more reliable? >>> >>> Thanks, >>> Zack >>> >>> Note1: my `ruleset_update_manifest.py` script doesn't append a newline >>> character to the end of the written `update.json` file, but I had added >>> one accidentally while playing with the content in vim. Rather than >>> hashing and signing the file again, I decided to simply append a newline >>> character to the hardcoded data in my test code. >>> >>> Note2: I've gone through a lot of permutations of, what I hope are, >>> reasonable modifications to my test code to try to resolve this issue, >>> so I highly recommend having a peek through the commit history on [1] to >>> get an idea of what I've been trying. >>> >>> [1]: >>> https://github.com/redwire/https-everywhere/blob/feature/tests/https-everywhere-tests/test/test-rsupdate-verify.js >>> [2]: >>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDataSignatureVerifier >>> [3]: >>> https://github.com/redwire/https-everywhere/tree/rulesetUpdating/utils/testing/sign_verify >>> [4]: >>> https://github.com/redwire/https-everywhere/blob/rulesetUpdating/doc/updateJSONSpec.md#updatejson-and-updatejsonsig >>> >>> >>> >>> _______________________________________________ >>> HTTPS-Everywhere mailing list >>> [email protected] >>> https://lists.eff.org/mailman/listinfo/https-everywhere >>> >> > > > > > _______________________________________________ > HTTPS-Everywhere mailing list > [email protected] > https://lists.eff.org/mailman/listinfo/https-everywhere > -- Yan Zhu <[email protected]>, <[email protected]> Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
