[HTTPS-Everywhere] [GSoC] Progress Report

[Red]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 276 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140814/94d0841e/attachment.sig>