On Wed, Aug 03, 2016 at 01:58:54PM -0400, Jeff King wrote: > 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).
yeah, that was one of our assumptions. I think it's unrealistic to think that people do not coordinate over mailing lists or other means. > > > > 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. :) Yeah, that's one of the long-term goals with my PhD, but it's still on the early stages, and I don't have much done yet in that field. I can of course share this around once it's more mature if that's ok with people in here :) > > > > 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_". Yep and also "is this signed thing the thing I should be looking at?" > > 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. yep, what I like from in-band solution is that it is easy to piggyback on existing git mechanisms (e.g., git ref backend). > > 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. :) yeah, a naive implementation may be easy, but there are little details to consider when trying to get something more robust. I don't see why sketching something would be a bad idea though. Thanks all for all your feedback! I'll keep this mail archived around to revisit it in the future; all of this seems really interesting/helpful. -Santiago. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
