{"thread":{"id":"57122","subject":"[RFC PATCH 0/2] cryptoSign flag & config","startedAt":"2021-12-20T14:09:43Z","lastAt":"2021-12-21T09:39:46Z","messageCount":7,"participants":["Fabian Stelzer","Junio C Hamano","Eric Sunshine"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"444465","messageId":"20211220140928.1205586-1-fs@gigacodes.de","threadId":"57122","inReplyTo":null,"subject":"[RFC PATCH 0/2] cryptoSign flag & config","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-20T14:09:26Z","receivedAt":"2021-12-20T14:09:43Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"Since git now supports multiple methods for signing objects some of the \nexisting flags and configuration variables can be misleading. Especially the \nflags could be understood as selecting a format (--gpg-sign), which they do \nnot.\n\nThis series introduces the more generic name \"cryptoSign\". Using just \"sign\" \ncould otherwise be too easily confused with \"sign-off\".\n\nFor now I have only adjusted the gpg-sign flag to a single command and added \nthe new configuration prefix and would like to hear some feedback. If we can \nagree on the naming and implementation I will of course adjust all the other \ncommands likewise and add some tests for the compatibility layer.\nThe `(commit|tag|push).gpgsign` var is still on my todo list as well. \n\nMy earlier question to the list () did not \nreceive much feedback so i'm sending this rfc patch.\n\nFabian Stelzer (2):\n crypto sign: add crypto-sign alias flag\n crypto sign: add cryptoSign.* config\n\n Documentation/config/gpg.txt | 31 ++++++++++++++++++++-----------\n Documentation/git-commit.txt | 15 ++++++++++-----\n builtin/commit.c | 5 ++++-\n gpg-interface.c | 30 ++++++++++++++++++++++--------\n 4 files changed, 56 insertions(+), 25 deletions(-)\n\n-- \n2.33.1\n\n"},{"id":"444466","messageId":"20211220140928.1205586-2-fs@gigacodes.de","threadId":"57122","inReplyTo":"20211220140928.1205586-1-fs@gigacodes.de","subject":"[RFC PATCH 1/2] crypto sign: add crypto-sign alias flag","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-20T14:09:27Z","receivedAt":"2021-12-20T14:09:44Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"Multiple commands allow passing `--gpg-sign` or `--no-gpg-sign` to\nenable or disable object signing. Since git can now use other methods\nfor signing this flag could suggest that it selects `gpg` as the method\nto use, which it does not.\nSince just `--sign` would conflict with `--signoff` too easily we choose\n`--crypto-sign` as a more general name.\n\nAdd the new flag to all affected commands as an alias to gpg-sign.\nMove the `-S` shorthand to the new flag to indicate that this is the\nrecommended one to use.\nUpdate the documentation to match.\n\nThis affects the commands: am, commit-tree, commit, merge, rebase and\nrevert.\n---\n Documentation/git-commit.txt | 15 ++++++++++-----\n builtin/commit.c | 5 ++++-\n 2 files changed, 14 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 6c60bf98f9..b2c1d8bdb9 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -387,13 +387,18 @@ changes to tracked files.\n \tdefault commit message.\n \n -S[]::\n+--crypto-sign[=]::\n+--no-crypto-sign::\n --gpg-sign[=]::\n --no-gpg-sign::\n-\tGPG-sign commits. The `keyid` argument is optional and\n-\tdefaults to the committer identity; if specified, it must be\n-\tstuck to the option without a space. `--no-gpg-sign` is useful to\n-\tcountermand both `commit.gpgSign` configuration variable, and\n-\tearlier `--gpg-sign`.\n+\tCryptographically sign commits. The `keyid` argument is optional and\n+\tits default depends on the configured `cryptoSign.format`; if specified,\n+\tit must be stuck to the option without a space. `--no-crypto-sign` is\n+\tuseful to countermand both `commit.gpgSign` configuration variable, and\n+\tearlier `--crypto-sign`.\n+\t`--(no-)gpg-sign` is a compatibility alias and has no effect on which\n+\tcryptographic format will be used. This is determined by the\n+\tconfiguration variable cryptoSign.format (see linkgit:git-config[1]).\n \n \\--::\n \tDo not interpret any more arguments as options.\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex 883c16256c..2c789ff6f9 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -1639,8 +1639,11 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \t\tOPT_BOOL('e', \"edit\", &edit_flag, N_(\"force edit of commit\")),\n \t\tOPT_CLEANUP(&cleanup_arg),\n \t\tOPT_BOOL(0, \"status\", &include_status, N_(\"include status in commit message template\")),\n-\t\t{ OPTION_STRING, 'S', \"gpg-sign\", &sign_commit, N_(\"key-id\"),\n+\t\t{ OPTION_STRING, 'S', \"crypto-sign\", &sign_commit, N_(\"key-id\"),\n+\t\t N_(\"cryptographically sign commit\"), PARSE_OPT_OPTARG, NULL, (intptr_t) \"\" },\n+\t\t{ OPTION_STRING, 0, \"gpg-sign\", &sign_commit, N_(\"key-id\"),\n \t\t N_(\"GPG sign commit\"), PARSE_OPT_OPTARG, NULL, (intptr_t) \"\" },\n+\n \t\t/* end commit message options */\n \n \t\tOPT_GROUP(N_(\"Commit contents options\")),\n-- \n2.33.1\n\n"},{"id":"444467","messageId":"20211220140928.1205586-3-fs@gigacodes.de","threadId":"57122","inReplyTo":"20211220140928.1205586-1-fs@gigacodes.de","subject":"[RFC PATCH 2/2] crypto sign: add cryptoSign.* config","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-20T14:09:28Z","receivedAt":"2021-12-20T14:09:45Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"Since git now supports multiple cryptographic methods/formats to sign\nobjects, the `gpg.` configuration prefix is misleading.\nAdd `cryptoSign.`, but keep `gpg.` as a compatibility alias at least for\nall existing options.\n`gpg.mintrustlevel` is moved to `cryptosign.gpg.mintrustlevel` while\nalso still allowing the former.\n---\n Documentation/config/gpg.txt | 31 ++++++++++++++++++++-----------\n gpg-interface.c | 30 ++++++++++++++++++++++--------\n 2 files changed, 42 insertions(+), 19 deletions(-)\n\ndiff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt\nindex 4f30c7dbdd..ef21eb8249 100644\n--- a/Documentation/config/gpg.txt\n+++ b/Documentation/config/gpg.txt\n@@ -1,6 +1,17 @@\n gpg.program::\n-\tUse this custom program instead of \"`gpg`\" found on `$PATH` when\n-\tmaking or verifying a PGP signature. The program must support the\n+\tDeprecated alias for `cryptoSign..program`.\n+\n+cryptoSign.format::\n+gpg.format::\n+\tSpecifies which key format to use when signing with `--crypto-sign`.\n+\tDefault is \"openpgp\". Other possible values are \"x509\", \"ssh\".\n+\n+cryptoSign..program::\n+gpg..program::\n+\tUse this to customize the program used for the signing format you\n+\tchose (see `cryptoSign.format`). The default value for\n+\t`gpg.x509.program` is \"gpgsm\" and `gpg.ssh.program` is \"ssh-keygen\".\n+\tWith the format set to \"opengpg\" or \"x509\" the program must support the\n \tsame command-line interface as GPG, namely, to verify a detached\n \tsignature, \"`gpg --verify $signature - <$file`\" is run, and the\n \tprogram is expected to signal a good signature by exiting with\n@@ -8,17 +19,12 @@ gpg.program::\n \tstandard input of \"`gpg -bsau $key`\" is fed with the contents to be\n \tsigned, and the program is expected to send the result to its\n \tstandard output.\n+\tIf the format is \"ssh\", then the configured program must implement the\n+\t`ssh-keygen -Y find-principals|check-novalidate|verify|sign` commands\n+\t(see ssh-keygen(1) man page).\n \n-gpg.format::\n-\tSpecifies which key format to use when signing with `--gpg-sign`.\n-\tDefault is \"openpgp\". Other possible values are \"x509\", \"ssh\".\n-\n-gpg..program::\n-\tUse this to customize the program used for the signing format you\n-\tchose. (see `gpg.program` and `gpg.format`) `gpg.program` can still\n-\tbe used as a legacy synonym for `gpg.openpgp.program`. The default\n-\tvalue for `gpg.x509.program` is \"gpgsm\" and `gpg.ssh.program` is \"ssh-keygen\".\n \n+crpytoSign.gpg.minTrustLevel::\n gpg.minTrustLevel::\n \tSpecifies a minimum trust level for signature verification. If\n \tthis option is unset, then signature verification for merge\n@@ -34,12 +40,14 @@ gpg.minTrustLevel::\n * `fully`\n * `ultimate`\n \n+cryptoSign.ssh.defaultKeyCommand::\n gpg.ssh.defaultKeyCommand:\n \tThis command that will be run when user.signingkey is not set and a ssh\n \tsignature is requested. On successful exit a valid ssh public key is\n \texpected in the\tfirst line of its output. To automatically use the first\n \tavailable key from your ssh-agent set this to \"ssh-add -L\".\n \n+cryptoSign.ssh.allowedSignersFile::\n gpg.ssh.allowedSignersFile::\n \tA file containing ssh public keys which you are willing to trust.\n \tThe file consists of one or more lines of principals followed by an ssh\n@@ -67,6 +75,7 @@ This way only committers with an already valid key can add or change keys in the\n Using a SSH CA key with the cert-authority option\n (see ssh-keygen(1) \"CERTIFICATES\") is also valid.\n \n+cryptoSign.ssh.revocationFile::\n gpg.ssh.revocationFile::\n \tEither a SSH KRL or a list of revoked public keys (without the principal prefix).\n \tSee ssh-keygen(1) for details.\ndiff --git a/gpg-interface.c b/gpg-interface.c\nindex 3e7255a2a9..eacafcd56e 100644\n--- a/gpg-interface.c\n+++ b/gpg-interface.c\n@@ -638,6 +638,7 @@ int git_gpg_config(const char *var, const char *value, void *cb)\n \tstruct gpg_format *fmt = NULL;\n \tchar *fmtname = NULL;\n \tchar *trust;\n+\tconst char *crypto_var = NULL;\n \tint ret;\n \n \tif (!strcmp(var, \"user.signingkey\")) {\n@@ -647,7 +648,17 @@ int git_gpg_config(const char *var, const char *value, void *cb)\n \t\treturn 0;\n \t}\n \n-\tif (!strcmp(var, \"gpg.format\")) {\n+\t/*\n+\t * `gpg.` is a backwards compatibility prefix alias for `cryptosign.`\n+\t * All following vars expect a prefix so we can return early if\n+\t * there is none\n+\t */\n+\tif (!skip_prefix(var, \"gpg.\", &crypto_var) &&\n+\t !skip_prefix(var, \"cryptosign.\", &crypto_var))\n+\t\treturn 0;\n+\n+\n+\tif (!strcmp(crypto_var, \"format\")) {\n \t\tif (!value)\n \t\t\treturn config_error_nonbool(var);\n \t\tfmt = get_format_by_name(value);\n@@ -658,7 +669,9 @@ int git_gpg_config(const char *var, const char *value, void *cb)\n \t\treturn 0;\n \t}\n \n-\tif (!strcmp(var, \"gpg.mintrustlevel\")) {\n+\t/* `gpg.mintrustlevel` moved to `cryptosign.gpg.mintrustlevel` */\n+\tif (!strcmp(crypto_var, \"mintrustlevel\") ||\n+\t !strcmp(crypto_var, \"gpg.mintrustlevel\")) {\n \t\tif (!value)\n \t\t\treturn config_error_nonbool(var);\n \n@@ -672,31 +685,32 @@ int git_gpg_config(const char *var, const char *value, void *cb)\n \t\treturn 0;\n \t}\n \n-\tif (!strcmp(var, \"gpg.ssh.defaultkeycommand\")) {\n+\tif (!strcmp(crypto_var, \"ssh.defaultkeycommand\")) {\n \t\tif (!value)\n \t\t\treturn config_error_nonbool(var);\n \t\treturn git_config_string(&ssh_default_key_command, var, value);\n \t}\n \n-\tif (!strcmp(var, \"gpg.ssh.allowedsignersfile\")) {\n+\tif (!strcmp(crypto_var, \"ssh.allowedsignersfile\")) {\n \t\tif (!value)\n \t\t\treturn config_error_nonbool(var);\n \t\treturn git_config_pathname(&ssh_allowed_signers, var, value);\n \t}\n \n-\tif (!strcmp(var, \"gpg.ssh.revocationfile\")) {\n+\tif (!strcmp(crypto_var, \"ssh.revocationfile\")) {\n \t\tif (!value)\n \t\t\treturn config_error_nonbool(var);\n \t\treturn git_config_pathname(&ssh_revocation_file, var, value);\n \t}\n \n-\tif (!strcmp(var, \"gpg.program\") || !strcmp(var, \"gpg.openpgp.program\"))\n+\tif (!strcmp(crypto_var, \"program\") ||\n+\t !strcmp(crypto_var, \"openpgp.program\"))\n \t\tfmtname = \"openpgp\";\n \n-\tif (!strcmp(var, \"gpg.x509.program\"))\n+\tif (!strcmp(crypto_var, \"x509.program\"))\n \t\tfmtname = \"x509\";\n \n-\tif (!strcmp(var, \"gpg.ssh.program\"))\n+\tif (!strcmp(crypto_var, \"ssh.program\"))\n \t\tfmtname = \"ssh\";\n \n \tif (fmtname) {\n-- \n2.33.1\n\n"},{"id":"444546","messageId":"xmqqr1a7t00y.fsf@gitster.g","threadId":"57122","inReplyTo":"20211220140928.1205586-2-fs@gigacodes.de","subject":"Re: [RFC PATCH 1/2] crypto sign: add crypto-sign alias flag","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-12-20T21:54:37Z","receivedAt":"2021-12-20T21:54:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fabian Stelzer writes:\n\n> +--crypto-sign[=]::\n> +--no-crypto-sign::\n> --gpg-sign[=]::\n> --no-gpg-sign::\n> -\tGPG-sign commits. The `keyid` argument is optional and\n> -\tdefaults to the committer identity; if specified, it must be\n> -\tstuck to the option without a space. `--no-gpg-sign` is useful to\n> -\tcountermand both `commit.gpgSign` configuration variable, and\n> -\tearlier `--gpg-sign`.\n> +\tCryptographically sign commits. The `keyid` argument is optional and\n> +\tits default depends on the configured `cryptoSign.format`; if specified,\n> +\tit must be stuck to the option without a space. `--no-crypto-sign` is\n> +\tuseful to countermand both `commit.gpgSign` configuration variable, and\n> +\tearlier `--crypto-sign`.\n> +\t`--(no-)gpg-sign` is a compatibility alias and has no effect on which\n> +\tcryptographic format will be used. This is determined by the\n> +\tconfiguration variable cryptoSign.format (see linkgit:git-config[1]).\n\nI'd make the last three lines into a separate paragraph and nudge\nusers toward the new spelling if I were doing this change, e.g.\n\n\t...\n\tearlier `--crypto-sign`.\n+\nThe option was originally called `--[no-]gpg-sign` and is still\nsupported as a synonym, but it is encouraged to migrate to use\nthe `--crypto-sign` option.\n\nNot the problem with this patch, but can the format be inferred from\n?\n\nIf so, `--crypt-sign=` can choose the format X\nand specify what exact key to use at the same time without the\ncryptosign.format configuration variable. But if not, the interface\nleaves us in an awkward place by letting different keys easily\nspecified from the command line while making it impossible to\nswitch between GPG and SSH from the command line.\n\nIf --gpg-sign is not a mere synonym, but also implies GPG is\npreferred when cryptoSign.format is not specified, that is a\ndifferent story, of course. That makes it unnecessary to deprecate\n`--gpg-sign` and in addition we need to add `--ssh-sign` option that\nworks similarly, which may not scale well but I do not expect we'd\nadd many more next to GPG and SSH, hopefully? I dunno.\n\n> diff --git a/builtin/commit.c b/builtin/commit.c\n> index 883c16256c..2c789ff6f9 100644\n> --- a/builtin/commit.c\n> +++ b/builtin/commit.c\n> @@ -1639,8 +1639,11 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n> \t\tOPT_BOOL('e', \"edit\", &edit_flag, N_(\"force edit of commit\")),\n> \t\tOPT_CLEANUP(&cleanup_arg),\n> \t\tOPT_BOOL(0, \"status\", &include_status, N_(\"include status in commit message template\")),\n> -\t\t{ OPTION_STRING, 'S', \"gpg-sign\", &sign_commit, N_(\"key-id\"),\n> +\t\t{ OPTION_STRING, 'S', \"crypto-sign\", &sign_commit, N_(\"key-id\"),\n> +\t\t N_(\"cryptographically sign commit\"), PARSE_OPT_OPTARG, NULL, (intptr_t) \"\" },\n> +\t\t{ OPTION_STRING, 0, \"gpg-sign\", &sign_commit, N_(\"key-id\"),\n> \t\t N_(\"GPG sign commit\"), PARSE_OPT_OPTARG, NULL, (intptr_t) \"\" },\n\nLeaving this explained as \"GPG sign commit\" contradicts \"it is a\nmere alias that does not even imply GPG is preferred when no\npreference is given by the cryptoSign.format variable\".\n\n> +\n\nUnwanted blank line before the \"this is the last line of these\noptions\" marker?\n\n> \t\t/* end commit message options */\n> \n> \t\tOPT_GROUP(N_(\"Commit contents options\")),\n"},{"id":"444549","messageId":"CAPig+cRGnMQaDj-qocpAbhQqyksCNqGub+LsspWf7-Dwy=TKzg@mail.gmail.com","threadId":"57122","inReplyTo":"20211220140928.1205586-3-fs@gigacodes.de","subject":"Re: [RFC PATCH 2/2] crypto sign: add cryptoSign.* config","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-12-20T22:07:48Z","receivedAt":"2021-12-20T22:08:01Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"`On Mon, Dec 20, 2021 at 9:09 AM Fabian Stelzer wrote:\n> Since git now supports multiple cryptographic methods/formats to sign\n> objects, the `gpg.` configuration prefix is misleading.\n> Add `cryptoSign.`, but keep `gpg.` as a compatibility alias at least for\n> all existing options.\n> `gpg.mintrustlevel` is moved to `cryptosign.gpg.mintrustlevel` while\n> also still allowing the former.\n> ---\n> diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt\n> @@ -1,6 +1,17 @@\n> +cryptoSign.format::\n> +gpg.format::\n> + Specifies which key format to use when signing with `--crypto-sign`.\n> + Default is \"openpgp\". Other possible values are \"x509\", \"ssh\".\n> +\n> +cryptoSign..program::\n> +gpg..program::\n> + Use this to customize the program used for the signing format you\n> + chose (see `cryptoSign.format`). The default value for\n\nThis is a somewhat minor comment, but I find that grouping these\nconfig keys together like this gives too much weight to the old\n`gpg.foo` ones, making it seem as if they're still first-class\ncitizens which people can use freely. If you instead organize them as\nbelow, then it is easier to see at a glance that the old keys\nshouldn't be used:\n\n cryptoSign.format::\n Specifies which key format to use when signing...\n\n cryptoSign..program::\n Use this to customize the program used...\n\n ...\n\n gpg.format::\n Deprecated synonym of `cryptoSign.format`.\n\n gpg..program::\n Deprecated synonym of `cryptoSign..program`.\n\nThe same observation about grouping of config keys applies to the\nremainder of the documentation changes in this patch.\n"},{"id":"444592","messageId":"20211221093716.nalrgfsvl6ovjdqr@fs","threadId":"57122","inReplyTo":"xmqqr1a7t00y.fsf@gitster.g","subject":"Re: [RFC PATCH 1/2] crypto sign: add crypto-sign alias flag","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-21T09:37:16Z","receivedAt":"2021-12-21T09:37:21Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 20.12.2021 13:54, Junio C Hamano wrote:\n>Fabian Stelzer writes:\n>\n>> +--crypto-sign[=]::\n>> +--no-crypto-sign::\n>> --gpg-sign[=]::\n>> --no-gpg-sign::\n>> -\tGPG-sign commits. The `keyid` argument is optional and\n>> -\tdefaults to the committer identity; if specified, it must be\n>> -\tstuck to the option without a space. `--no-gpg-sign` is useful to\n>> -\tcountermand both `commit.gpgSign` configuration variable, and\n>> -\tearlier `--gpg-sign`.\n>> +\tCryptographically sign commits. The `keyid` argument is optional and\n>> +\tits default depends on the configured `cryptoSign.format`; if specified,\n>> +\tit must be stuck to the option without a space. `--no-crypto-sign` is\n>> +\tuseful to countermand both `commit.gpgSign` configuration variable, and\n>> +\tearlier `--crypto-sign`.\n>> +\t`--(no-)gpg-sign` is a compatibility alias and has no effect on which\n>> +\tcryptographic format will be used. This is determined by the\n>> +\tconfiguration variable cryptoSign.format (see linkgit:git-config[1]).\n>\n>I'd make the last three lines into a separate paragraph and nudge\n>users toward the new spelling if I were doing this change, e.g.\n>\n>\t...\n>\tearlier `--crypto-sign`.\n>+\n>The option was originally called `--[no-]gpg-sign` and is still\n>supported as a synonym, but it is encouraged to migrate to use\n>the `--crypto-sign` option.\n\nWill do.\n\n>\n>Not the problem with this patch, but can the format be inferred from\n>?\n>\n>If so, `--crypt-sign=` can choose the format X\n>and specify what exact key to use at the same time without the\n>cryptosign.format configuration variable. But if not, the interface\n>leaves us in an awkward place by letting different keys easily\n>specified from the command line while making it impossible to\n>switch between GPG and SSH from the command line.\n>\n\nI thought about doing this when we added the key:: prefix to differentiate \nbetween literal keys and file paths for ssh. Something like \nssh-key::/ssh-file::/gpg-key::\nI decided against it since I think this could lead to different to \nunderstand behaviour for the user. It is quite clear that a flag takes \nprecedence over a config var, but what if i set `format=gpg` and then \n`user.signingkey=ssh-key::...`?\nIf we would start this from a green field and did not have the format \nsetting, then just inferring from the key would be ok. But with the backward \ncompatibility I think this is too confusing.\n\n>If --gpg-sign is not a mere synonym, but also implies GPG is\n>preferred when cryptoSign.format is not specified, that is a\n>different story, of course. That makes it unnecessary to deprecate\n>`--gpg-sign` and in addition we need to add `--ssh-sign` option that\n>works similarly, which may not scale well but I do not expect we'd\n>add many more next to GPG and SSH, hopefully? I dunno.\n>\n\nThis is indeed a path we could take. Here the flag would have precedence \nover the config. However it would not make sense to just specify --ssh-sign \nwhen `user.signingkey` is set to a gpg key id. So the user would always have \nto specify the key or we would need to move the signing key config into the \nformat specific blocks leading to even more compatibility code paths :/\n\nI'm going to make some bold assumptions here, so please correct me if I'm \nwrong.\nMost users will not need to switch signing methods within repositories, if \nat all. Corporate users will probably adopt ssh, if anything at all. I have \nnever seen gpg consistently used in a corporate setup. Open source \ndevelopment is heavily leaning on gpg. So the most common case will probably \nbe users having to switch between work (ssh) & oss (gpg) development which \ncan either be configured per repository or by using `includeIf \"gitdir:\"` in \nyour .gitconfig.\n\nSo I think the extra flags or extended key prefixes to infer the format are \nnot needed and we can choose the simple option of only having the single \ncryptosign.format config.\n\n>> diff --git a/builtin/commit.c b/builtin/commit.c\n>> index 883c16256c..2c789ff6f9 100644\n>> --- a/builtin/commit.c\n>> +++ b/builtin/commit.c\n>> @@ -1639,8 +1639,11 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n>> \t\tOPT_BOOL('e', \"edit\", &edit_flag, N_(\"force edit of commit\")),\n>> \t\tOPT_CLEANUP(&cleanup_arg),\n>> \t\tOPT_BOOL(0, \"status\", &include_status, N_(\"include status in commit message template\")),\n>> -\t\t{ OPTION_STRING, 'S', \"gpg-sign\", &sign_commit, N_(\"key-id\"),\n>> +\t\t{ OPTION_STRING, 'S', \"crypto-sign\", &sign_commit, N_(\"key-id\"),\n>> +\t\t N_(\"cryptographically sign commit\"), PARSE_OPT_OPTARG, NULL, (intptr_t) \"\" },\n>> +\t\t{ OPTION_STRING, 0, \"gpg-sign\", &sign_commit, N_(\"key-id\"),\n>> \t\t N_(\"GPG sign commit\"), PARSE_OPT_OPTARG, NULL, (intptr_t) \"\" },\n>\n>Leaving this explained as \"GPG sign commit\" contradicts \"it is a\n>mere alias that does not even imply GPG is preferred when no\n>preference is given by the cryptoSign.format variable\".\n>\n\nTrue, will fix.\n\n>> +\n>\n>Unwanted blank line before the \"this is the last line of these\n>options\" marker?\n>\n>> \t\t/* end commit message options */\n>>\n>> \t\tOPT_GROUP(N_(\"Commit contents options\")),\n"},{"id":"444593","messageId":"20211221093941.53ks5gnbkxl7vkn6@fs","threadId":"57122","inReplyTo":"CAPig+cRGnMQaDj-qocpAbhQqyksCNqGub+LsspWf7-Dwy=TKzg@mail.gmail.com","subject":"Re: [RFC PATCH 2/2] crypto sign: add cryptoSign.* config","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2021-12-21T09:39:41Z","receivedAt":"2021-12-21T09:39:46Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 20.12.2021 17:07, Eric Sunshine wrote:\n>`On Mon, Dec 20, 2021 at 9:09 AM Fabian Stelzer wrote:\n>> Since git now supports multiple cryptographic methods/formats to sign\n>> objects, the `gpg.` configuration prefix is misleading.\n>> Add `cryptoSign.`, but keep `gpg.` as a compatibility alias at least for\n>> all existing options.\n>> `gpg.mintrustlevel` is moved to `cryptosign.gpg.mintrustlevel` while\n>> also still allowing the former.\n>> ---\n>> diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt\n>> @@ -1,6 +1,17 @@\n>> +cryptoSign.format::\n>> +gpg.format::\n>> + Specifies which key format to use when signing with `--crypto-sign`.\n>> + Default is \"openpgp\". Other possible values are \"x509\", \"ssh\".\n>> +\n>> +cryptoSign..program::\n>> +gpg..program::\n>> + Use this to customize the program used for the signing format you\n>> + chose (see `cryptoSign.format`). The default value for\n>\n>This is a somewhat minor comment, but I find that grouping these\n>config keys together like this gives too much weight to the old\n>`gpg.foo` ones, making it seem as if they're still first-class\n>citizens which people can use freely. If you instead organize them as\n>below, then it is easier to see at a glance that the old keys\n>shouldn't be used:\n>\n> cryptoSign.format::\n> Specifies which key format to use when signing...\n>\n> cryptoSign..program::\n> Use this to customize the program used...\n>\n> ...\n>\n> gpg.format::\n> Deprecated synonym of `cryptoSign.format`.\n>\n> gpg..program::\n> Deprecated synonym of `cryptoSign..program`.\n>\n>The same observation about grouping of config keys applies to the\n>remainder of the documentation changes in this patch.\n\nI wasn't sure how much we want to already deprecate the `gpg.` keys so I \ntried a gentle approach :)\nBut I would be in favor of your variant.\n\nThanks\n"}]}