From: Sam Vilain <sam@vilain.net>
To: Shawn Pearce <spearce@spearce.org>
Cc: Junio C Hamano <gitster@pobox.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
git@vger.kernel.org
Subject: Re: [Survey] Signed push
Date: Tue, 13 Sep 2011 18:03:14 -0700 [thread overview]
Message-ID: <4E6FFD52.7050907@vilain.net> (raw)
In-Reply-To: <CAJo=hJt-n0Xn85g7-7eEgxZhsBu8wd843dvvbaJgdYSx3t4Xug@mail.gmail.com>
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
next prev parent reply other threads:[~2011-09-14 1:04 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-13 16:45 [Survey] Signed push Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 0/2] State commit name explicitly in request-pull messages Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 1/2] fetch: allow asking for an explicit commit object by name Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 2/2] request-pull: state exact commit object name Junio C Hamano
2011-09-13 23:26 ` [Survey] Signed push Guenter Roeck
2011-09-13 23:50 ` Junio C Hamano
2011-09-14 0:02 ` Junio C Hamano
2011-09-14 0:31 ` Sam Vilain
2011-09-14 0:39 ` Shawn Pearce
2011-09-14 1:03 ` Sam Vilain [this message]
[not found] ` <CA+55aFxAQTR3sT7gekAD4qih8J+z-qwri7ZmNCPUd811xgci6w@mail.gmail.com>
2011-09-14 7:06 ` Fwd: " Linus Torvalds
2011-09-14 10:45 ` Michael Haggerty
2011-09-14 11:03 ` Matthieu Moy
2011-09-14 11:46 ` Nguyen Thai Ngoc Duy
2011-09-14 12:28 ` Johan Herland
2011-09-14 12:56 ` Ted Ts'o
2011-09-14 15:27 ` Linus Torvalds
2011-09-14 15:42 ` Matthieu Moy
2011-09-14 16:14 ` Johan Herland
2011-09-14 22:51 ` Philip Oakley
2011-09-14 23:30 ` Linus Torvalds
2011-09-14 23:44 ` Junio C Hamano
2011-09-14 15:25 ` Linus Torvalds
2011-09-14 17:52 ` Junio C Hamano
2011-09-14 18:36 ` Linus Torvalds
2011-09-14 17:49 ` Junio C Hamano
2011-09-14 20:52 ` Sam Vilain
2011-09-16 19:04 ` [PATCH v3] request-pull: state what commit to expect Junio C Hamano
2011-09-20 23:01 ` Junio C Hamano
2011-09-20 23:02 ` [PATCH 2/3] branch: teach --edit-description option Junio C Hamano
2011-09-21 0:15 ` Andrew Ardill
2011-09-21 2:44 ` Junio C Hamano
2011-09-20 23:03 ` [PATCH] request-pull: use the branch description Junio C Hamano
2011-09-22 22:09 ` [PATCH 0/6] A handful of "branch description" patches Junio C Hamano
2011-09-22 22:09 ` [PATCH 1/6] branch: add read_branch_desc() helper function Junio C Hamano
2011-09-22 22:09 ` [PATCH 2/6] format-patch: use branch description in cover letter Junio C Hamano
2011-09-22 22:09 ` [PATCH 3/6] branch: teach --edit-description option Junio C Hamano
2011-09-23 9:00 ` Michael J Gruber
2011-09-23 9:47 ` Nguyen Thai Ngoc Duy
2011-09-23 19:04 ` Junio C Hamano
2011-09-25 5:21 ` Nguyen Thai Ngoc Duy
2011-09-22 22:09 ` [PATCH 4/6] request-pull: modernize style Junio C Hamano
2011-09-22 22:09 ` [PATCH 5/6] request-pull: state what commit to expect Junio C Hamano
2011-09-22 22:09 ` [PATCH 6/6] request-pull: use the branch description Junio C Hamano
2011-09-23 8:56 ` [PATCH 0/6] A handful of "branch description" patches Michael J Gruber
2011-09-23 20:18 ` Jeff King
2011-09-23 20:52 ` Junio C Hamano
2011-09-23 20:53 ` Jeff King
2011-09-24 14:42 ` Michael J Gruber
2011-09-27 21:58 ` Jeff King
2011-09-28 4:23 ` Annotated branch ≈ annotated tag? Michael Haggerty
2011-09-28 7:12 ` Andrew Ardill
2011-09-28 8:04 ` Michael Haggerty
2011-09-28 8:58 ` Branch annotations [Re: Annotated branch ≈ annotated tag?] Michael J Gruber
2011-09-29 6:44 ` Annotated branch ≈ annotated tag? Jeff King
2011-09-14 11:58 ` [Survey] Signed push Nguyen Thai Ngoc Duy
2011-09-14 21:05 ` Jonathan Nieder
2011-09-14 22:42 ` Nguyen Thai Ngoc Duy
2011-09-15 17:50 ` Jeff King
2011-09-14 19:35 ` Andy Lutomirski
2011-09-14 20:40 ` Junio C Hamano
2011-09-14 20:49 ` Andrew Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E6FFD52.7050907@vilain.net \
--to=sam@vilain.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=spearce@spearce.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).