[HTTPS-Everywhere] Replacing the rulesets database file

Red redwire at riseup.net
Sun Aug 10 11:01:23 PDT 2014


Hello, everyone.

I've been working on getting the last couple of parts of the ruleset
updating mechanism finished, and just have a couple of questions I was
hoping someone more familiar with extension development and the
preferred methodology of the project could answer.

So far the updater can fetch the update.json and update.json.sig files
and successfully verifies the authenticity of update.json provided a
valid signature.  All that really remains is to get the extension to
download the new rulesets.sqlite file and replace the old one with it.
I've discovered two problems with the method of using a simple
XMLHttpRequest to fetch the file, replacing the existing file with the
new one's contents (after verifying its hash matches the one provided in
update.json), and then reinitializing HTTPSRules.

The most pressing issue right now is that of the replacement and
reinitialization of the rulesets database.  The extension cannot replace
files in it's own basepath, so I have been working on moving the
database file to the extension's user's profile directory. You can see
what I've been working on do this in my commits since Commit 44fb14b in
my branch at
https://github.com/redwire/https-everywhere/commits/rulesetUpdating

The other problem is that the binary nature of rulesets.sqlite is
problematic for XHRs. When the file was fetched with a simple XHR, the
contents terminated after the SQLite version information at the
beginning of the file. When I asked in #extdev on mozilla's IRC network,
I was told I would have more luck downloading such a file using the
Downloads.jsm module, which you can see I started using in this commit:
https://github.com/redwire/https-everywhere/commit/92c765861cbf8a31c99507979ddee674b86b1e3d

Tomorrow is the "soft pencil's down" date for Google Summer of Code, but
the firm end date isn't until the 18th.  I've been "flying solo" on this
since the second re-occurrence of the signature verification problem,
which I overcame, but I want to really do my best to get this as ready
to ship as possible before then.  Since I haven't had much direction for
a while, I would sincerely appreciate it if anyone could suggest any
solutions to these last couple problems, alternative approaches, or even
just some general guidance so I don't go too far down one road and have
things not work out.

Thanks,
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/20140810/dc4403d6/attachment.sig>


More information about the HTTPS-Everywhere mailing list