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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
