From: dwh@linuxprogrammer.org
To: git@vger.kernel.org
Subject: Re: GPG Commit Signing Project
Date: Thu, 11 Jun 2020 18:55:56 -0700 [thread overview]
Message-ID: <20200612015556.4kvsfcwabuaxuiuc@dev> (raw)
In-Reply-To: <xmqq1rmmg1ds.fsf@gitster.c.googlers.com>
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
next prev parent reply other threads:[~2020-06-12 1:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 18:06 GPG Commit Signing Project Jimit Bhalavat
2020-06-10 19:35 ` Junio C Hamano
2020-06-12 1:55 ` dwh [this message]
2020-06-12 2:24 ` brian m. carlson
2020-06-12 17:03 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2020-08-18 18:43 Jimit Bhalavat
2020-08-18 20:32 ` Junio C Hamano
2020-08-19 10:19 ` brian m. carlson
2020-07-07 18:01 Jimit Bhalavat
2020-07-07 19:10 ` Junio C Hamano
2020-06-10 23:11 Jimit Bhalavat
2020-06-10 17:57 Jimit Bhalavat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200612015556.4kvsfcwabuaxuiuc@dev \
--to=dwh@linuxprogrammer.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).