On Wed, Aug 28, 2013 at 6:26 PM, John Long <[email protected]> wrote:
> ...that problem is solved by using SHA1. The other issue, which is > specific to > specific situations, is whether the hash alone is sufficient to protect > against malicious alteration of the repository. In the first case it would > seem SHA1 is still acceptable although it's increasingly becoming apparent > SHA1's days as an ideal hash have come and gone. In principal it would be possible to update fossil at some point to use a different hashing mechanism, and export a sha1-based repo to a new one. They wouldn't be compatible after that, but nothing in the overall design really prohibits it. There is arguably a micro-window of opportunity for corruption during conversion unless the conversion is tested both ways, but that would be manageable. There are "cosmetics", such the hard-coded word "SHA1" everywhere (and related length/syntax constraints), but the underlying SCM model is independent of the hashing algorithm used (or the storage used to store the blobs, for that matter). A simple CRC32 would "work just as well" for most purposes (though of course nobody's suggesting that). That said, while the change is simplein the abstract, SHA1 is pretty well-entrenched into the source code, so it would be an invasive port/change. In the second case I think > it's possible to prevent and/or detect of attacks on the repo with very > minimal workflow adjustments I outlined earlier, or something similar to > that, without any changes to fossil at all. > i'm still waiting for someone who has a head for security-related coding to volunteer for that ;). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
