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 >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
