On Thu, Sep 8, 2011 at 6:57 AM, Junio C Hamano <gitster@xxxxxxxxx> 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 <gitster@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html