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

[Yan Zhu]

On 06/12/2014 08:57 AM, Red wrote:
> On 2014-06-12, 7:18 AM, Jacob Hoffman-Andrews wrote:
>> > Instead of hashing a stringified version of the `update` object
>> directly, we could sort an array of the keys in the update object and
>> then create an array of key, value pairs in the sorted-key order.
>>
>> Presumably, we would also want to recursively sort any sub-objects in
>> the update object? What encoding do we use to serialize the update
>> object for signing?
> We actually sign the hash of `updateObj.update` (that is, the flat
> update object inside the outer object).  You can see what I've done to
> handle this automatically in the utility I built to handle most of the
> process of creating the update.json file contents:
> https://github.com/redwire/https-everywhere/commit/eaff57798a5682ec6171ef5c86a65df8b06c174b
> 
> As I mentioned in my previous email, because we have decided not to use
> a nested structure for the update object and are instead going to serve
> different update.json files from different URLs, there isn't currently a
> need to recursively convert objects inside `update` to a list of key,
> value pairs.  If that changes at some point, it wouldn't be hard to
> implement, though.

That still leaves open the question of how to serialize the array of
keys. As mentioned before, there is no guarantee that JSON.stringify is
deterministic across versions/environments. A quick Goog. search
suggests that various people have come up with variously-convoluted
solutions to this problem, including in more-or-less in the way you've
mentioned:
https://stackoverflow.com/questions/8931967/is-there-a-deterministic-equivalent-of-json-stringify

It might be a pain to always make sure that our js object serialization
code gives the same result across different Firefox releases, for instance.

Given this, I'm leaning toward Jacob's solution of taking the signature
over the raw bytes in the update JSON file, either as the first line in
the update file or as a detached .sig.

-Yan

> 
> 
> 
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere
> 


-- 
Yan Zhu  <yan at eff.org>, <yan at torproject.org>
Staff Technologist
Electronic Frontier Foundation                  https://www.eff.org
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x134

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