Re: [PATCH 00/18] Signed push

I don't think anybody can come up with a good auditing and recording
scheme without sufficient experience. Because I want to avoid whatever
random scheme we happen to implement first in git-core, even if it is
way suboptimal, ends up as the de-facto standard, I deliberately stayed
away from adding one of my own in this initial series, whose purpose is
to lay a groundwork for server operators can build on.  For the same
reason, I tried to avoid anything that defines and forces a particular policy
(e.g. does a server that accepts push certificate accept an unsigned
push to some of its refs? Is it OK if the GPG key is slightly stale? etc.).

"git notes" may or may not be a good vehicle to store them. This series
deliberately refrains from making that judgement. I'd rather leave these
operational issues to folks who work on systems like Gitolite and Gerrit.


On Tue, Aug 19, 2014 at 4:07 PM, Duy Nguyen [off-list ref] wrote:

On Wed, Aug 20, 2014 at 5:06 AM, Junio C Hamano [off-list ref] wrote:

quoted

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.

I only had a quick read of a few important patches and may miss
something. But all this audit recording is left to the hook, right? I
suppose git-notes could be used to store the push cert. blob, or the
server could make a signed tag to record this info in the ref.. or do
you intend any other way to record these blobs?
--
Duy