Jim Hyslop wrote: > Earlier, we discussed mechanisms for allowing loginfo access to the > signature, so that the signatures can be stored in a secure area. > Unfortunately for Beth, without signed deltas this mechanism pretty > much convicts her of introducing the malicious code: Aaron checks in > revision 1.18, its signature is stored in the secure area. Eve > modifies rev 1.18 and changes the signature. At this point, the > tampering could be detected *if* someone compares the signature in the > repository against the signature in the secure area. Let's assume that > nobody does this, though, and the rest of your scenario is followed: > Beth commits her changes, then Eve completes her attack.
Actually, for this defense, you don't need to store signatures externally. Simply storing the commit emails with attached diffs, which many projects already generate, would be sufficient to spot this change in the repository. And the data would not only be stored in a presumably secure archive, it would be duplicated in each developer's inbox. Of course, it might be a little less resource intensive to store and compare signatures... they would presumably be smaller on average than diffs. It's definitely a forensic defense, though. This sort of analysis is time consuming and would likely only be conducted at intervals or after a compromise is detected some other way. Even with signed diffs, it would be hard to defend against this sort of attack on the fly on the client end without downloading the entire RCS archive to the client and letting the client process individual diffs. That would be very resource intensive - as things stand, even the server normally only needs to look at the head revision for a checkout of HEAD. This analysis would require examining every revision back to 1.1 with practically every checkout... and old, expired or revoked keys would mean that eventually even the HEAD could no longer be satisfactorily verified. Not sure how to do better than the forensic defense on this one and the tools are already in place. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6168 f: +1 717.234.3125 <mailto:[EMAIL PROTECTED]> _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
