Christian Couder <christian.couder@xxxxxxxxx> writes:
> A recent commit, d9cb0e6ff8 (fast-export, fast-import: add support for
> signed-commits, 2025-03-10), added support for signed commits.
>
> However, when processing signatures `git fast-export` outputs "gpgsig
> sha1" not just when it encounters an OpenPGP SHA-1 signature, but also
> when it encounters an SSH or X.509 signature. This is not very
> informative to say the least, and this might prevent tools that process
> the output from easily and properly handling signatures.
>
> Let's improve on that by reusing the existing code from
> "gpg-interface.{c,h}" to detect the signature algorithm, and then put
> the signature algorithm name (like "openpgp", "x509" or "ssh") instead
> of "sha1" in the output. If we can't detect the signature algorithm we
> will use "unknown". It might be a signature added by an external tool
> and we should likely keep it.
>
> Similarly on the `git fast-import` side, let's use the existing code
> from "gpg-interface.{c,h}" to check if a signature algorithm name is
> valid. In case of an "unknown" signature algorithm name, we will warn
> but still keep it. Future work might implement several options to let
> users deal with it in different ways, and might implement checking
> known signatures too.
>
> Signed-off-by: Christian Couder <chriscool@xxxxxxxxxxxxx>
> ---
>
> This is a follow up from cc/signed-fast-export-import that was merged
> by 01d17c0530 (Merge branch 'cc/signed-fast-export-import', 2025-03-29)
> and introduced the support for signed commits.
>
> The format that this series implemented was lacking a bit, so the goal
> with this patch is to improve it and handle signed commits a bit more
> consistently in the code base. It also shows in the tests and in our
> documentation that SSH and X.509 signatures are supported.
Thanks.
It is a bit surprising and slightly sad that nobody bothered to
report/complain about the brokenness until the original author
follows up one month later X-<. Nobody but the original author is
using this feature? I would have expected that use of signed
commits were of high demand and many more people were actively
interested in the topic.
> '--signed-commits', you may set the environment variable
> 'FAST_EXPORT_SIGNED_COMMITS_NOABORT=1' in order to change the default
> from 'abort' to 'warn-strip'.
> ++
> +When exported, signature starts with "gpgsig <alg>" where <alg> is the
> +signature algorithm name as identified by Git (e.g. "openpgp", "x509",
> +"ssh", or "sha256" for SHA-256 OpenPGP signatures), or "unknown" for
> +signatures that can't be identified.
Nice to see these enumerated. As we are not opening the choices of
"algorithms" up to end-users by allowing custom signature routines
to be plugged in, configured, or hooked into the system, it may make
sense to make it clear that we will keep a canonical and exhausitve
list here, by saying "one of these:" followed by a bulleted list,
instead of a parenthesized examples (e.g.), like you did in the
other documentation below. Or perhaps refer to the other document
from here so that we do not have to keep two lists in sync?
> diff --git a/Documentation/git-fast-import.adoc b/Documentation/git-fast-import.adoc
> index 7b107f5e8e..50b6d2cc1d 100644
> --- a/Documentation/git-fast-import.adoc
> +++ b/Documentation/git-fast-import.adoc
> @@ -521,7 +521,20 @@ The optional `gpgsig` command is used to include a PGP/GPG signature
> that signs the commit data.
>
> Here <alg> specifies which hashing algorithm is used for this
> -signature, either `sha1` or `sha256`.
> +signature. Current valid values are:
> +
> +* "openpgp" for SHA-1 OpenPGP signatures,
> +
> +* "sha256" for SHA-256 OpenPGP signatures,
> +
> +* "x509" for X.509 (GPGSM) signatures,
> +
> +* "ssh", for SSH signatures,
> +
> +* "unknown" for signatures that can't be identified (a warning is
> + emitted).
> +
> +Signatures are not yet checked in the current implementation though.
Excellent.
> diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> index 170126d41a..d00f02dc74 100644
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -29,6 +29,7 @@
> #include "quote.h"
> #include "remote.h"
> #include "blob.h"
> +#include "gpg-interface.h"
>
> static const char *fast_export_usage[] = {
> N_("git fast-export [<rev-list-opts>]"),
> @@ -700,9 +701,10 @@ static void handle_commit(struct commit *commit, struct rev_info *rev,
> }
>
> if (*commit_buffer_cursor == '\n') {
> - if ((signature = find_commit_multiline_header(commit_buffer_cursor + 1, "gpgsig", &commit_buffer_cursor)))
> - signature_alg = "sha1";
> - else if ((signature = find_commit_multiline_header(commit_buffer_cursor + 1, "gpgsig-sha256", &commit_buffer_cursor)))
> + if ((signature = find_commit_multiline_header(commit_buffer_cursor + 1, "gpgsig", &commit_buffer_cursor))) {
> + const char *name = get_signature_name(signature);
> + signature_alg = name ? name : "unknown";
> + } else if ((signature = find_commit_multiline_header(commit_buffer_cursor + 1, "gpgsig-sha256", &commit_buffer_cursor)))
> signature_alg = "sha256";
The original is bad enough but can we do something to these overly
long lines?
> }
>
> diff --git a/builtin/fast-import.c b/builtin/fast-import.c
> index 63880b595c..59e991a03c 100644
> --- a/builtin/fast-import.c
> +++ b/builtin/fast-import.c
> @@ -29,6 +29,7 @@
> #include "commit-reach.h"
> #include "khash.h"
> #include "date.h"
> +#include "gpg-interface.h"
>
> #define PACK_ID_BITS 16
> #define MAX_PACK_ID ((1<<PACK_ID_BITS)-1)
> @@ -2830,12 +2831,15 @@ static void parse_new_commit(const char *arg)
> "encoding %s\n",
> encoding);
> if (sig_alg) {
> - if (!strcmp(sig_alg, "sha1"))
> - strbuf_addstr(&new_data, "gpgsig ");
> - else if (!strcmp(sig_alg, "sha256"))
> + if (!strcmp(sig_alg, "sha256"))
> strbuf_addstr(&new_data, "gpgsig-sha256 ");
> - else
> - die("Expected gpgsig algorithm sha1 or sha256, got %s", sig_alg);
> + else if (valid_signature_name(sig_alg))
> + strbuf_addstr(&new_data, "gpgsig ");
> + else if (!strcmp(sig_alg, "unknown")) {
> + warning("Unknown gpgsig algorithm name!");
> + strbuf_addstr(&new_data, "gpgsig ");
> + } else
> + die("Invalid gpgsig algorithm name, got '%s'", sig_alg);
Hmph, we used to have special cases for sha1 and sha256 but now we
can handle sha1 with a more generic "valid_signature_name()" logic?
And yet we need to still special case sha256? Not that I trust the
old code all that much and take deviations from the patterns in the
old code as a sign of something not right...
The fast-export stream produced by the code with d9cb0e6f
(fast-export, fast-import: add support for signed-commits,
2025-03-10) used to identify a signature algorithm "sha1", but this
new version of fast-import lost the support for it, and will barf
when seeing such an existing fast-export stream? I am not sure what
is going on around this code.
I am not so worried about the other case, where the stream produced
by fast-export contained in this version may or may not be readable
by an older version of fast-import.
I am puzzled enough, so I'll stop here for now.
Thanks.
