git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 00/18] Signed push

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 19, 2014, 23:29 UTC
Message-ID
<CAPc5daWgPgxPf2gL1e+-nwj7kGGBPDnGpA1syLVSVcqug+pEZw@mail.gmail.com>
In-Reply-To
<CACsJy8AMCR5v1YYfA1AWWWXuYyuvOpsuXUfYzWfxhPYZE9SbcQ@mail.gmail.com>

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 <pclouds@gmail.com> wrote:
Show 20 quoted lines
> On Wed, Aug 20, 2014 at 5:06 AM, Junio C Hamano <gitster@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
Previous: Duy NguyenNext: Nico Williams
Message 45 of 59 in “Signed push”
  1. 00/18 Signed pushJunio C Hamano, Aug 19, 2014
  2. 01/18 receive-pack: do not overallocate command structureJunio C Hamano, Aug 19, 2014
  3. 02/18 receive-pack: parse feature request a bit earlierJunio C Hamano, Aug 19, 2014
  4. Junio C HamanoAug 19, 2014
  5. 03/18 receive-pack: do not reuse old_sha1[] to other thingsJunio C Hamano, Aug 19, 2014
  6. Junio C HamanoAug 19, 2014
  7. 04/18 receive-pack: factor out queueing of commandJunio C Hamano, Aug 19, 2014
  8. 05/18 send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higherJunio C Hamano, Aug 19, 2014
  9. 06/18 send-pack: refactor decision to send update per refJunio C Hamano, Aug 19, 2014
  10. 07/18 send-pack: always send capabilitiesJunio C Hamano, Aug 19, 2014
  11. 08/18 send-pack: factor out capability string generationJunio C Hamano, Aug 19, 2014
  12. 09/18 send-pack: rename "new_refs" to "need_pack_data"Junio C Hamano, Aug 19, 2014
  13. 10/18 send-pack: refactor inspecting and resetting status and sending commandsJunio C Hamano, Aug 19, 2014
  14. 11/18 send-pack: clarify that cmds_sent is a booleanJunio C Hamano, Aug 19, 2014
  15. 12/18 gpg-interface: move parse_gpg_output() to where it should beJunio C Hamano, Aug 19, 2014
  16. 13/18 gpg-interface: move parse_signature() to where it should beJunio C Hamano, Aug 19, 2014
  17. 14/18 pack-protocol doc: typofix for PKT-LINEJunio C Hamano, Aug 19, 2014
  18. 15/18 the beginning of the signed pushJunio C Hamano, Aug 19, 2014
  19. brian m. carlsonAug 20, 2014
  20. Bert WesargAug 20, 2014
  21. Junio C HamanoAug 20, 2014
  22. 16/18 receive-pack: GPG-validate push certificatesJunio C Hamano, Aug 19, 2014
  23. David TurnerAug 20, 2014
  24. Junio C HamanoAug 20, 2014
  25. David TurnerAug 20, 2014
  26. Junio C HamanoAug 20, 2014
  27. David TurnerAug 21, 2014
  28. Junio C HamanoAug 22, 2014
  29. 17/18 send-pack: send feature request on push-cert packetJunio C Hamano, Aug 19, 2014
  30. 18/18 signed push: final protocol updateJunio C Hamano, Aug 19, 2014
  31. Shawn PearceAug 21, 2014
  32. Junio C HamanoAug 21, 2014
  33. Kyle J. McKayAug 22, 2014
  34. Junio C HamanoAug 22, 2014
  35. Shawn PearceAug 22, 2014
  36. Junio C HamanoAug 25, 2014
  37. Shawn PearceAug 26, 2014
  38. Junio C HamanoAug 26, 2014
  39. Junio C HamanoAug 26, 2014
  40. Junio C HamanoSep 4, 2014
  41. Shawn PearceSep 5, 2014
  42. Junio C HamanoAug 22, 2014
  43. David TurnerAug 22, 2014
  44. Duy NguyenAug 19, 2014
  45. Junio C HamanoAug 19, 2014
  46. Nico WilliamsAug 20, 2014
  47. Junio C HamanoAug 20, 2014
  48. Junio C HamanoAug 20, 2014
  49. Junio C HamanoAug 20, 2014
  50. Nico WilliamsAug 20, 2014
  51. Stefan BellerAug 22, 2014
  52. Junio C HamanoAug 22, 2014
  53. Stefan BellerAug 22, 2014
  54. Junio C HamanoAug 22, 2014
  55. Stefan BellerAug 22, 2014
  56. Junio C HamanoAug 22, 2014
  57. Stefan BellerAug 22, 2014
  58. Junio C HamanoAug 25, 2014
  59. Jason PyeronAug 25, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.