On Tue, Jan 12, 2016 at 10:21 AM, Santiago Torres <santiago@xxxxxxx> wrote: > Hello Everyone, > > Thanks for the feedback regarding our attack scenario; it certainly shed some > light in what is the current state of git's metadata protection. We were > pleasantly surprised that attacks of this nature were considered, yet we think > we can improve on the current mechanisms. > > We have been designing an extension that addresses this attack scenario (and > other similar attacks). Although originally it is not based on push > certificates, we feel that it works similar to them. The principal advantages > over push certificates are: > > 1) It doesn't require (although it could support it) a side channel. We store similar > information about branch status (push status) on the repository itself. > > 2) It is backwards compatible, as it doesn't modify the existing metadata > format. > > 3) Following Ted's email, it could be easily integrated in any git workflow. > Although some workflows might be benefitted more than others, it doesn't > get in the way of any existing workflow that we know of. > > 4) It covers a broader attack suurface (e.g., our malicious-merge scenario). > > To keep things simple (we can elaborate in further emails), our solution > basically works by keeping track of pushes by developers in an append only > file, so that, everytime a branch is pushed, the deloper signs his version of > the log and his "push entry" (similar to a push certificate). Right now, we > push this log to a separate branch called BSL (for Branch State Log), but > ideallly this could be part of the git metadata. Recently in another context (an alternative refs backend) there was a proposal by Shawn to keep the .git directory versioned by git itself, i.e. having only loose refs in .git/refs and then there is a repository tracking .git/refs as a directory structure. Using that idea of a refs back end, combined with signed tags in the refs repository would give you signed version of the log of possible push entries. > > Upon pulling/fetching, this push certificate chain (BSL) is also fetched > and used to verify whether all branches are pointing to a sensible > location (i.e., the location reported by the last user who > pushed/merged).This ensures that a malicious server can't change the > location to which branches point to. This is what push certs ought to solve already? AFAIU the main issue with untrustworthy servers is holding back the latest push. As Ted said, usually there is problem in the code and then the fix is pushed, but the malicious server would not advertise the update, but deliver the old unfixed version. This attack cannot be mitigated by having either a side channel (email announcements) or time outs (state is only good if push cert is newer than <amount of time>, but this may require empty pushes) > > Furthermore, upon fetching, users with write access also push an entry > indicating that they fetched the BSL. This avoids cases in which a malicious > attacker keeps older versions of the BSL and withhold changes to other users. This would make it a "be malicious to all or none" thing? So the attacker cannot attack a single target IIUC. I have a bad feeling about repository modifications upon fetching as software distribution is a highly asymmetric workflow (number of fetches is many orders of magnitudes larger than pushes), which may not scale well? (How would you serialize parallel fetches into the BSL?) Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html