Re: [PATCH v3 0/4] Signed push

Ted Ts'o [off-list ref] writes:

I guess I'm confused about what the problem is with this?

Yeah, I have to agree.

If I do something like this:

git tag -s -m for_linus-20110910 for_linus-20110910
git push github
git push --tags github

I'm "forcing" the sending side to keep the signed tag, no?

No, you are not forced to _keep_ it. After pushing you can delete it
locally.

The reason your "tag" example is fundamentally different is because a tag
like for_linus_20110910 is a one-shot thing and you can choose to remove
it from your local namespace once you are done pushing. It does not affect
your ability to make another signed tag for_linus_20110911 before pushing
tomorrow.

The point in this round of "signed push" topic is to allow people not tag
every time before they push, making it easier to sign their pushes to
encourage it, so that other people can have a way to verify the commits
near the tip of branches that are not still tagged in between releases.
Instead of contaminating refs/tags/ namespace with daily tags, the idea
was to keep a single "signed-push" notes tree on the receiving end (which
is the distribution point for consumers) that contain the signed record of
pushes.

The original "signed push" (what I called v2) design was for the sender to
prepare the record that goes into the notes tree, but record the notes
tree at the receiving end (this does _not_ prevent the sender from
fetching it back to keep his local copy, but the sender is _not_ required
to do so). It needs updates to both sending and receiving end.

An alternative idea (which I implemented as v3) that came up during the
discussion was to instead have the sender add this record locally to the
signed-push notes tree, and push it out along with the branches. For this
push not to lose _existing_ records of pushes at the receiving end, the
pusher is required to have an up-to-date copy of signed-push notes tree,
and add the new record to it before pushing it out. One upside is that
this does not need updates to receiving end.

I do not know if you read the message Sverre was responding to, but the
"you have to have local copy" requirement has another and potentially
bigger downside (which Sverre did not quote) for people who push out to
multiple places.

Perhaps we shouldn't worry about tag namespace contamination to make
things easier and simpler and stop using notes tree?

Heya,

On Sun, Sep 11, 2011 at 03:42, Junio C Hamano [off-list ref] wrote:

I do not know if you read the message Sverre was responding to, but the
"you have to have local copy" requirement has another and potentially
bigger downside (which Sverre did not quote) for people who push out to
multiple places.

That's not what I meant though. I was responding to your "than you can
later _inspect_ the certificates from multiple locations". I was
indicating that it would be easier to do such inspection if you can
optionally fetch the notes from different remotes to different
locations in the refs/remotes namespace.

-- 
Cheers,

Sverre Rabbelier

On Sat, Sep 10, 2011 at 06:42:58PM -0700, Junio C Hamano wrote:

Perhaps we shouldn't worry about tag namespace contamination to make
things easier and simpler and stop using notes tree?

With the appropriate conventions, such as using a tag name such as
signed-<email>-<timestamp>" we can at least avoid name conflicts, at
least for all practical purposes.

There is the additional problem that "git tag -l" gets painful.  At
least for me, though, it's already mostly useless:

   % git tag -l | grep ^v[23] | wc -l
   858

I can work around this with git aliases that filter out certain
prefixes that I normally don't care about, but maybe that's something
that should be directly supported in git-tag with some git-config
parameters.

The final issue that I'd worry about with using tags is performance.
If we have hundreds of thousands or millions of tags of the form
signed-<email>-<timestamp>, is this going to be a problem?  This does
seem like something that could be worked around --- in the worst case
there could just be a locally maintained reverse index from git commit
id's to tag names.  (Although as I recall Linus objected to having
something like this for time skews, so maybe he'd object to this too.)

	       	    	     	       	     	  - Ted