Hello everyone, I would like to quickly summarize what has been going on for the last couple of weeks of my work. Due to my mentor, Yan, being away on travel, we haven't had time to have a formal weekly meeting on IRC as per usual. We have, however, been emailing on the HTTPS Everywhere mailing list frequently to discuss some of the problems I've been working on last week. We have also compiled a list of things I am to work on for the next week, which I will summarize here. For the past week, I have been grappling with a problem pertaining to digital signature verification using the nsIDataSignatureVerifier XPCOM component designed to handle this task. I had written a few tests[1] that would use the testing mechanism that Yan built to make sure that the hashing and signature verification my project would rely on for security was working. The testing mechanism was built after our last meeting the Friday before last, during which time we realized we could write a separate Firefox extension using the addon SDK (and thus, Jetpack's testing suite) and import the HTTPS Everywhere component into that extension for testing purposes. Despite the fact that the process for producing the signature in question[2] seemed to work fine- Openssl was able to generate and verify the signature, the testing code calling the verifyData[3] function used for verification was returning an undocumented NS_ERROR_FAILURE exception. I had spent a great deal of time asking for support in relevant Firefox extension development IRC channels, reading source code from unit tests for the nsIDataSignatureVerifier component, and experimenting with alternative openssl commands in order to try to figure out why this error was occurring. Yan was able to get the test to pass by generating a key and signature using the NSS tools. However, she has said that this process is more involved than we would like, and is not likely feasible to accomplish on EFF's airgapped machine hosting its offline private signing key due to the lack of availability of NSS tools. To overcome this limitation, I will be porting one of either the Uhura tool that has been used in the past, or the pk1sign program[4] Yan had found referenced in a Bugzilla report. For now, that's what I'll be doing. I am feeling optimistic that, once this issue of generating an appropriate (i.e. verifiable by nsIDataSignatureVerifier) signature is resolved, writing tests for and refactoring the secure update mechanism I am building will be complete before long. I have compiled some of the discussion Yan and I have had via email into my weekly meeting notes[5], despite there having not been an actual meeting. As usual, I welcome any advice and input! Cheers, Zack [1]: https://github.com/redwire/https-everywhere/blob/feature/tests/https-everywhere-tests/test/test-rsupdate-verify.js [2]: https://github.com/redwire/https-everywhere/blob/rulesetUpdating/doc/updateJSONSpec.md#updatejson-and-updatejsonsig [3]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDataSignatureVerifier [4]: http://dxr.mozilla.org/mozilla-central/source/security/nss/cmd/pk1sign/pk1sign.c [5]: https://gist.github.com/redwire/b62f03905a826e79947a#week-8
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev