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 <pclo...@gmail.com> wrote: > On Wed, Aug 20, 2014 at 5:06 AM, Junio C Hamano <gits...@pobox.com> 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. > > 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 -- 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
