On 10.06.2020 12:35, Junio C Hamano wrote:
The fact that I know almost nothing about "Hyperledger Git Commit Signing Project" (other than the search term returns some hits from the search engines [*1*]) makes me suspect that whatever branch I control is not suitable to contribute to that project, which does not have much to do with the Git project, where this mailing list is its home for. Perhaps ask your mentor first?
Hello Junio, I thought I should jump in here and introduce myself and give Jimit a little help. My name is Dave Huseby and I'm Jimit's mentor. I'm also the Security Maven for the Hyperledger Project. Jimit was selected for our Summer 2020 mentorship project to work on our ongoing efforts to support alternative signing tools in Git. Last summer a series of patches were submitted by Ibrahim and it was not accepted, although we did get some good feedback. The feedback from the Git community was that the refactor of the signing system organized the signing-tool-specific C code into "drivers" for each signing tool instead of being configuration based. See Brian's comment here: https://public-inbox.org/git/20190826231543.GD11334@xxxxxxxxxxxxxxxxxxxxxxxxxx/ Ibrahim's mentorship ended with him sending a new proposal for a config based approach to solve this problem here: https://public-inbox.org/git/R3X1WzWH0sgOh85GuUmXwsTC6CPKysi4TRzN_BPecDVGr__ET2-mitZ2DZA0_bpKkzLRtnTtoomIWxZtL52_1XkihYBVBAuWMpSdwoboixY=@pm.me/T/#u I now think even that proposal is overly complicated. I think the easiest solution is to simply standardize the existing pipe-fork interface as the way GPG talks to all signing tools. For signing tools that have different command line interfaces than GPG, we can create adapter scripts. Tools that want to be compatible can adapt. I'll outline a new proposal in a follow up email. Cheers! Dave
