You argue that while one function will certainly be broken, it is unlikely that two functions will be broken at the same time.
But logically speaking, the combination of two hash functions is a single hash function. It is just as "a priori" likely that the combination will be broken. Really, all the bickering comes down to setting a price tag: how much does it cost to crack the security features in core arch? Already, just as things stand, the cost is very high relative to other revision control systems. Carefully deployed, arch is unlikely to be the weak link in a chain (and has a lot to help making a strong system). (Casually (and typically, I suspect) deployed, arch unfortunately invites a false sense of security -- but not in any way that can be fixed by adding new hash functions.) Once security features reach the level of "pretty good", further improvements are very difficult to make with confidence. Anyway: while source code *does* deserve better protection than it usually gets, there is also a sharp and not far off upper bound where one wants to say "if i reach the point of having to defend this stuff *that* tediously, then it isn't worth defending at all." You have to fix other stuff, outside of computing, to implement that one. -t _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
