<div dir="ltr"><div><div><div>On 20 June 2014 01:19, Red <<a href="mailto:redwire@riseup.net">redwire@riseup.net</a>> wrote:<br>><br>> On 2014-06-19, 2:07 PM, Yan Zhu wrote:<br>> > Red:<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>> >> The fact that SHA1 is used is specified in the first paragraph of<br>> >> "Verification and Version Checking".<br>> >> Specifically: "SHA1 is currently being used as the hashing algorithm."<br>

> > Right, SHA1 is in the spec, but it would be better to also include it in<br>> > update.json itself. That way, if/when we switch to another hash<br>> > function, someone who is reading update.json or using it to manually<br>

> > verify a ruleset file doesn't need to find the version of the<br>> > specification that was current at the time of posting or look in the<br>> > corresponding checkout of the extension code, etc.<br>

> Oh, I see.  Then we can have the extension use whichever hash algorithm<br>> is specified in update.json.<br></div> Just be careful not to introduce the hash downgrade attack, i.e. only a few (supposedly secure) hash functions should be allowed.<br>

<br></div>Best regards,<br></div>Maxim Nazarenko<br></div>