Re: [PATCH 00/18] Signed push

On 20.08.2014 00:06, Junio C Hamano wrote:

While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch.  My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.

The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.

This series introduces a cryptographic assurance for ref updates
done by "git push" by introducing a mechanism that allows you to
sign a "push certificate" (for the lack of better name) every time
you push.  Think of it as working on an axis orthogonal to the
traditional "signed tags".

What kind of additional benefit do we gain? (i.e. why?)
The described problem, the lacking auditability of what's pushed
at which time, could be worked around like this:

Whenever you do a push, you just tag the latest commit in that branch.
So there would be tags like:
	master_2014_08_21
	master_2014_08_22
	...
	maint_2014_08_13
	maint_2014_08_21
and so on. Whenever there is no tag at the tip of the branch, we'd
know there is something wrong.
	
My guess would be usability as tagging so many branches is cumbersome
for a maintainer?

Looking at my made-up workaround again:
That would produce lots of tags. So I could imagine there would also be
lots of push certs. The number of push certs would
roughly scale linear to time passed. May this result in slowness over time?

Does this patch series mean, we'd get another object type (additional to
blobs, commits, tags, trees)?

I did not read the code yet, it's just first thoughts,
so this weigh this input lightly.

Stefan