hash type at beginning, hash itself at end.

[Sean Mullan]

My proposal for signed modules did not consider streamed writing as a 
requirement since this is not listed as a goal in the module file format [1]. As 
Roger points out, since the signature is over the hashes, the hashes must be 
calculated before writing the signature.

Thanks,
Sean

[1]: http://cr.openjdk.java.net/~mr/jigsaw/notes/module-file-format/


Reinier Zwitserloot wrote:
> Ah, well, with the added speediness on verifying authentications there's
> more of an argument to keep the hash where it is, at the top. Though, the
> time taken by parsing the stream is effectively nil; skipping a section is
> very simple by simply reading and discarding (size) bytes.
> 
> Creating jmods on the fly doesn't look like its going to be a common event,
> but nevertheless *if* there was no other reason to put the hash at the top,
> accomodating it is better than not accomodating it. However, if hash-at-top
> has extra benefits, as it looks like it does, then, consider my suggestion
> dropped.
> 
> --Reinier Zwitserloot
> 
> 
> 
> On Wed, Mar 17, 2010 at 1:52 AM, Roger Riggs <Roger.Riggs at sun.com> wrote:
> 
>>  Hi Reinier,
>>
>> The current placement allows authentication checks of the hashes to be
>> performed
>> without reading the entire package including parsing of all of the
>> sections.
>> Using the same hash for integrity and authenticity avoids duplication in
>> the package
>> and potential for inconsistency.
>>
>> As proposed, the header, signature, and module-info all can be verified
>> against
>> the signing information without reading the entire file to get the final
>> hash.
>> For larger modules early placement of this information allows verification
>> earlier and quicker identification of dependencies which can help decrease
>> processing and download times in cases where additional modules need to
>> be identified and fetched.
>>
>> It is likely that modules will be created on the systems where the
>> compilation
>> and build processes occur and random access files are available and the
>> need
>> to rewrite the hashes is not a problem.  It is much more likely that the
>> device
>> creating the package has more resources than the device receiving the
>> package.
>>
>> Are you envisaging that creation of modules is frequently done on demand
>> and in contexts where streaming is critical? Can you give an example?
>>
>> Roger Riggs
>>
>>
>>
>> Reinier Zwitserloot wrote:
>>
>> In Mr. Mullen's proposal for signatures, it looks like the hash (the one
>> that's been in the proposal for a while now, for data integrity, not for
>> verification of author) is still at the top of the file. This is convenient
>> for readers, but not for writers. You don't know the hash yet at the
>> beginning!
>>
>> The easy workaround is to rewrite the file after you're done, but this is
>> only possible when the target is on the file system. You can't rewrite parts
>> of the stream when the target is a db, a pipe, or the network.
>>
>> If you can't rewrite the stream, then the process is hopeless:
>>
>>  - store the entire file in memory first, hash it, then write it.
>>  - store the entire file with a dummy hash in a temporary file, then stream
>> that file, filling in the right hash.
>>
>>
>> A true solution to this problem is trivial: Send the *type* of the hash
>> algorithm at the top, and send the actual hash content at the bottom. This
>> is easy for both readers and writers.
>>
>> --Reinier Zwitserloot
>>
>>
>>