Re: [Survey] Signed push

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/13/11 5:39 PM, Shawn Pearce wrote:
>  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.

Perhaps because they didn't notice what happened. Someone else pushed to the server without a signed push somehow, and then they pulled, pushed ... and now as far as you know, those commits are certified like any other. Having this extra information, not much information, will help figure out what happens in this sort of situation.

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.


Yes, this is true, but it also makes it a lot harder to figure out if two projects are from the same real project, or whether they just shared some history. In general, git repositories are partitioned by URL or project, and so this makes a soft case for a distributed system to partition itself by URL or project also.

Sam
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]