Re: [OT] USENIX paper on Git

> On Wed, Aug 03, 2016 at 01:45:00PM -0400, Santiago Torres wrote:
> 
> > >   - if there is a chain of signatures, the attacker must follow the
> > >     chain, but they can always withhold links from the end. So imagine a
> > >     repository has held a sequence of signed states (A, B, C), that B
> > >     has a bug, C has the fix, and I am at A. An attacker can serve me B
> > >     and I cannot know without out-of-band information that it is not the
> > >     correct tip (because until C was created, it _was_ the correct tip).
> > 
> > I think we address this by using the "nonce bag". We basically force the
> > server to fork the user's history if it withholds changes from on group
> > to the other. By doing so, the user's nonce can't be added to any other
> > history. I don't think this is noticeable from start though.
> 
> OK, I think that is in the details I glossed over. ;)
> 
> If you are effectively preventing the server from showing different
> states to different people, then at least that lets the "main"
> developers notice problems (because at least one of them already saw "C"
> because they wrote it).

> 
> > > I think git in general is quite weak in automatic tooling for
> > > verifications. There are room for signatures in the data format and
> > > tools for checking that the bytes haven't been touched, but there's
> > > almost nothing to tell you that signatures make any sense, tools for
> > > handling trust, etc.
> > 
> > Yes, from our previous interactions, it seems that git's philosophy
> > focuses on providing the right information to users/tools and let those
> > tools make the call of whether something is fishy. I don't think this is
> > necessarily bad.
> 
> I think it's half philosophy (git strives for flexibility, and so aims
> to provide low-level tooling that you can build on), and half that
> nobody has bothered to implement a sane set of automatic checks.
> 
> There's definitely some low-hanging fruit there. I think we've discussed
> things like checking that verifying refs/tags/v1.0.0 actually gets you a
> tag that says "v1.0.0" in it. But I'd love to see a framework either
> built into or on top of git that would implement sensible policies, and
> make out-of-the-box verification easy to do. Then people might actually
> use it. :)

> 
> > > I think your solution also had some mechanisms for adding trusted keys
> > > as part of the hash chain. I'm not convinced that's something that
> > > should be part of git's solution in particular, and not an out-of-band
> > > thing handled as part of the PKI. Because it's really a group key
> > > management problem, and applies to anything you might sign.
> > 
> > I see. What about, for example, having an official "overlay" on git for
> > signing and verification of a repository? (e.g., similar to what
> > monotone does). I see that other VCS's have a plugin mechanism, and they
> > host official plugins.
> 
> In general, if something is more general than git, I'd like to see a
> general tool address it, and then add support to git to make use of the
> tool.
> 
> For group key management, I specifically was wondering if you could do
> something like:
> 
>   - start with some seed GPG keys for the project
> 
>   - existing keys can sign or revoke certificates to add or remove other
>     keys to/from the project; you could even require a threshold of
>     signatures, etc.
> 
>   - those keys could be used for signing git pushes, but also for other
>     things, like signing tarballs, used as encryption keys for sending
>     for-developers-eyes-only security reports, etc
> 
>     You'd want a tool that asks not just "is this signed" but "is this
>     signed _by a key that is valid for this project_".

> 
> And then git support would just consist of feeding signatures to
> "gpg-group --project=..." instead of "gpg". Management of the group
> would be out-of-band from git, which is in some ways good and in some
> ways bad.

> 
> I think a naive implementation would be pretty easy, but I've glossed
> over all of the chaining properties we've discussed. So whatever
> mechanism you use to receive updates to the key-group would have all the
> same problems (e.g., withholding revocations of compromised keys). It's
> still orders of magnitude ahead of what's currently happening
> day-to-day. :)