MaterialFiles icon indicating copy to clipboard operation
MaterialFiles copied to clipboard

Add checksums in file properties

Open panagiotopoulos opened this issue 5 years ago • 4 comments

Added a tab in file properties to check a file's checksum (MD5, SHA-1 and SHA-256). Hashes are calculated when user clicks on the appropriate text area. Closes #48

checksums_preview

Idea for future functionality: Text input to paste hash from clipboard and attempt to match against file's checksums (example: KDE's Dolphin File Manager).

panagiotopoulos avatar Jun 03 '20 17:06 panagiotopoulos

Thanks for the PR - but there are actually still a lot of other things to consider here.

  • When to compute the cheksums? What is the bottleneck of checksum computation, i.e. if only the FS read is expansive, why don't we just calculate the checksums all at once? What about start the computation when user clicks the checksums tab, which clear shows they want the checksums?
  • How to compute the checksums? Doing it on main thread (as in this PR) is unacceptible because it will freeze the UI, especially because checksums are often checked for big files. If we move it to background thread, how do we handle things like screen rotation? I'm thinking of addressing this in a common place because it will also beneift the address fetching for media GPS metadata.
  • The design - how does the user know they need to press the box with a down arrow to start computing checksums? Usually a down arrow means dropdown, or at most opening a new window, but definitely not starting a computation. I'm checking Dolphin and nautilus-gtkhash and still thinking of it.

The UI implementation is straightforward given the infrastructure built for other tabs, but it's these tricky things that prevented me from including checksum in 1.1.0. I'll think about and experiment more with this when I have time...

zhanghai avatar Jun 04 '20 00:06 zhanghai

Thanks for the feedback.

  • I decided to make the calculation in a lazy way (when user clicks the area) to avoid unnecessary computations (it's unlikely they need all 3 hashes anyway) since they are expensive. A cache could be added to store big file hashes and improve performance.
  • Calculating them in another thread is a possibility but then would require extra UI elements to show that it's computing something while the user is waiting (spinning bar maybe).
  • About the design - I wanted to add the feature with as little change possible to your codebase to avoid potential future conflicts. A totally different layout could be used for the checksum tab fragment with proper buttons. Is that something you would consider (I noticed you merged image, audio, video, apk tabs into a single layout a while back)?

panagiotopoulos avatar Jun 04 '20 10:06 panagiotopoulos

FX File Explorer has this nifty little feature that if you have a checksum copied to your clipboard, the app automatically reads it and compares it to the correct one when calculating the checksum for a file. No manual comparison needed. Could that feature be added here?

Regarding the UI, Tap to calculate after the name of the checksum would be fine, I think. The arrow should be removed.

opusforlife2 avatar Nov 29 '20 07:11 opusforlife2

Regarding Fx File Explorer, procedure:

  1. File properties open checksum tab
  2. Click calculate
  3. Click copy to clipboard
  4. Open another file and click calculate from checksum tab, wrong match: Checksum match: Same file checksum:

rancidfrog avatar Nov 29 '20 09:11 rancidfrog

MD5, SHA-1 and SHA-256

if i may suggest additional hash algorithms that are more modern and secure:

  • most important SHA-2 variants: SHA-256 and SHA-512 (optionally also SHA-384 and maybe even SHA-224)
  • most important SHA-3 variants: SHA3-256 and SHA3-512 (optionally also SHA3-384 and maybe even SHA3-224)

i included SHA-224 and SHA-384 because they're the only ones in the SHA-2 family that are not vulnerable to length extension attacks (SHA-3 fixed this)

i would even recommend against including MD5/SHA-1 or at least not preselecting them in the UI as

  • MD5 was already broken in 2008
  • SHA-1 was officially deprecated in 2011, broken in 2017 and is planned to be phased out by 2030

additionally a minor suggestion: preselect SHA-256 on 32-bit hardware and SHA-512 on 64-bit hardware (384 and 512 are more performant on 64-bit, while 224 and 256 are more performant on 32-bit), i think these would be good defaults because SHA-2 is way more widespread than SHA-3

masterflitzer avatar Apr 09 '24 10:04 masterflitzer

I've addressed some of the original concerns and added SHA-512 check.

Checksums are still lazily calculated but now their calculations are asynchronously performed in proper IO context and lifecycle. Once activated the text view will change to Calculating... and will be updated again when the result is ready. Finally, once calculated, the text can be long pressed to copy the checksum to clipboard.

if i may suggest additional hash algorithms that are more modern and secure

My main concern is that most software releases won't include hashes for those therefore the user won't have anything to compare against.

More algorithms can be added in the future depending on their popularity. Alternatively, a wider variety could be supported and then utilize a global setting to configure which of them are visible in tab properties as well as their order.

panagiotopoulos avatar Apr 13 '24 13:04 panagiotopoulos

won't have anything to compare against

comparing against own files like shown in some of the screenshots in this thread (fx file explorer) is also a valid use case, it's not only about downloaded files

masterflitzer avatar Apr 13 '24 13:04 masterflitzer