It would constitute a collision because it would mean that two clients had
different ideas of the contents of a file prior to the USHI request. If
you wanted to maintain a repository that tracks SHA1 PDFs that collide you
would have to issue an USHI first to something other than SHA1, or start
out with something other than SHA1.
Adding the size isn't particularly meaningful since the USHI's goal is to
safely upgrade file identifiers (which are SHA1 right now) to something
else and the size wasn't considered part of the identifier.
On February 28, 2017 3:36:34 PM "Andy Bradford" <amb-fos...@bradfords.org>
wrote:
Thus said Roy Keene on Tue, 28 Feb 2017 11:13:01 -0600:
e. If a collision is submitted (e.g., same SHA1, different SHA256)
the artifact (by SHA1) is considered compromised and shunned from
the repository (or something)
Why would this constitute a collision? Wouldn't a collision only happen
IFF all listed hashes have a collision? What would be wrong with holding
content of two artifacts that have colliding SHA1 but differing SHA256?
What if I want to maintain a repository that tracks the SHA1 PDFs that
collide?
Would adding the Size of the artifact strenghten the the U-card?
U SIZE 321 SHA1 3301ac54c1e6072db792352f5a77b6defbba6d7f SHA256
4b4781b51dd011ff6202b527a97ddb3c1b7b3cc8122ef42c2b8b1fbe3dd4a17e
Thus, a file would only be considered a duplicate file if all known
hashes and their size collide?
Thanks,
Andy
--
TAI64 timestamp: 4000000058b5ed82
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
