metadata hashes used in a way that negates security benefits

[jku]

There seems to be a logic mistake in the way hash checks are done WRT parsing metadata: the point of having hashes for metadata is that parsing completely unverified data can be avoided. The go-tuf client implementation parses the metadata before checking the content hash. This makes using metadata hashes a bit pointless: Once the metadata has been parsed, we have access to signatures...

Details: downloadMetaFromTimestamp() downloads bytes, then calls GenerateTimestampFileMeta() that parses bytes to metadata. Then it calls TimestampFileMetaEqual() to verify byte hashes. I did not look at the same process for snapshot but I assume same is true there.

The logical order for these operations is:

• download bytes
• check hashes of the bytes
• data is now known to be "vouched for" by delegating metadata: parse/unmarshal bytes into metadata
• do the checks that require parsed metadata (signature, version, etc, ...)

this order is documented in the spec as well, although it does not explain the reason for this order of events and does not specify that data should not be parsed before hash checks.

see also #229