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

[Maxim Nazarenko]

Actually, I believe we can have _several_ "update" objects stored in a
_single_ update JSON file (in an array may be? My JSON is not fluent). The
extension then will download the appropriate rulseset, this choice may be
either hardcoded or set via (hidden) prefs.
PROS: Less hassle with signing and distribution.
CONS: Transfer overhead. No secret ruleset flavors ^_^

Best regards,
Maxim Nazarenko


On 9 June 2014 07:14, Red <redwire at riseup.net> wrote:

> Yan and Jacob and I have been talking about version number strings in
> the update manifest that we've been refining a little bit lately.  I
> wrote in my comment on the gist
> (https://gist.github.com/redwire/2e1d8377ea58e43edb40) that I was
> thinking that we could have a part of the version string be interpreted
> specially as meaning the ruleset release is for the development release
> of the extension vs the stable version.  While it would technically be
> possible to, for example say that a ruleset release versioned A.B.C.preD
> could be interpreted as being version A.B.C.D of the ruleset library for
> the developmental release of the extension (pre, in this case, denoting
> this), this still leaves us with the problem of serving different releases.
>
> The extension will have to be able to fetch the most recent ruleset
> release information (the appropriate update.json file) for any given
> version of the extension- developmental or otherwise.  If we were to
> adopt an approach of marking the ruleset version like I described above
> to distinguish between developmental and stable releases, we would be
> able to serve one update.json file from one specific URL at all times.
> This, however, leads to the problem that many clients could fail to
> update between stable and developmental ruleset releases.  The only
> reasonable thing to do about this is to make the extension aware of
> specifically which URL it is to fetch an appropriate update.json file
> from.  That is, a stable HTTPS-E release may fetch the file from
> eff.org/.../update-stable.json, and a developmental release of the
> extension may fetch from eff.org/.../update-devel.json.
>
> To make it possible for the extension to make this distinction without
> requiring more extra work from the project's maintainers (such as in the
> case of remembering to update the format_version preference for database
> file compatibility we discussed), I propose the following solution:
> Releases of the extension store version information (in a preference,
> perhaps) (is this already done somehow?) pertaining to whether the
> release is a dev. release or a stable release.
> The extension refers to a hard-coded mapping (JS Object) of version type
> to the URL to fetch the appropriate JSON file from.
>
> I realize I'm back to proposing something we decided would be best
> avoided in the case of the database version format preference, which
> would require extra attention from maintainers and developers.  However,
> I think that this, unlike the database format version preference idea,
> is far more reasonable, as the only change that would have to be made
> would be to a string constant or preference that we might expect would
> only take on one of two or three easily-understood and descriptive
> values ('developmental', 'stable', 'willeatyourcomputer', ...).
>
> I'd like to know if anyone has a simpler idea for making the distinction
> between version types than this!
> Cheers,
> Zack
>
>
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140609/d5822cfc/attachment.html>