<div dir="ltr"><div><div><div><div>Two more ideas:<br><br></div>1) Switch the design documentation to Git as opposed to Gist -- pull requests are great!<br><br></div>2) Consider using SHA3 (or at least SHA2) instead of SHA1 -- performance loss should be negligible. According to <a href="http://valerieaurora.org/hash.html" target="_blank">http://valerieaurora.org/hash.html</a> , SHA1 is way into the orange zone :)<br>
<br></div>Best regards,<br></div>Maxim Nazarenko<br><div><div><div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 June 2014 22:43, Yan Zhu <span dir="ltr"><<a href="mailto:yan@eff.org" target="_blank">yan@eff.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nice work! I have some comments on the spec below (why does gist not<br>
allow you to post inline comments??)<br>
<br>
> However, fetching files using standard XMLHTTPRequests from within the<br>
extension is trivial to accomplish and standards-compliant.<br>
<br>
What does standards-compliant mean here? Maybe omit.<br>
<br>
> And finally, the public key to hardcode into the HTTPS-Everywhere<br>
extension to enable it to verify such signatures can be output to<br>
pubkey.pem via the command [...]<br>
<br>
This command should be modified to generate a base64-encoded signature,<br>
which is what nsIDataSignatureVerifier expects.<br>
<br>
Note that the header/footer of pubkey.pem need to be stripped before<br>
giving it as input to nsIDataSignatureVerifier.<br>
<br>
> If an attempt to fetch or verify an update fails, the extension should<br>
request update.json again every 5 + R minutes, where R is a random<br>
number between 0 and 5.<br>
<br>
The padding should be a random integer in milliseconds, so it's probably<br>
better to specify this time interval in milliseconds.<br>
<br>
> Every time the extension finds that the data provided by update.json<br>
to be inauthentic, either as a result of the hash of the database file<br>
not matching or the signature not verifying, the extension must send a<br>
POST request to a hardcoded url containing the data in the update.json<br>
file that it tried and failed to verify.<br>
<br>
Replace "hardcoded URL" with "hardcoded failure-reporting URL" for<br>
clarity. Add that the format for failure reports is yet to be determined.<br>
<br>
> This will, of course, only occur after the extension has determined<br>
that an update to the ruleset database is available, and verified the<br>
content of the update.json file to be authentic.<br>
<br>
Replace with "Replacing the local rulesets library will only occur after<br>
validating update.json (pseudocode below)."<br>
<br>
> The format for the date is " , ". For example, "08 June, 2014".<br>
<br>
Why not 08-06-2014 for easier date comparison in JS if we ever need to<br>
do it?<br>
<br>
> hash is a SHA1 (for now) hash of the database file's raw content.<br>
<br>
What encoding should we use for the hash? The default from<br>
<a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICryptoHash#finish%28%29" target="_blank">https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICryptoHash#finish%28%29</a><br>
is base64, so I would lean towards that.<br>
<br>
Also, it's better to specify SHA1 somewhere in the update.json file in<br>
case anyone is reading it independently. This could either be an<br>
additional field, or we could use the format<br>
"sha1/5R0zeLx7EWRxqw6HRlgCRxNLHDo=" (<name of hash function>/<base<br>
64-encoded string).<br>
<br>
> Pseudocode of update procedure [...]<br>
<br>
line 9: "update.version" should be "updateData.version"<br>
<br>
"inauthentic" should be initialized to true instead of false so that if<br>
isValidSignature throws an error or gets skipped, nothing is updated<br>
(generally safer).<br>
<br>
updateData.source should be validated to be a valid <a href="http://eff.org" target="_blank">eff.org</a> URL before<br>
fetching it.<br>
<br>
if any of the XHR fails (due to network disconnectivity, for instance),<br>
we should try again in 5 minutes plus padding.<br>
<div><div><br>
<br>
<br>
On 06/17/2014 06:18 PM, Red wrote:<br>
> I have recently been working on updating the ruleset updater spec to<br>
> reflect the changes that Yan and I discussed during our meeting last<br>
> Friday (notes at<br>
> <a href="https://gist.github.com/redwire/b62f03905a826e79947a#week-5" target="_blank">https://gist.github.com/redwire/b62f03905a826e79947a#week-5</a>), so I<br>
> wanted to inform everyone of the changes. If anyone would like to have<br>
> a look over the document, I'd be happy to receive any suggestions for<br>
> improvements.<br>
> <a href="https://gist.github.com/redwire/2e1d8377ea58e43edb40" target="_blank">https://gist.github.com/redwire/2e1d8377ea58e43edb40</a><br>
><br>
> Another thing I want to report is that I have finished updating the<br>
> utility script I have also been working on to automate most of the<br>
> process of building the update.json file. One thing I have added into<br>
> it is a simple mechanism for creating and applying sanity checks to<br>
> input values. One such test is the "valid_eff_url" function I wrote<br>
> that attempts to match the provided source (directing the extension to<br>
> the location of the ruleset database file) to a valid <a href="http://eff.org" target="_blank">eff.org</a> URL<br>
> (ending with .sqlite). I wrote the regular expression here specifically<br>
> to be exactly the same as what would be used to repeat this sanity check<br>
> in the update mechanism itself. I have tested the regex in both Python<br>
> and Javascript and found it behaves the same in Javascript and Python,<br>
> but as Yan suggested, it seems obvious that several others should review<br>
> this regex to be sure. Here is a direct link to the beginning of the<br>
> function.<br>
> <a href="https://github.com/redwire/https-everywhere/blob/makeJSONManifest/utils/ruleset_update_manifest.py#L58" target="_blank">https://github.com/redwire/https-everywhere/blob/makeJSONManifest/utils/ruleset_update_manifest.py#L58</a><br>
><br>
> Cheers,<br>
> Zack<br>
><br>
><br>
><br>
</div></div><div><div>> _______________________________________________<br>
> HTTPS-Everywhere mailing list<br>
> <a href="mailto:HTTPS-Everywhere@lists.eff.org" target="_blank">HTTPS-Everywhere@lists.eff.org</a><br>
> <a href="https://lists.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://lists.eff.org/mailman/listinfo/https-everywhere</a><br>
><br>
<br>
<br>
--<br>
Yan Zhu <<a href="mailto:yan@eff.org" target="_blank">yan@eff.org</a>>, <<a href="mailto:yan@torproject.org" target="_blank">yan@torproject.org</a>><br>
Staff Technologist<br>
Electronic Frontier Foundation <a href="https://www.eff.org" target="_blank">https://www.eff.org</a><br>
815 Eddy Street, San Francisco, CA 94109 <a href="tel:%2B1%20415%20436%209333%20x134" value="+14154369333" target="_blank">+1 415 436 9333 x134</a><br>
<br>
</div></div><br>_______________________________________________<br>
HTTPS-Everywhere mailing list<br>
<a href="mailto:HTTPS-Everywhere@lists.eff.org" target="_blank">HTTPS-Everywhere@lists.eff.org</a><br>
<a href="https://lists.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://lists.eff.org/mailman/listinfo/https-everywhere</a><br></blockquote></div><br></div></div></div></div></div></div></div></div>