hash type at beginning, hash itself at end.

[Reinier Zwitserloot]

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
>
>
>