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

[Red]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140612/bf0cde48/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/20140612/bf0cde48/attachment.sig>