On Tue, Sep 13, 2011 at 17:31, Sam Vilain <sam@xxxxxxxxxx> wrote: > On 9/13/11 9:45 AM, Junio C Hamano wrote: >> >> * "git push" prepares a "push certificate" (it is meant to certify "these >> are the commits I place at the tips of these refs"), which is a human >> and machine readable text file in core, that may look like this: >> >> Push-Certificate-Version: 0 >> Pusher: Junio C Hamano<gitster@xxxxxxxxx> >> Update: 3793ac56b4c4f9bf0bddc306a0cec21118683728 refs/heads/master >> Update: 12850bec0c24b529c9a9df6a95ad4bdeea39373e refs/heads/next > > If the push certificate also has the previous commit IDs for the changed > refs, then you actually have an audit log. Otherwise, it does not certify > the commit range they pushed. Is that necessary? The range they are certifying is that commit, and its entire ancestry. If the pusher doesn't trust his ancestry, why is he working with it? Similar to an annotated tag. I make a signed annotated tag, I am asserting that revision and its ancestry is something I like as far as a project build goes. You don't need the old revision to realize I like this commit. If you want to get into the game of, maybe I push a branch, then rewind it, and push something differently, and you want to be able to verify that the 2nd push is the "right thing" and the 1st push should be ignored, you can already see that by looking at the timestamp of the push certificates (/me assumes there is a timestamp in there). If you can create multiple signed pushes by yourself, using your GPG key, within the same second, and they are conflicting... well, stop using automated tools to create conflicting assertions as yourself. If you are creating signed pushes on systems with clock skew, learn how to configure NTP date. > This is an important prerequisite for a fully distributed, peer to peer git. > For this case it would also need something to distinguish which repository > is to be updated; such as a canonical repository URL (or list of URLs), or > just a short project name. A P2P protocol can then know projects as (KEYID, > projectname). Why do we need a project name? Most Git based projects are uniquely identified by the set of root commits they have. Why? Because most root commits were created by different people, at different times, with different commit messages, and different initial trees, resulting in a unique commit SHA-1 for that root commit. Projects with more than one root commit also disambiguate themselves from other projects that maybe contain one of those roots (e.g. git.git vs. gitk). If you wanted to identify a project on a P2P network, I think you would want to do it based off the root commits, not some random name people came up with and might try to publish forgeries under. -- Shawn. -- 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