git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fabian Stelzer <fs@gigacodes.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Git SSH/GPG signing flags and config
Date: Sun, 5 Dec 2021 12:36:50 +0100	[thread overview]
Message-ID: <20211205113650.33hndvacye2fjwkh@fs> (raw)
In-Reply-To: <xmqqzgpn50l6.fsf@gitster.g>

On 28.11.2021 15:20, Junio C Hamano wrote:
>Fabian Stelzer <fs@gigacodes.de> writes:
>
>> Hi everyone,
>> the `signing git objects with ssh` series was released with 2.34 and
>> i'd like to thank everyone for your support and the good reviews!
>> I think it would be beneficial now to adjust some of the wording in
>> flags and the config. Currently everything is configured via gpg.* and
>> all the `please sign this` flags are named --(no-?)gpg-sign.
>> I would be in favor of a more generic flag independent of the signing
>> mechanism. Adding something like `--ssh-sign` would suggest that you'd
>> be able to switch signing format with it which i think would not be
>> terribly useful. If you need to use multiple signing mechanism those
>> would usually be configured per repository and can easily be done with
>> an `includeif gitdir:` in your config.
>> Therefore i would suggest just adding a generic `--(no-?)sign` to all
>> the commands that support gpg-sign right now. The only problem i see
>> is a conflict with `--signoff` so i'm open to other naming ideas. The
>> same goes for the config. `sign.` as an alias to `gpg.` would work
>> well with the current settings.
>> Let me know what you think and i could prepare a first patch for one
>> command to see what the alias / config / docs change could look like.
>
>I do share your worry about --sign to be confused with the sign-off
>procedure, and that was why the original used --gpg-sign.  We are
>extending "gpg" part because "gpg" is not the only cryptographic
>signing protocol we support, so perhaps --crypto-sign would still be
>in the orginal spirit of "This is different from the sign-off, but
>is a cryptographic signature, but it is a mouthful.
>
Even if it's a bit much, including the word crypto makes it quite clear what 
the flag does. This is how this could look for `git commit`. I would do 
something similar for the `gpg.` configs and alias them with `cryptoSign.`
If this diff is acceptable i can prepare a patch series for all the commands 
and the config. Not sure if we want to mark the gpg options as deprecated.  
The problem is that the flags could imply that gpg is used even if another 
format is configured.

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 6c60bf98f9..67fc77dc1b 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -387,13 +387,18 @@ changes to tracked files.
  	default commit message.
  
  -S[<keyid>]::
+--crypto-sign[=<keyid>]::
+--no-crypto-sign::
  --gpg-sign[=<keyid>]::
  --no-gpg-sign::
-	GPG-sign commits. The `keyid` argument is optional and
+	Cryptographically sign commits. The `keyid` argument is optional and
  	defaults to the committer identity; if specified, it must be
-	stuck to the option without a space. `--no-gpg-sign` is useful to
+	stuck to the option without a space. `--no-crypto-sign` is useful to
  	countermand both `commit.gpgSign` configuration variable, and
-	earlier `--gpg-sign`.
+	earlier `--crypto-sign`.
+	`--(no-)gpg-sign` is a compatibility alias and has no effect on which
+	cryptographic format will be used. This is determined by the
+	configuration variable cryptoSign.format (see linkgit:git-config[1]).
  
  \--::
  	Do not interpret any more arguments as options.
diff --git a/builtin/commit.c b/builtin/commit.c
index 883c16256c..2c789ff6f9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1639,8 +1639,11 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
  		OPT_BOOL('e', "edit", &edit_flag, N_("force edit of commit")),
  		OPT_CLEANUP(&cleanup_arg),
  		OPT_BOOL(0, "status", &include_status, N_("include status in commit message template")),
-		{ OPTION_STRING, 'S', "gpg-sign", &sign_commit, N_("key-id"),
+		{ OPTION_STRING, 'S', "crypto-sign", &sign_commit, N_("key-id"),
+		  N_("cryptographically sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
+		{ OPTION_STRING, 0, "gpg-sign", &sign_commit, N_("key-id"),
  		  N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
+
  		/* end commit message options */
  
  		OPT_GROUP(N_("Commit contents options")),


      reply	other threads:[~2021-12-05 11:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-28 12:57 Git SSH/GPG signing flags and config Fabian Stelzer
2021-11-28 23:20 ` Junio C Hamano
2021-12-05 11:36   ` Fabian Stelzer [this message]

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=20211205113650.33hndvacye2fjwkh@fs \
    --to=fs@gigacodes.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).