DID:GIT: Where is it at?

DID:GIT: Where Is It At?

Thursday 12H

Convener: David Huseby

Notes-taker(s): David Huseby

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

• After IIW 28, a group formed around writing the did:git: method spec. 
  • The latest version of the spec can be found here: https://github.com/dhuseby/did-git-spec

• Hyperledger hosted a summer internship project focused on modifying Git to support DID signing.
  • The project page is here: https://wiki.hyperledger.org/display/INTERN/Git+signing+with+DIDs
  • The intern selected to work on the project is Ibrahim El Rhezzali ibrahim.elrhezzali@gmail.com
  • Ibrahim successfully fixed and completed the patched I had started a year prior. He submitted them to the Git community here:
    • [RFC PATCH 0/5] New signing interface API with pluggable drivers https://public-inbox.org/git/Z2XOTcGuVovMKhcdrrO08KWI2I7L9s0CyFITvvj3jkmGTQPB6FkCiyOtTm6GdYWbnf25dsPD8M08kDCuD37EE1B-sxHQ3se9Kn1zVBrCPZw=@pm.me/T/#u
    • [RFC PATCH 1/5] Signing API: Added documentation for the new signing interface https://public-inbox.org/git/N31G34oKnfr3MVifk42-Kt3YtM_3fHuCp3V1cpGOK5f1jn1vbg1TaSCy9ukI-YD8qRfu4xMcHcPc78xFE0MSwJQWNrSvuQuer9wSNugNRLg=@pm.me/T/#u
    • [RFC PATCH 2/5] Signing API: Added new signing interface API https://public-inbox.org/git/8AMhjK19PJ35u3LCR57IvtAzOBN5bKK2vUn0Ns-4mmZzK9U14W5CGW5R8aITNXBm78J4Z7nd09RTVKW2pGaB4PnF7p2PireF_vzRST8DngE=@pm.me/T/#u
    • [RFC PATCH 3/5] Signing API: Migrated to the new signing interface API https://public-inbox.org/git/0oTOrSdJdIaEfs3NVkfRmLxjYRvUPkucwwaXPuhCjS2QL3ztRJLfIlBkcpjSRiZQaY70SKSkg8_w20rxnuD4Vu3IbRcGOZM-fht8G7ySEHk=@pm.me/T/#u
    • [RFC PATCH 4/5] Signing API: Removed old gpg interface and gpg mentions in code https://public-inbox.org/git/T4zS1hogOjySpdv7lDjVaZV83KKSeK9fx8m33SIo-e_BH4RtKcm67btmGzTPeflbRnQr7mWjTpObB0hCkX8VkGZElkQbLEgbrETg6Aq4nUg=@pm.me/T/#u
    • [RFC PATCH 5/5] Signing API: Duplicated signing tests using new config aliases https://public-inbox.org/git/74R10RrvOffzj20d_Owd_1WFMh1bWq8mIhEEBSzbhkHfbvW5BLHZj-L-AgHYnpqkxgZdCfW5b72GoIvKHucQz7tdiGZEzietp0IKpU1_wuI=@pm.me/T/#u
  • The Git maintainers rejected the patches saying that they didn't want to have to add a C driver for every new signing tool Git supports in the future. They requested that we look into doing a configuration based solution.
  • Ibrahim and I collaborated on a new design that was more in line with what the maintainers requested. The following is an email Ibrahim sent to one of the Git maintainers to discuss how to move forward:
  • Hello Brian,
  • My name is Ibrahim, i submitted previously the proposal for the new 'generic signing interface' in the git mailing list.
  • I'd like to thank you very much for your feedback about adopting a "config based approach".
  • We've been thinking the last few weeks how to go about it so the C code in git isn't aware of any external signing tools. We've come-up with a few ideas:
  • - At first we thought about keeping a generic driver in the C code that handles operations just like the current code (Pipe / Stdin / Stdout) and all other variables would be handled by the user config (like the command to run the signing tool, its parameters and options, Regex to parse existing signatures, etc.)
  • - Then we realized that this option would be very difficult for the user on one hand and on the other hand we're making the assumption that all signing tools would handle the signing process same as GPG (exit codes, status, output, etc.). So we found another idea which is to use Assuan, an IPC protocol developed by the GPG team to use their signing tools in server mode: This would have been a clean way of coding the interface but it had it's drawbacks: Is it worth adding a new C library in git just for the signing operations ? and again only tools that handle Assuan would work, namely as of now GPGSM handles it and GPG not fully, which is not so great.
  • - After much thought, we landed on a middle ground solution and we think at the moment it may be the best way to go: Just like you proposed, make the signing interface in C not aware of any signing tool and completely standardized. On top of that the user would have tool specific configuration that contains information like signing key and identity. Then we use simple bash scripts to drive the tool correctly. We would have for example a "git-signing-gpg.sh and git-signing-gpgsm.sh" and so on for the other tools.
  • Adding a new tool would be as simple as adding a bash script and the necessary config to make it work,without touching the C code. Since git already bundles many bash scripts for different purposes, we didn't think it would be a problem.
  • I really want to find the best way to do this properly and in a clean way, that's why i contacted you directly before submitting the proposal to the mailing list. What do you think ?
  • The response has been great and Ibrahim is continuing to work on this version of the abstraction.

• At the same time as the internship, I also started a conversation with Konstantin Ryabitsev about inline identity management in Git repos and why we think git:did: is necessary.

• Konstantin responded with a really inspired blog post: https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains
  • Konstantin's concern is about preserving the nature of the email+git lifestyle of kernel/git developers that he serves.
  • I think it is important to note that Konstantin and I agree that inline identity management is important but we disagree on how we get there and somewhat on how it should be implemented.