Re: [integrity] What should we hash?

Hi

Below is how I imagine things would work for a .tar.gz. But, recall
that this is the exception rather than the rule and if this seems
awkward, remember that it is this or making even day to day use of
gzipp'ed images etc awkward.

Server Side:
1. Developer uploads foo.tar.gz file
2. Developer does zcat foo.tar.gz | sha256sum and notes that down.
3. Developer adds "<a href="foo.tar.gz"
integrity="ni:///sha-256;whatever" download>

Browser:
1. User clicks on link.
2. Browser sees that there is an integrity attribute on the download
link and remembers the SHA-256 value to check.
3. Browser receives a .tar.gz with "Content-Encoding gzip".
4. To verify that the hash matches, browser undoes the Content
encoding and checks the hash. If hash doesn't match, the browser tells
user and throws away the download.
5. If the hash matched, then browser, as usual, saves a foo.tar.gz
file to the user's harddisk.

-----------

I imagine there is a 1a: "Developer realizes sha256sum on .tar.gz
doesn't work and googles for a solution and realizes what is needed
because Mike West posted the answer on StackOverflow"

I don't deny this is ugly but I can't see a better mechanism than
this. The .tar.gz case with an integrity attribute really is the
exception, imho, and we shouldn't optimize for it.


What do you think?

thanks
Dev


On 13 March 2014 11:44, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 3/13/14 12:48 PM, Devdatta Akhawe wrote:
>>
>> The browser can do whatever it does right now. But for integrity
>> verification, it will need to undo content encodings like gzip.
>
>
> Hmm.  That's actually pretty annoying to implement, on both the browser and
> the server.
>
> Consider the current data flow.  Right now, the server just has a .tar.gz
> sitting on a hard drive.  When you ask for it, it sends it.  The browser
> receives the data, and streams it directly to disk.
>
> What is the proposed data flow, both on server and client, with integrity
> verification?
>
> -Boris

Received on Friday, 14 March 2014 06:52:45 UTC