Compute hashes in File Browser - page 2 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 [2]   Go Down

Compute hashes in File Browser

  • 16 Replies
  • 8605 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: Compute hashes in File Browser
« Reply #10 on: 24 / June / 2017, 13:28:55 »
Advertisements
Quote from: philmoz on 24 / June / 2017, 02:05:19
Ummm - why?
+1

I just can't imagine anyone using this. It might be cool and easy to implement, but that's all.

Hashes/CRC can potentially find other use in CHDK (say, core/module integrity check after loading), but displaying them on the LCD does not appear to be useful to me.
Logged
*

Offline dmitrys

  • ****
  • 267
Re: Compute hashes in File Browser
« Reply #11 on: 24 / June / 2017, 13:35:05 »
Quote from: srsa_4c on 24 / June / 2017, 13:28:55
+1

I just can't imagine anyone using this. It might be cool and easy to implement, but that's all.

I'm using this to check if binaries match those that I have on my hard drive.

Quote
Hashes/CRC can potentially find other use in CHDK (say, core/module integrity check after loading), but displaying them on the LCD does not appear to be useful to me.

So if somebody uploads a module they're developing, that would prevent CHDK from booting?
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Offline srsa_4c

  • ******
  • 4451
Re: Compute hashes in File Browser
« Reply #12 on: 24 / June / 2017, 14:06:52 »
Quote from: dmitrys on 24 / June / 2017, 13:35:05
I'm using this to check if binaries match those that I have on my hard drive.
I'd consider the file's timestamp sufficient, unless there are major problems with USB connection or the card.
Quote
So if somebody uploads a module they're developing, that would prevent CHDK from booting?
No, I meant checking executables for corruption.
1) The CHDK loader (files under loader/) does not currently check the CHDK core's integrity before it starts executing it.
2) Module integrity is not checked by the module loader.
These are obviously more difficult to implement, but might be considered more useful*.

edit:
*That can be debated, since files don't usually get corrupted.
« Last Edit: 24 / June / 2017, 14:09:22 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 14079
Re: Compute hashes in File Browser
« Reply #13 on: 24 / June / 2017, 15:50:10 »
I agree, programmatic access to hashes could be useful, I don't see much reason to expose it in UI. File browser size/timestamp is usually good enough.

Even if this has value, I don't see a need for many hash implementations. We aren't worried about cryptographic security here.

If it was available from script, then people who really needed it for some reason could use a script. I can think of a few uses to having it in script.


Quote from: dmitrys on 24 / June / 2017, 12:02:01
Quote from: reyalp on 24 / June / 2017, 00:50:02
It's not a matter of what the camera supports, neither gcc nor elf2flt no anything about that.

I'm sorry I didn't clarify. The code would build, but the File Browser won't start.

Quote
Did you do a full build (make clean all)?

I'm assuming I don't have to re-upload DISKBOOT.BIN, since this is an assembly command. Am I wrong?
You would need to re-upload DISKBOOT.BIN, because the added gcc builtin function would be in the core.

As explained in the comments in the .inc file this is the whole point of ABI exports: To have one copy of the gcc builtins in the core, rather than attached to each module.

As long as the compiler is given the correct CPU flags (which AFAIK, it is), it should not generate instructions the CPU cannot execute, and if it did, the result would be a crash not the module failing to load. The builtins are specifically there to implement operations not supported by the CPU instruction set, i.e. division, floating point, 64 bit integer...
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Compute hashes in File Browser
« Reply #14 on: 24 / June / 2017, 19:00:44 »
Quote from: dmitrys on 24 / June / 2017, 12:08:22
Quote from: philmoz on 24 / June / 2017, 02:05:19
Ummm - why?

Phil.

That's practically a no-brainer. md5 and sha1 were already there for eyefi, crc32 was a part of packfi2, and I already had sha2 adapted for the metadata generators. I picked crc16 from the Linux kernel.

I think this feature is at least as useful as "Replace CHDK" (which BTW happens to corrupt DISKBOOT.BIN if source == target).


The current file browser .flt file is 9K - yours is > 23K!


I just can't see any need to for having 8 different hash functions in the file browser.
I don't see how this benefits CHDK users.


Phil.

Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline reyalp

  • ******
  • 14079
Re: Compute hashes in File Browser
« Reply #15 on: 24 / June / 2017, 20:20:40 »
Quote from: dmitrys on 24 / June / 2017, 12:03:07
Quote from: reyalp on 24 / June / 2017, 00:55:36
If people want changes in the official svn, they need to post them here, not on random personal github repos.
If I post this as a patch, will it be accepted?
FWIW, I didn't say that to be bureaucratic, what I meant was I don't see patches if they aren't posted here.

As far as that specific change goes, I don't recall anyone posting problems with that setting. The recommended approach is to set set it in localbuildconf.inc. I believe the compiler GUI does this for you based on the selected compiler, which probably takes care of most newbies.

The autobuilds have been on EABI since 1.4, so I'd be more inclined just to drop elf support completely in 1.5.
Logged
Don't forget what the H stands for.
*

Offline dmitrys

  • ****
  • 267
Re: Compute hashes in File Browser
« Reply #16 on: 25 / June / 2017, 17:59:29 »
Thank you all for your feedback.

I created a Properties box instead, which in addition to date, time and byte size contains only the three most-used caches (MD5, SHA and SHA256). FWIW the size is down to 19k.

Quote from: reyalp on 24 / June / 2017, 15:50:10
If it was available from script, then people who really needed it for some reason could use a script. I can think of a few uses to having it in script.

One possible use is for checking upload/download integrity, in line with srsa's suggestion.

Should I try moving the hash implementations to lib and adding them to the Lua interface?

Quote
The autobuilds have been on EABI since 1.4, so I'd be more inclined just to drop elf support completely in 1.5.

If it were up to me, I'd remove it too. However, I know of at least one person who's still using the elf toolchain for building (a fork of) CHDK.
« Last Edit: 25 / June / 2017, 18:18:03 by dmitrys »
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics