On Fri, Aug 03, 2018 at 06:07:46PM -0400, Jeff King wrote:
There's been some work on this lately. See this patch and the response
thread:
https://public-inbox.org/git/20180409204129.43537-9-mastahyeti@xxxxxxxxx/
The more recent work focused on just doing the minimum to provide
gpg/gpgsm variants:
https://public-inbox.org/git/cover.1531831244.git.henning.schild@xxxxxxxxxxx/
That replaces the earlier patch series, and is currently merged to the
'next' branch and is on track to get merged to 'master' before Git 2.19
is released.
thank you for setting the context. it looks like both patch sets are going in
the same direction that i suggested, at least with the config variables.
personally, i prefer the 'signingtool.<tool>' approach in the older patch set
over the 'gpg.<tool>' approach in the newer patch set since my goal is to get
away from assuming gpg.
the older patch set suggested the idea of using PEM strings to match up the
signature payload with a certain signing tool. i can't tell if they mean the
'pre-ecapsulation boundary' (e.g. '-----BEGIN FOO-----') or if they mean the
encapsulated headers; both as defined in RFC 1421 [0].
the newer patch set looks specifically at the pre-encapsulation boundary to
switch behaviors. that works assuming that the signing tools all understand
PEM. in the case of signify, it doesn't, so the driver code in git will have to
translate to/from PEM.
i suggest that we switch to a standard format for all signatures that is
similar to the commit message format with colon ':' separated fields followed
by a payload. the colon separated fields would specify the signing tool used
to generate the signature and the tool specific data followed by the signature
blob like so:
signing-tool: gpg
gpg-keyid: 0123456789ABCDEF
-----BEGIN PGP SIGNATURE-----
<base64 encoded signature>
-----END PGP SIGNATURE-----
by adopting this format, git will be fully abstracted from the underlying
signing tool and the user can specify multiple signing tools in their config
and git will be able to map the signature to the tool when verifying (e.g. git
log --show-signature).
a signify signature would look something like this:
signing-tool: signify
signify-public-key: <base64 encoded public key>
<base64 encoded signature>
i hope we adopt a more generic approach like this.
One of the downsides there is that if we eventually move to a generic
signing-tool config, we'd have to support two layers of historical
abstraction (the original "gpg.program" config, and the new
"gpg.<tool>.*" config).
i like the idea of aliasing all of the old config variables to their equivilent
and outputting a deprecation warning when we get plan on removing the aliases
altogether in the future.
So _if_ we knew what it would take to support signify, we could
potentially adjust what's going into 2.19 in order to skip straight to
the more generic interface. But on the OTOH, it may not be worth
rushing, and there is already a vague plan of how the gpg.<tool>.*
config would interact with a more generic config.
there's no rush, but i would prefer that the newer patch set get changed to use
the more generic 'signingtool.<tool>.*' instead of 'gpg.<tool>.*'. if you all
agree, i'll follow up with a patch to change that part of what is going into
2.19.
then round two will be to experiment with a new, standard signature format that
doesn't assume anything about the underlying signing tool.
//tæ
[0] https://tools.ietf.org/html/rfc1421
