Re: [RFC PATCH 0/2] Add named reference to latest push cert

From: Shikher Verma <root@shikherverma.com>
Date: Sep 7, 2017, 09:11 UTC
Message-ID: <20170907091133.zygswf3f6z2bedfo@weakknees.security.iitk.ac.in>
In-Reply-To: <CAGZ79kbxDh11KxrKCk_VjmN06kzp7x4iVO6XTV=a-qBmm39K5A@mail.gmail.com>

On Wed, Sep 06, 2017 at 02:31:49PM -0700, Stefan Beller wrote:

Show 22 quoted lines

> On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma <root@shikherverma.com> wrote: 
> > Currently, git only stores push certificates if there is a receive hook 
> > present. This may violate the principle of least surprise (e.g., I 
> > pushed with --signed, and I don't see anything in upstream). 
> > Additionally, push certificates could be more versatile if they are not 
> > tightly bound to git hooks. Finally, it would be useful to verify the 
> > signed pushes at later points of time with ease. 
> > 
> > A named ref is added for ease of access/tooling around push 
> > certificates. If the last push was signed, ref/PUSH_CERT stores the 
> > ref of the latest push cert otherwise it is empty. 
> > 
> > Sending patches as RFC since the documentation would have to be 
> > updated and git gc might have to be patched to not garbage collect 
> > the latest push certificate. 
> > 
> > This patch applies on master (3ec7d702a) 
> 
> What are performance implications for busy repositories at busy hosts? 
> (think kernel.org / github) They may want to disable this new feature 
> for performance reasons or because they don't want to clutter the 
> object store. So at least a config option to turn it off would be useful.

Any typical git push would write several objects to disk, this patch would only add one more object per push so I think the performance penalty is not that high. But I agree that we can have a config to turn it off.

Show 5 quoted lines

> On the ref to store the push certs: 
> (a) Currently the ref points at the blob, I wonder if we'd rather want to 
> point at a commit? (Then we can build up a history of 
> push certs, instead of relying on the reflog to show all 
> push certs. Also the gc issue might be easier to solve using this)

I am not sure how that would work. The ref points at the blob of push certificate. Since each push can update multiple refs, each push certificate can point to mutiple commits (tip of the updated refs). Also if the named ref points at the commit then how will we get the corresponding push certificate?

I did think about keeping a history of push certificates but the problem is new pushes can delete refs and commits which were pointed to by previous push certificates. This makes it really difficult to decide which push certificates to keep and which to gc. Also this history would be different for different clones of the same repo. Since push certificate are only meta data of the git workflow I think its best to just keep the latest push certificate and gc the old ones. People can use the recieve hook if they want to do advance things like logging a history of push certificates. I think git should provide a builtin solution for the simple case.

Another motivation to decouple push certificates from hooks was that later we could store a map of refs to the latest push cert which updated the ref. And serve the corresponding push cert whenever someone does `git pull --signed important-ref`. Effectively removing trust from the server by preventing tampering with refs. This could really help the Github generation developers like me.

Show 11 quoted lines

> (b) When going with (a), we might want to change the name. Most 
> refs are 3 directories deep: 
> refs/heads/<branch name> 
> refs/pr/<pull request nr> # at github IIUC 
> refs/changes/<id> # Gerrit 
> refs/meta/config # Gerrit to e.g. configure ACLs of the repo 
> "refs" indicates it is a ref, whereas the second part can be seen 
> as a "namespace". Currently Git only uses the "heads" and "tags" 
> namespace, "meta" is used by more than just Gerrit, so maybe it is 
> not wise to use "refs/meta/push_cert", but go with refs/gitmeta/pushcert 
> instead?