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. :)
-Peff
--
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