From: Nguyen Thai Ngoc Duy Date: Wed, 07 Sep 2011 22:21:05 GMT Subject: Re: [PATCH 2/2] push -s: skeleton Message-ID: In-Reply-To: <7vbouw2hqg.fsf@alter.siamese.dyndns.org> On Thu, Sep 8, 2011 at 6:57 AM, Junio C Hamano wrote: > A better alternative could be to sign a "push certificate" (for the lack > of better name) every time you push, asserting that what commits you are > pushing to update which refs. The basic workflow goes like this: > >  1. You push out your work with "git push -s"; > >  2. "git push", as usual, learns where the remote refs are and which refs >    are to be updated with this push. It prepares a text file in memory >    that looks like this using this information: > >        Push-Certificate-Version: 1 >        Pusher: Junio C Hamano 1315427886 -0700 >        Update: e83c51633... d4e58965f... refs/heads/master >        Update: 5a144a288... 7931f38a2... refs/heads/next > >    An actual push certificate records full 40-char object name, but it is >    ellided for brevity here. > >    The user then is asked to sign this push certificate using GPG. The >    result is carried to the other side (i.e. receive-pack). In the >    protocol exchange, this step comes immediately after the sender tells >    what the result of the push should be, before it sends the pack data. > >  3. The receiving end will keep the signed push certificate in core, >    receives the pack data and unpacks (or stores and runs index-pack) >    as usual. > >  4. A new phase to record the push certificate is introduced in the >    codepath after the receiving end runs receive_hook(). It is envisioned >    that this phase: > >    a. parses the updated-to object names, and appends the push >       certificate (still GPG signed) to a note attached to each of the >       objects that will sit at the tip of the refs; I recall Gentoo wanted something like this (recording who pushes what). Pulling Robin in if he has any comments. -- Duy