Dev.to WebDev πŸ›  Dev πŸ‘ 0 πŸ“– 3 min read

Comparing a Download Against Its Published SHA-256: Four Pastes Into the File Studio Checkbox

I work on OnePassApps - this is our own product, and everything below is a measurement of our live build in the browser, not a description of what the tool is meant to do. The File Studio hashes a file in the tab. Below

I work on OnePassApps - this is our own product, and everything below is a measurement of our live build in the browser, not a description of what the tool is meant to do.

The File Studio hashes a file in the tab. Below the digest there is a second box: a section headed "Compare with a trusted checksum" and the instruction "Paste the checksum published by the source." That box is the one I wanted to test, because the checksum comparison is the step where you decide whether the file you downloaded is the file its publisher said it was - and it is the step most likely to phone home.

What I ran

  • File: onepassapps-proof.bin, 65,536 bytes of random data written to disk on this machine.
  • The digest the panel displayed after its own Calculate SHA-256 button: 471052bf33232ea9a58fd1c2466252660a094a02ce701bf4890d4d2d3d8be8dd
  • An independent digest of the same file from sha256sum in a shell: 471052bf33232ea9a58fd1c2466252660a094a02ce701bf4890d4d2d3d8be8dd
  • The two strings are identical, character for character.

Four pastes into the compare box

I pasted four things into the box, one at a time, clearing it between runs and reading the field back afterwards to confirm that exactly what I intended was sitting in it.

1. The exact lowercase digest. The panel reported: "Matches. The checksums are identical." and "Checksums match. The file is identical to the trusted copy."

2. The same digest in upper case. The panel reported the same match. SHA-256 digests get written in either case, and this comparison does not care which: the same 64 hex characters in a different case still match, so a publisher who lists an upper-case checksum does not trip the check.

3. The same digest with one character changed. The panel reported: "Does not match." and "Checksums differ. Do not trust this copy of the file."

4. A full sha256sum output line - digest, two spaces, filename - the format you get if you copy a line straight out of a .sha256 file. The panel reported: "Does not match." and "Checksums differ. Do not trust this copy of the file." The box compares the text you paste against the digest as text; it does not parse the sha256sum output format, so paste the digest on its own.

What crossed the network while I compared

With the network log open for the whole session, the four comparisons produced 3 GET requests to api.onepassapps.com - the app's own runtime and feature-flag calls. None of them carried a request body, and none had the digest or the filename anywhere in the URL. The comparison happens in the page.

Limits of this run

  • One browser, one build, today, signed out, one file, one algorithm (SHA-256). I did not test the other File Studio tabs or other algorithms.
  • I read the panel text before and after each paste and quoted it verbatim rather than paraphrasing a verdict.
  • The digests were checked against sha256sum in a shell - two independent implementations, so the tool is not grading its own homework.
  • One run of each paste, so I am reporting what the panel said, not how often it says it.

The tool is here: File Studio. The written guides are here: app guides.

If you know a checksum flow that behaves differently, I would like to hear about it. The earlier post in this series traced the hashing request by request: what actually goes over the network when you hash a file in the browser.

πŸ“° Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.