[HTTPS-Everywhere] Draft specification for file used to check for ruleset updates

Maxim Nazarenko nz.phone at mail.ru
Wed May 28 00:07:02 PDT 2014

Hello everyone,

On 27 May 2014 22:53, Red <redwire at riseup.net> wrote:
> Yan mentioned during our meeting last week that the db_signature field
> was redundant since the hash of the database is part of the update
> object, so the update_signature is really the only signature needed.

Totally agree, my suggestion (two signatures instead of signature+hash
combo) was purely stylistic.

> Yan mentioned including a url to the HEAD of whichever branch of the git
> repository corresponds to the version of the extension installed.  In
> hindsight, I'm not sure I completely understood what you meant by that,
> and what utility it would provide.  Could you elaborate on that here
> when you get a chance?

The idea is that we can have several ruleset at the same time, each of them
is "current" in its own right, and we do not want them mixing. Indeed right
now this functionality is implemented via branches: there are stable,
developer and "git master" rulesets (hence my term), but after some
consideration I believe we can call them "flavors" or something similar,
since that's what they are for a end-user. E.g. a Firefox installation can
be Nightly, Aurora, Stable or LTS, and won't change its flavor while
updating. Hope this helps!

Best regards,
Maxim Nazarenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140528/1af26482/attachment.html>

More information about the HTTPS-Everywhere mailing list