Hello, everyone. I've been working on implementing some of the solutions that have been discussed here earlier this week to finish the process of downloading a new ruleset database file and apply its contents. The code that has changed as a result can be found at: https://github.com/redwire/https-everywhere/blob/rulesetUpdating/src/chrome/content/code/rulesetUpdate.js#L149
I thought it was time I gave another status update, since I've been able to wade through a lot of documentation regarding and managed to implement: 1. Fetching the database file using the arraybuffer responseType. 2. Applying the new database by dropping the contents of the old one and inserting those of the new one. These two solutions have proven slightly nuanced as the extension now has to deal directly with binary files, and this has lead to the most recent problem, which is that the contents of the downloaded sqlite file are not hashing to the same value as the one in the "hash" field of update.json. I have avoided merging the master branch from the original repository so that changes to the rulesets library would not conflict with the test update.json data I am using. As I am very short on time, and should really be preparing to submit my report to Google after Yan writes her report regarding my work and makes the decision for a pass or a fail, I'm a little conflicted about where my efforts should be directed right now. Finally getting to the stage of actually testing to make sure that the new ruleset is applied may open up a new level of complications as we're dealing with actually modifying a file in the extension's base directory (which I've been told can/should not be done), and I can't even really imagine that I can have this binary file hashing issue sorted out in time for the firm "pencils down" date on the 18th. As much as I'd like to have this all sorted out and ready to be merged into the master branch of the main repo, I can't imagine this being possible in such a short amount of time, given that I keep getting snagged on these poorly documented details. Any suggestions for where to go from here would be greatly appreciated. Today I'll be updating the documentation for the update.json generation and signing process to describe the method Yan found involving using pk1sign and taking into account the fact that nsIDataSignatureVerifier doesn't like hashed data. I'll probably also write a more detailed summary for the benefit of this and the tor-dev mailing lists of my work throughout the entire Summer after Monday and after Yan has made her final report and decision for Google. Thanks again as always, Zack
signature.asc
Description: OpenPGP digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
