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

Red redwire at riseup.net
Tue Jun 10 07:39:12 PDT 2014


On 2014-06-10, 7:05 AM, Maxim Nazarenko wrote:
> Good morning!
>
> I suspect we might use machine-readable date format (like YYYYMMDD) to
> keep the corresponding code cleaner, since it is mostly internal anyway.
Yan has been talking about using subversions of the extension release
version for the ruleset releases.  That way we can easily compare
version types using the nsIVersionComparator XPCOM class and have the
heavy lifting done for us.  We'll leave a date field in the update
object, but it would just be something there to present to users so they
can be informed when their most recent ruleset update was.
> Best regards,
> Maxim Nazarenko
>
> P.S. Looks like this email was private... Is it intentional? I suppose
> it should be tossed to the mailing list.
Making the email private was my mistake.  Thunderbird isn't quite clever
enough to put the mailing list in the reply-to section of my responses,
it seems.

> On 9 June 2014 19:11, Red <redwire at riseup.net
> <mailto:redwire at riseup.net>> wrote:
>
>     On 2014-06-09, 12:28 PM, Maxim Nazarenko wrote:
>     > 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
>     Oh, you're exactly right!  I completely forgot JSON allows arrays.  In
>     that case, we could have a structure like
>     {
>         "updates": [
>             {
>                 "branch" : "development",
>                 "date"     : "09 June, 2014",
>                  ...
>             },
>             {
>                 "branch" : "stable",
>                 "date"     : "21 July, 2014",
>                 ...
>             }
>         ],
>         "updates_signature" : ...
>     }
>     couldn't we?  That's a much better suggestion, Maxim! Thanks!
>
>
Yan has also stated in her comment
(https://gist.github.com/redwire/2e1d8377ea58e43edb40#comment-1242761)
that she feels it might still be better to take the approach of
releasing several different update.json files corresponding to different
extension release types.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140610/01f326ed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 341 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140610/01f326ed/attachment.sig>


More information about the HTTPS-Everywhere mailing list