Hash type too inflexible #6
Description
The current design has the hash in the setup package stored as a plain byte
array. I presume that the plan is to support longer hashes in the future by
checking the length of the array, but this has one major flaw.
Presume that a SHA-3 algorithm is selected. It will likely be reccommended for
widespread use shortly thereafter. If a subsequent flaw is found, any
replacement chosen or tweaks applied will keep the API invariant, *including*
the digest length. The versioning inherent in protocol buffers will not help
because the current protocol is insufficiently self-descriptive and has
unwarranted assumptions. I would suggest including some sort of identifier of
which hash is in use.
Original issue reported on code.google.com by Eternal...@gmail.com on 6 Mar 2012 at 6:21