location of hash code in the module file format: Current State?

[Mark Reinhold]

> Date: Sun, 07 Feb 2010 03:46:48 +0100
> From: Reinier Zwitserloot <reinier at zwitserloot.com>

> I believe the last update of the module file format spec now lists the hash
> at the top of the file, vs. the original version where it was at the bottom.

Yes, that's right.

> I don't think either is correct, the only strategy that is simple for all
> tools (both readers and writers) is for the type of hash to be at the top,
> and the actual hash value at the bottom; that way, writers can write to a
> stream (as in, writers don't have to buffer the whole module and they don't
> have to go back and edit the start of the stream), and readers don't have to
> buffer anything either and can just check on-the-fly.

Optimizing the format for writers isn't a priority, and I don't think
it's an undue burden on readers to save the hash for as long as it takes
to read the stream.  Placing the hash at the front is convenient for some
types of readers, e.g., the code for publishing module files to a web
repository, which stores the hash in a central index as a sanity check.

> If splitting this up is not a good idea, I suggest we revisit dropping
> support of multiple hash algorithms and instead pick one with reasonable
> security implications but a lightweight implementation, or, if that doesn't
> exist, to mandate 2 hashes, a lightweight one and a more robust one, with
> certain simple mobile platforms making do with only checking the
> lightweight.

Do you mean to require that every module file contain two distinct hash
values, using different algorithms, whereever the current format requires
only one?  Or do you just want to limit the number of algorithm choices
to two?

>              I doubt such platforms would ever _make_ a module file.

Agreed.

- Mark