Haven't noticed your discuss...Thank you Ben...
It is evidence that Fossil was not correctly planned in the beginning.I would
never forget to put some option, such as different [hash, security] algorithm
possibilities.
(*sighs*)
No really, I am not astonished ...
Best Regards
K.
De : Ben Summers <b...@fluffy.co.uk>
À : fossil-dev@mailinglists.sqlite.org
Envoyé le : Lundi 27 février 2017 20h56
Objet : Re: [fossil-dev] Proposed roadmap for Fossil 2.0
> On 27 Feb 2017, at 18:59, Richard Hipp <d...@sqlite.org> wrote:
>
> Maybe I'm making this too hard....
>
> Here is plan B:
>
> Continue to use SHA1 hashes as the "names" of artifacts. But also
> store a second hash for each artifact as a double-check against
> collisions. This would allow hash collisions to be detected
> immediately, and the colliding artifacts to be automatically shunned,
> or otherwise disabled, rendering them harmless.
Would the secondary hash be included in the manifest, breaking backwards
compatibility?
If it isn't, then your PGP signed manifests don't have the full security
properties you'd hope for.
Ben
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
