{"thread":{"id":"63264","subject":"[RFC] Exploring Trust and Provenance in Git: The Open Integrity Project","startedAt":"2025-04-07T09:01:36Z","lastAt":"2025-04-07T09:01:36Z","messageCount":1,"participants":["Christopher Allen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"515748","messageId":"CACrqygB1Pga0w8VzXFGPAsHgYR_YiHKQXRnaaTokxEi2BMwRCg@mail.gmail.com","threadId":"63264","inReplyTo":null,"subject":"[RFC] Exploring Trust and Provenance in Git: The Open Integrity Project","fromName":"Christopher Allen","fromEmail":"christophera@lifewithalacrity.com","sentAt":"2025-04-07T09:00:57Z","receivedAt":"2025-04-07T09:01:36Z","isPatch":false,"sender":{"key":"christophera@lifewithalacrity.com","avatar":null},"body":"Git developers,\n\nToday marks Git's 20th anniversary—a remarkable milestone for a tool\nthat has become foundational to software development worldwide. First,\nthank you. Git’s distributed model, flexibility, and robustness have\nmade it an essential pillar of modern open-source infrastructure.\n\nAs someone focused on digital trust architectures (I'm co-author of\nthe IETF TLS & W3C DID standards), I've been thinking deeply about how\ntrust is conveyed (or not) in Git repositories, especially over\nlong-lived, collaborative projects.\n\nOver the past year, I've been developing a proof-of-concept called the\nOpen Integrity Project, which aims to layer trust and provenance on\ntop of Git, without altering its internals or requiring new binaries.\nIt uses a pattern of inception commits (to cryptographically assert\noriginal control) and trust transition commits (to document changes in\nmaintainership or key rotation).\n\nIt builds directly on Git's existing capabilities, particularly commit\nsigning and SSH-based authentication, but adds some basic structure\nfor reasoning about ownership and accountability over time. All of\nthis is done through shell scripts and Git aliases—no new binarys,\npatches, or daemons.\n\nSome highlights:\n\n• Musings on the concept:\nhttps://www.blockchaincommons.com/musings/open-integrity/\n\n• Problem statement:\nhttps://github.com/OpenIntegrityProject/core/blob/main/docs/Open_Integrity_Problem_Statement.md\n\n• GitHub repo (PoC implementation):\nhttps://github.com/OpenIntegrityProject/core\n\n• Example inception commit:\nhttps://github.com/OpenIntegrityProject/core/commit/69c8659959f1a6aa281bdc1b8653b381e741b3f6\n\nI’m sharing this here not as a proposal for upstream changes, but as\nan open invitation:\n\n• If you think the problem space is worth discussing, I’d welcome any\nfeedback, either on this list or in our new GitHub discussions area:\nhttps://github.com/orgs/OpenIntegrityProject/discussions\n• If you have thoughts on how Git’s existing tooling could better\nsupport trust workflows (even non-normatively), I’d love to hear them.\n    - In particular, I've not made any decisions yet on the best\ntechnique to preserve the git-author SSH signatures when a branch is\nmerged and then the branch is deleted.\n• And if this overlaps with any ongoing or past discussions I should\nbe aware of, I’d appreciate a pointer.\n\nThank you again for maintaining and evolving Git with such care over\nthe years. I hope Open Integrity is seen as a complementary experiment\nin responsible stewardship of our shared infrastructure.\n\nWarm regards,\n\nChristopher Allen\nPrincipal Architect, Blockchain Commons\nhttps://github.com/ChristopherA\nhttps://www.blockchaincommons.com\n"}]}