Hello, it has been pointed out that
- fossil uses weak sha1 hash to link related artifacts to a commit artifact - only commit artifact is signed and not its linked artifacts/partents/whatever -> signing commits is useless One can sign release tarballs but the repo itself is a maze of numerous little bits which are not really traceable with any reliability when you require crypto grade integrity assurances. It has been also pointed out that - pretty much nobody uses commit signing with fossil - There is a chicken and egg problem here. Since there is no way to meaningfully sign commits it's no wonder next to nobody does. - replacing the hash fossil uses for linking artifacts is hard due to code quality/design/compatibility issues However, there is possibility to *add* another hash. If the new hash requires 4x the storage space and 10x the computation time compared to the old hash it is not a real problem to make it 5x and 11x. This allows for backwards compatibility - the sha1 hashes are mandatory, the new hash is optional. - import of sha1 hashed commits is possible - when signing a commit which does not have new hash is requested it either fails or the hash is computed recursively - this also means that when creating a commit its parents need to have the new hash for the commit itself to get it or it has to be calculated recursively - when an old style signature using sha1 hashes is found fossil can warn the user or reject the signature as invalid - during development of new hash feature stable fossil can ignore or strip the new hash when importing commits that have it. For 100% compatibility with old fossils a special sync URL that does not include new hash can be provided or a mirror of the repo with new hash stripped can be used as proxy for old fossil binaries So it's quite possible to have fossil with crypto grade hashes for artifacts with reasonable interoperability with current versions of fossil that use sha1 hashes. I am not particularly interested in implementing this. However, this feature has been requested repeatedly so if this way of implementing it is acceptable somebody might try to do it. Thanks Michal _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
