On Wed, Mar 7, 2012 at 19:37, Themba Fletcher <themba.fletc...@gmail.com> wrote: > > If I understand correctly, what happened at github was that someone exploited > a misconfiguration in the rails framework to insert his own public key as > trusted with respect to several repositories. > > The "fossil verify" command you proposed above would have had little to no > benefit in detecting or sorting out that particular mess. > > It seems to me cleaning up any specific intrusion is going to be a special > case and is probably going to require a trip into the depths of SQLite. I > don't really see any benefit to having built-in commands to try to detect a > subset of potential intrusions -- that just introduces a larger code base. > And every added line of code is a potential security hole in and of itself. > > Themba >
I think you are entirely missing my point! It is not about intrusion detection but about *code integrity*. Your box can be compromised via different attack vectors not even related to your SCM. But distributed SCMs have an advantage that when you try to sync a malicious code coming from a compromised remote server with your pristine local version you have a fighting chance to detect malicious code manipulations. For that very reason gpg --clearsign signatures have been already implemented in fossil specifically to verify the identity of the commiters. As it stands now, signing a commit in fossil is very easy but signature verification has not been implemented. As a result, a user is forced to implement signature verify out of tree. It is error-prone, inconvenient and time consuming. Most importantly, due to extra work required users simply will not use these signatures. --Leo-- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
