{"thread":{"id":"57933","subject":"[PATCH] ssh signing: Support ECDSA as literal SSH keys","startedAt":"2022-05-30T17:45:25Z","lastAt":"2022-06-13T01:15:17Z","messageCount":9,"participants":["Andy Lindeman via GitGitGadget","Fabian Stelzer","Andy Lindeman","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"456376","messageId":"pull.1272.git.git.1653932705097.gitgitgadget@gmail.com","threadId":"57933","inReplyTo":null,"subject":"[PATCH] ssh signing: Support ECDSA as literal SSH keys","fromName":"Andy Lindeman via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-30T17:45:04Z","receivedAt":"2022-05-30T17:45:25Z","isPatch":true,"sender":{"key":"andy@lindeman.io","avatar":"https://gravatar.com/avatar/271232963028fcde203abe47abb859d4997adfa8686032ef2dd387317405cf1a?d=mp&s=160"},"body":"From: Andy Lindeman <andy@lindeman.io>\n\nKeys generated using `ssh-keygen -t ecdsa` or similar are being rejected\nas literal SSH keys because the prefix is `ecdsa-sha2-nistp256`,\n`ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`.\n\nThis was acknowledged as an issue [1] in the past, but hasn't yet been\nfixed.\n\n[1]: https://github.com/git/git/pull/1041#issuecomment-971425601\n\nSigned-off-by: Andy Lindeman <andy@lindeman.io>\n---\n    ssh signing: Support ECDSA as literal SSH keys\n    \n    Keys generated using ssh-keygen -t ecdsa or similar will currently be\n    rejected as literal SSH keys because the prefix is ecdsa-sha2-nistp256,\n    ecdsa-sha2-nistp384 or ecdsa-sha2-nistp521.\n    \n    This was acknowledged as an issue in the past, but hasn't yet been\n    fixed.\n    \n    https://github.com/git/git/pull/1041#issuecomment-971425601\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1272%2Falindeman%2Fecdsa-sha2-keys-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1272/alindeman/ecdsa-sha2-keys-v1\nPull-Request: https://github.com/git/git/pull/1272\n\n gpg-interface.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/gpg-interface.c b/gpg-interface.c\nindex 280f1fa1a58..086bd03b51d 100644\n--- a/gpg-interface.c\n+++ b/gpg-interface.c\n@@ -779,7 +779,7 @@ static int is_literal_ssh_key(const char *string, const char **key)\n {\n \tif (skip_prefix(string, \"key::\", key))\n \t\treturn 1;\n-\tif (starts_with(string, \"ssh-\")) {\n+\tif (starts_with(string, \"ssh-\") || starts_with(string, \"ecdsa-sha2-\")) {\n \t\t*key = string;\n \t\treturn 1;\n \t}\n\nbase-commit: 8ddf593a250e07d388059f7e3f471078e1d2ed5c\n-- \ngitgitgadget\n"},{"id":"456382","messageId":"20220531073445.iuovy634ufp5xims@fs","threadId":"57933","inReplyTo":"pull.1272.git.git.1653932705097.gitgitgadget@gmail.com","subject":"Re: [PATCH] ssh signing: Support ECDSA as literal SSH keys","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2022-05-31T07:34:45Z","receivedAt":"2022-05-31T07:35:18Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 30.05.2022 17:45, Andy Lindeman via GitGitGadget wrote:\n>From: Andy Lindeman <andy@lindeman.io>\n>\n>Keys generated using `ssh-keygen -t ecdsa` or similar are being rejected\n>as literal SSH keys because the prefix is `ecdsa-sha2-nistp256`,\n>`ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`.\n>\n>This was acknowledged as an issue [1] in the past, but hasn't yet been\n>fixed.\n\nHi Andy,\nthanks for your report. We have decided in the past to not explicitly cater \nto every key prefix and instead use `key::` for literal keys.\nSee \nhttps://git-scm.com/docs/git-config#Documentation/git-config.txt-usersigningKey\n\n`For backward compatibility, a raw key which begins with \"ssh-\", such as \n\"ssh-rsa XXXXXX identifier\", is treated as \"key::ssh-rsa XXXXXX identifier\", \nbut this form is deprecated; use the key:: form instead.`\n\n>\n>[1]: https://github.com/git/git/pull/1041#issuecomment-971425601\n>\n>Signed-off-by: Andy Lindeman <andy@lindeman.io>\n>---\n>    ssh signing: Support ECDSA as literal SSH keys\n>\n>    Keys generated using ssh-keygen -t ecdsa or similar will currently be\n>    rejected as literal SSH keys because the prefix is ecdsa-sha2-nistp256,\n>    ecdsa-sha2-nistp384 or ecdsa-sha2-nistp521.\n>\n>    This was acknowledged as an issue in the past, but hasn't yet been\n>    fixed.\n>\n>    https://github.com/git/git/pull/1041#issuecomment-971425601\n>\n>Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1272%2Falindeman%2Fecdsa-sha2-keys-v1\n>Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1272/alindeman/ecdsa-sha2-keys-v1\n>Pull-Request: https://github.com/git/git/pull/1272\n>\n> gpg-interface.c | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n>diff --git a/gpg-interface.c b/gpg-interface.c\n>index 280f1fa1a58..086bd03b51d 100644\n>--- a/gpg-interface.c\n>+++ b/gpg-interface.c\n>@@ -779,7 +779,7 @@ static int is_literal_ssh_key(const char *string, const char **key)\n> {\n> \tif (skip_prefix(string, \"key::\", key))\n> \t\treturn 1;\n>-\tif (starts_with(string, \"ssh-\")) {\n>+\tif (starts_with(string, \"ssh-\") || starts_with(string, \"ecdsa-sha2-\")) {\n> \t\t*key = string;\n> \t\treturn 1;\n> \t}\n>\n>base-commit: 8ddf593a250e07d388059f7e3f471078e1d2ed5c\n>-- \n>gitgitgadget\n"},{"id":"456386","messageId":"CA+vJLfu1WyqP4V44iyZj+Fyr8O7JSB8tSJfOmS1SeSZ65fXh0w@mail.gmail.com","threadId":"57933","inReplyTo":"20220531073445.iuovy634ufp5xims@fs","subject":"Re: [PATCH] ssh signing: Support ECDSA as literal SSH keys","fromName":"Andy Lindeman","fromEmail":"andy@lindeman.io","sentAt":"2022-05-31T13:28:53Z","receivedAt":"2022-05-31T13:29:14Z","isPatch":true,"sender":{"key":"andy@lindeman.io","avatar":"https://gravatar.com/avatar/271232963028fcde203abe47abb859d4997adfa8686032ef2dd387317405cf1a?d=mp&s=160"},"body":"On Tue, May 31, 2022 at 3:34 AM Fabian Stelzer <fs@gigacodes.de> wrote:\n> On 30.05.2022 17:45, Andy Lindeman via GitGitGadget wrote:\n> >From: Andy Lindeman <andy@lindeman.io>\n> >\n> >Keys generated using `ssh-keygen -t ecdsa` or similar are being rejected\n> >as literal SSH keys because the prefix is `ecdsa-sha2-nistp256`,\n> >`ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`.\n> >\n> >This was acknowledged as an issue [1] in the past, but hasn't yet been\n> >fixed.\n>\n> Hi Andy,\n> thanks for your report. We have decided in the past to not explicitly cater\n> to every key prefix and instead use `key::` for literal keys.\n> See\n> https://git-scm.com/docs/git-config#Documentation/git-config.txt-usersigningKey\n>\n> `For backward compatibility, a raw key which begins with \"ssh-\", such as\n> \"ssh-rsa XXXXXX identifier\", is treated as \"key::ssh-rsa XXXXXX identifier\",\n> but this form is deprecated; use the key:: form instead.`\n\nThanks for replying, Fabian.\n\nMy main issue is that ecdsa-sha2-* keys currently seem incompatible\nwith `gpg.ssh.defaultKeyCommand = \"ssh-add -L\"`\n\nThe git-config documentation of `gpg.ssh.defaultKeyCommand` says:\n\n> To automatically use the first available key from your ssh-agent set this to \"ssh-add -L\".\n\nBut this does not work with ecdsa keys because each line of the output\nof the command is checked against `is_literal_ssh_key`. Because of\nthat check, keys that do not begin with `ssh-` are skipped.\n\nI could certainly write my own shell script for `defaultKeyCommand`\nthat did something like `ssh-add -L | sed 's/^/key::/'` but it's a bit\nawkward.\n\nThe code that runs `defaultKeyCommand` states:\n\n> /*\n> * We only use `is_literal_ssh_key` here to check validity\n> * The prefix will be stripped when the key is used.\n> */\n\nbut this is clearly not true because it is rejecting valid SSH keys.\n\nDo you have thoughts on how to improve `gpg.ssh.defaultKeyCommand` for\nkeys whose prefix is not `ssh-` ?\n"},{"id":"456391","messageId":"20220531144703.jbawf3tkypt7se2i@fs","threadId":"57933","inReplyTo":"CA+vJLfu1WyqP4V44iyZj+Fyr8O7JSB8tSJfOmS1SeSZ65fXh0w@mail.gmail.com","subject":"Re: [PATCH] ssh signing: Support ECDSA as literal SSH keys","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2022-05-31T14:47:03Z","receivedAt":"2022-05-31T14:47:14Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 31.05.2022 09:28, Andy Lindeman wrote:\n>On Tue, May 31, 2022 at 3:34 AM Fabian Stelzer <fs@gigacodes.de> wrote:\n>> On 30.05.2022 17:45, Andy Lindeman via GitGitGadget wrote:\n>> >From: Andy Lindeman <andy@lindeman.io>\n>> >\n>> >Keys generated using `ssh-keygen -t ecdsa` or similar are being rejected\n>> >as literal SSH keys because the prefix is `ecdsa-sha2-nistp256`,\n>> >`ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`.\n>> >\n>> >This was acknowledged as an issue [1] in the past, but hasn't yet been\n>> >fixed.\n>>\n>> Hi Andy,\n>> thanks for your report. We have decided in the past to not explicitly cater\n>> to every key prefix and instead use `key::` for literal keys.\n>> See\n>> https://git-scm.com/docs/git-config#Documentation/git-config.txt-usersigningKey\n>>\n>> `For backward compatibility, a raw key which begins with \"ssh-\", such as\n>> \"ssh-rsa XXXXXX identifier\", is treated as \"key::ssh-rsa XXXXXX identifier\",\n>> but this form is deprecated; use the key:: form instead.`\n>\n>Thanks for replying, Fabian.\n>\n>My main issue is that ecdsa-sha2-* keys currently seem incompatible\n>with `gpg.ssh.defaultKeyCommand = \"ssh-add -L\"`\n>\n>The git-config documentation of `gpg.ssh.defaultKeyCommand` says:\n>\n>> To automatically use the first available key from your ssh-agent set this to \"ssh-add -L\".\n>\n>But this does not work with ecdsa keys because each line of the output\n>of the command is checked against `is_literal_ssh_key`. Because of\n>that check, keys that do not begin with `ssh-` are skipped.\n\nTrue, this is a bug.\n\n>\n>I could certainly write my own shell script for `defaultKeyCommand`\n>that did something like `ssh-add -L | sed 's/^/key::/'` but it's a bit\n>awkward.\n\nI think this is at least a valid workaround for now.\n\n>\n>The code that runs `defaultKeyCommand` states:\n>\n>> /*\n>> * We only use `is_literal_ssh_key` here to check validity\n>> * The prefix will be stripped when the key is used.\n>> */\n>\n>but this is clearly not true because it is rejecting valid SSH keys.\n>\n>Do you have thoughts on how to improve `gpg.ssh.defaultKeyCommand` for\n>keys whose prefix is not `ssh-` ?\n\nThe problem is that we do not want to maintain all ssh keytypes in the git \ncode. Thats why the `key::` was added.\nI'll have to think what we could do besides just skipping the check \ncompletely and just assuming the defaultKeyCommand will return a valid key.\nssh-add -L is not necessarily defined as having a parsable output and any \nadditional messages it might print (or some pkcs11 provider) would at least \nbe skipped with the ssh- prefix check.\n"},{"id":"456435","messageId":"xmqqa6awvp60.fsf@gitster.g","threadId":"57933","inReplyTo":"20220531144703.jbawf3tkypt7se2i@fs","subject":"Re: [PATCH] ssh signing: Support ECDSA as literal SSH keys","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-01T07:05:59Z","receivedAt":"2022-06-01T07:06:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fabian Stelzer <fs@gigacodes.de> writes:\n\n>>Thanks for replying, Fabian.\n>>\n>>My main issue is that ecdsa-sha2-* keys currently seem incompatible\n>>with `gpg.ssh.defaultKeyCommand = \"ssh-add -L\"`\n>>\n>>The git-config documentation of `gpg.ssh.defaultKeyCommand` says:\n>>\n>>> To automatically use the first available key from your ssh-agent set this to \"ssh-add -L\".\n\nThis is puzzling.  One chooses the key to use when signing, and the\nkey should go to the gpg.ssh.defaultkey, and also \"ssh-add\" is told\nabout the key for convenient access.  Asking \"ssh-add -L\" about the\nkeys it knows about and randomly pick the first one it happens to\ntell you about sounds totally backwards to me.\n\nI may have a key I use to sign, and one key each to go to various\ndestinations, all of which \"ssh-add -L\" may know about.  It alone\ncannot fundamentally tell because it does not know what you intend\nto use each key for.\n\nOf course, as your own custom script, defaultKeyCommand may know\nwhich keys you intend to use for connecting and which keys you\nintend to use for signing.  It may even need to know which key you\nintend to use for each project you work with and your .git/config\nmay have something to tell the script what \"trait\" the key to be\nused that appear in \"ssh-add -L\" output should have (perhaps the key\nis rotated very often so you cannot write the exact key in your\nconfiguration, but perhaps the comment at the end of each line have\nsufficient cue to tell them apart).  So, the custom script would\nneed to go line by line to find the key to use in the first place,\nand if it is computationally capable enough to do so, it should be\neasy to prefix key:: in front.  IIRC, we designed the system in such\na way that it is not an error to prefix key:: in front of ssh-* keys.\n\nIn any case, perhaps we should extend the documentation a bit.  It\ngenerally is not sensible to just use \"ssh-add -L\" and pick one\nrandom key out of it, so we shouldn't be encouraging such a use, I\nsuspect.\n\n"},{"id":"456779","messageId":"20220607085226.g6sjcmoiimcvqknx@fs","threadId":"57933","inReplyTo":"xmqqa6awvp60.fsf@gitster.g","subject":"Re: [PATCH] ssh signing: Support ECDSA as literal SSH keys","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2022-06-07T08:52:26Z","receivedAt":"2022-06-07T08:52:42Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"On 01.06.2022 00:05, Junio C Hamano wrote:\n>Fabian Stelzer <fs@gigacodes.de> writes:\n>\n>>>Thanks for replying, Fabian.\n>>>\n>>>My main issue is that ecdsa-sha2-* keys currently seem incompatible\n>>>with `gpg.ssh.defaultKeyCommand = \"ssh-add -L\"`\n>>>\n>>>The git-config documentation of `gpg.ssh.defaultKeyCommand` says:\n>>>\n>>>> To automatically use the first available key from your ssh-agent set this to \"ssh-add -L\".\n>\n>This is puzzling.  One chooses the key to use when signing, and the\n>key should go to the gpg.ssh.defaultkey, and also \"ssh-add\" is told\n>about the key for convenient access.\n\nI think you mean `user.siningKey` but yes, this is the best way to do this.\n\n> Asking \"ssh-add -L\" about the\n>keys it knows about and randomly pick the first one it happens to\n>tell you about sounds totally backwards to me.\n>\n>I may have a key I use to sign, and one key each to go to various\n>destinations, all of which \"ssh-add -L\" may know about.  It alone\n>cannot fundamentally tell because it does not know what you intend\n>to use each key for.\n>\n>Of course, as your own custom script, defaultKeyCommand may know\n>which keys you intend to use for connecting and which keys you\n>intend to use for signing.  It may even need to know which key you\n>intend to use for each project you work with and your .git/config\n>may have something to tell the script what \"trait\" the key to be\n>used that appear in \"ssh-add -L\" output should have (perhaps the key\n>is rotated very often so you cannot write the exact key in your\n>configuration, but perhaps the comment at the end of each line have\n>sufficient cue to tell them apart).  So, the custom script would\n>need to go line by line to find the key to use in the first place,\n>and if it is computationally capable enough to do so, it should be\n>easy to prefix key:: in front.  IIRC, we designed the system in such\n>a way that it is not an error to prefix key:: in front of ssh-* keys.\n>\n>In any case, perhaps we should extend the documentation a bit.  It\n>generally is not sensible to just use \"ssh-add -L\" and pick one\n>random key out of it, so we shouldn't be encouraging such a use, I\n>suspect.\n\nYes, I think that reasonable. The script can do some advanced decision \nmaking / key lookup if needed. The use-case for me was to enforce/encourage \nuse of the correct users keys on a shared development server in a corporate \nenvironment (i have a global directory of all the users keys and want to \nmake sure everyone uses their correct one when signing).\n\nI'll take a look at the docs and suggest a patch in a bit.\n\n"},{"id":"456798","messageId":"xmqqtu8wxue8.fsf@gitster.g","threadId":"57933","inReplyTo":"20220607085226.g6sjcmoiimcvqknx@fs","subject":"Re: [PATCH] ssh signing: Support ECDSA as literal SSH keys","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-07T17:20:31Z","receivedAt":"2022-06-07T17:20:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fabian Stelzer <fs@gigacodes.de> writes:\n\n> On 01.06.2022 00:05, Junio C Hamano wrote:\n>>Fabian Stelzer <fs@gigacodes.de> writes:\n>>\n>>>>Thanks for replying, Fabian.\n>>>>\n>>>>My main issue is that ecdsa-sha2-* keys currently seem incompatible\n>>>>with `gpg.ssh.defaultKeyCommand = \"ssh-add -L\"`\n>>>>\n>>>>The git-config documentation of `gpg.ssh.defaultKeyCommand` says:\n>>>>\n>>>>> To automatically use the first available key from your ssh-agent set this to \"ssh-add -L\".\n>>\n>>This is puzzling.  One chooses the key to use when signing, and the\n>>key should go to the gpg.ssh.defaultkey, and also \"ssh-add\" is told\n>>about the key for convenient access.\n>\n> I think you mean `user.siningKey` but yes, this is the best way to do this.\n\nThanks for seeing my intention through my mistake.\n\n>> Asking \"ssh-add -L\" about the\n>>keys it knows about and randomly pick the first one it happens to\n>>tell you about sounds totally backwards to me.\n>>\n>>I may have a key I use to sign, and one key each to go to various\n>>destinations, all of which \"ssh-add -L\" may know about.  It alone\n>>cannot fundamentally tell because it does not know what you intend\n>>to use each key for.\n>> ...\n>>In any case, perhaps we should extend the documentation a bit.  It\n>>generally is not sensible to just use \"ssh-add -L\" and pick one\n>>random key out of it, so we shouldn't be encouraging such a use, I\n>>suspect.\n>\n> Yes, I think that reasonable. The script can do some advanced decision\n> making / key lookup if needed.\n\nOK.\n\n> The use-case for me was to enforce/encourage use of the correct\n> users keys on a shared development server in a corporate\n> environment (i have a global directory of all the users keys and\n> want to make sure everyone uses their correct one when signing).\n\nI actually wanted to hear more about the reasoning along that line.\n\nIOW, \"sure, theoretically, you should start from 'this is the key I\nwant to use' and you shouldn't be asking 'ssh-add -L' about it, but\nhere is a real-world workflow that makes it cumbersome\" was what I\nwanted to see, both in the discussion *and* in the documentation\nupdate.\n\nFor example, there may be corporate environment where key is\nfrequently rotated, e.g. every morning an employee may have to \"corp\nlogin\" to talk to a central key server and get the ssh key stored in\ntheir hardware token refreshed.  In such an environment, it would\nnot be surprising if the employee does not even know what the\nfingerprint or the public part of the key looks like before asking\n'ssh-add -L' to query the hardware token, so it may be impractical\nto follow the \"set your key to user.signingKey and add that to the\nagent\".  Asking the agent about the key may make perfect sense (but\nyou'd probably need to find which key among its output lines) in\nsuch a case.\n\n\n\n\n\n"},{"id":"456866","messageId":"20220608152437.126276-1-fs@gigacodes.de","threadId":"57933","inReplyTo":"xmqqa6awvp60.fsf@gitster.g","subject":"[PATCH] gpg docs: explain better use of ssh.defaultKeyCommand","fromName":"Fabian Stelzer","fromEmail":"fs@gigacodes.de","sentAt":"2022-06-08T15:24:37Z","receivedAt":"2022-06-08T15:30:56Z","isPatch":true,"sender":{"key":"fs@gigacodes.de","avatar":"https://avatars.githubusercontent.com/u/564858?v=4"},"body":"Using `ssh-add -L` for gpg.ssh.defaultKeyCommand is not a good\nrecommendation. It might switch keys depending on the order of known\nkeys and it only supports ssh-* and no ecdsa or other keys.\nClarify that we expect a literal key prefixed by `key::`, give valid\nexample use cases and refer to `user.signingKey` as the preferred\noption.\n\nSigned-off-by: Fabian Stelzer <fs@gigacodes.de>\n---\n Documentation/config/gpg.txt | 9 ++++++---\n 1 file changed, 6 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt\nindex 86892ada77..86f6308c4c 100644\n--- a/Documentation/config/gpg.txt\n+++ b/Documentation/config/gpg.txt\n@@ -36,9 +36,12 @@ gpg.minTrustLevel::\n \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 first line of its output. To automatically use the first\n-\tavailable key from your ssh-agent set this to \"ssh-add -L\".\n+\tsignature is requested. On successful exit a valid ssh public key\n+\tprefixed with `key::` is expected in the first line of its output.\n+\tThis allows for a script doing a dynamic lookup of the correct public\n+\tkey when it is impractical to statically configure `user.signingKey`.\n+\tFor example when keys or SSH Certificates are rotated frequently or\n+\tselection of the right key depends on external factors unknown to git.\n \n gpg.ssh.allowedSignersFile::\n \tA file containing ssh public keys which you are willing to trust.\n-- \n2.35.3\n\n"},{"id":"457094","messageId":"CA+vJLftKhkuVp3b6Tk4WezeCWpYq2Tdy9vRtjxdopbgV94ZsxQ@mail.gmail.com","threadId":"57933","inReplyTo":"20220608152437.126276-1-fs@gigacodes.de","subject":"Re: [PATCH] gpg docs: explain better use of ssh.defaultKeyCommand","fromName":"Andy Lindeman","fromEmail":"andy@lindeman.io","sentAt":"2022-06-13T01:13:32Z","receivedAt":"2022-06-13T01:15:17Z","isPatch":true,"sender":{"key":"andy@lindeman.io","avatar":"https://gravatar.com/avatar/271232963028fcde203abe47abb859d4997adfa8686032ef2dd387317405cf1a?d=mp&s=160"},"body":"On Wed, Jun 8, 2022 at 11:24 AM Fabian Stelzer <fs@gigacodes.de> wrote:\n>\n> Using `ssh-add -L` for gpg.ssh.defaultKeyCommand is not a good\n> recommendation. It might switch keys depending on the order of known\n> keys and it only supports ssh-* and no ecdsa or other keys.\n> Clarify that we expect a literal key prefixed by `key::`, give valid\n> example use cases and refer to `user.signingKey` as the preferred\n> option.\n>\n> Signed-off-by: Fabian Stelzer <fs@gigacodes.de>\n> ---\n>  Documentation/config/gpg.txt | 9 ++++++---\n>  1 file changed, 6 insertions(+), 3 deletions(-)\n>\n> diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt\n> index 86892ada77..86f6308c4c 100644\n> --- a/Documentation/config/gpg.txt\n> +++ b/Documentation/config/gpg.txt\n> @@ -36,9 +36,12 @@ gpg.minTrustLevel::\n>\n>  gpg.ssh.defaultKeyCommand::\n>         This command that will be run when user.signingkey is not set and a ssh\n> -       signature is requested. On successful exit a valid ssh public key is\n> -       expected in the first line of its output. To automatically use the first\n> -       available key from your ssh-agent set this to \"ssh-add -L\".\n> +       signature is requested. On successful exit a valid ssh public key\n> +       prefixed with `key::` is expected in the first line of its output.\n> +       This allows for a script doing a dynamic lookup of the correct public\n> +       key when it is impractical to statically configure `user.signingKey`.\n> +       For example when keys or SSH Certificates are rotated frequently or\n> +       selection of the right key depends on external factors unknown to git.\n>\n>  gpg.ssh.allowedSignersFile::\n>         A file containing ssh public keys which you are willing to trust.\n> --\n> 2.35.3\n>\n\nNice. This makes sense to me.\n"}]}