If you guys are going to get into this more deeply, you should probably also consider revocation issues. That is, what happens when it is discovered that a contributor's private key has been compromised?
The discovery date of the compromise is obviously >= the compromise date. As such, some set of prior check-ins were signed while the key was compromised. So you need to figure out how to deal with those check-ins. Do you display them differently, or shun them, or so on. On the other hand, you're not going to address every possible threat model with your system. For example, you are not going to prevent "rubber-hose attacks" on contributors. If you haven't already, you should probably enumerate exactly what threat models you care about. Only then can you reason clearly about whether you are protecting against such threats. I'd imagine, since one of fossil's primary purposes seems to revolve around preserving a clear and unimpeachable chain of intellectual property ownership, that you'll want to come up with specific potential attacks on that chain and figure out if you are preventing them. See here for an example of a well-defined model, arranged as a tree: http://tldp.org/HOWTO/Disk-Encryption-HOWTO/introduction.html#ThreatModel Eric
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
