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
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
Proposed change:
1. A new control artifact ("Upgrade Security Hash Identifier");
a. U cards which identify an existing SHA1 (or other hash)
and the same hash in a different hasing algorith, e.g.:
U SHA1 3301ac54c1e6072db792352f5a7
Thus said Richard Hipp on Mon, 27 Feb 2017 21:50:43 -0500:
> (9) There are no changes to the file formats, other than relaxing the
> size constraint on artifact hashes - allowing hash to be greater than
> or equal to 40 characters rather than requiring it to be exactly 40
> characters.
The F
My latest thoughts on Fossil-2.0 are in the attachment. (I think I
have successfully modified the mailing list settings to allow text
attachments through - this message will serve as a test case.)
--
D. Richard Hipp
d...@sqlite.org
The latest thinking on the Fossil-2.0 upgrade.
(1) Keep the BLOB
On 02/27/2017 11:43 AM, Warren Young wrote:
On Feb 26, 2017, at 1:45 PM, Richard Hipp wrote:
(9) Can a Fossil 1.x client push/pull/clone from a Fossil 2.0 server,
assuming the repository uses SHA1 has it preferred hash algorithm?
This is desirable, but I am willing to sacrifice this capability
On 2/27/17, Warren Young wrote:
>
> There are many fewer hash sizes than hash algorithms:
>
Having a large number of available hash functions merely complicates
the interface by giving the user yet another decision to make. The
intent is to keep the number of available hash functions to a minimu
On Feb 26, 2017, at 1:45 PM, Richard Hipp wrote:
>
> initial implementation will support SHA1 and SHA3-228
224.
> Other hash algorithms may be supported
> in future releases as long as each hash algorithm has a unique hash
> length
That seems brittle. There are many fewer hash sizes than hash
On 26/02/17, Richard Hipp wrote:
> My goal is to keep changes to a minimum. The only change is to add
> support for multiple hash algorithms.
If neither the roy-export or jan-export branches are planned to be
merged to trunk for 2.0, can we get consensus on how the tag comment
should actually be
