Good Afternoon,
I am Jimit Bhalavat, and I am a Junior at Colorado State University and my major is Computer Science. Recently, I accepted to work on Hyperledger Git Commit Signing Project through The Linux Foundation and my mentor is David Huseby. I am writing to you in order to ask you if you are the maintainer for the GPG Signing Project?
Which branches are for refactoring/new features in the GPG Commit Signing Project?
Thank you so much. Have a great rest of your day.
Best, Jimit Bhalavat.
Junio C HamanoRe: GPG Commit Signing Project
Jimit Bhalavat <jimit@rams.colostate.edu> writes:
> I am Jimit Bhalavat, and I am a Junior at Colorado State > University and my major is Computer Science. Recently, I accepted > to work on Hyperledger Git Commit Signing Project through The > Linux Foundation and my mentor is David Huseby. I am writing to > you in order to ask you if you are the maintainer for the GPG > Signing Project? > > Which branches are for refactoring/new features in the GPG Commit > Signing Project?
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?
[Reference]
*1* https://wiki.hyperledger.org/display/INTERN/Git+signing+with+DIDs
Re: GPG Commit Signing Project
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@genre.crustytoothpaste.net/
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
brian m. carlsonRe: GPG Commit Signing Project
On 2020-06-12 at 01:55:56, dwh@linuxprogrammer.org wrote:
> 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.
This becomes pretty tricky because Git parses OpenPGP headers in a variety of places (e.g., at the end of tags). If your proposal is to wrap new formats in a fake OpenPGP format, like some existing tools do, then that would be viable, but otherwise you're going to require either Git to know about your signing format specifically (which is not a sustainable approach) or some sort of configuration framework like has been previously discussed.
If you're going to wrap things in a fake OpenPGP format, then you don't actually need to send any patches to Git at all; you can simply set gpg.program and continue.
-- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Junio C HamanoRe: GPG Commit Signing Project
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2020-06-12 at 01:55:56, dwh@linuxprogrammer.org wrote: >> 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. > > This becomes pretty tricky because Git parses OpenPGP headers in a > variety of places (e.g., at the end of tags). If your proposal is to > wrap new formats in a fake OpenPGP format, like some existing tools do, > then that would be viable, but otherwise you're going to require either > Git to know about your signing format specifically (which is not a > sustainable approach) or some sort of configuration framework like has > been previously discussed. > > If you're going to wrap things in a fake OpenPGP format, then you don't > actually need to send any patches to Git at all; you can simply set > gpg.program and continue.
True enough ;-) Thanks for a concise summary of the situation.