{"thread":{"id":"61051","subject":"[PATCH] gpg-interface: Look up signing keys with only email address","startedAt":"2024-03-05T02:18:01Z","lastAt":"2024-03-05T07:54:14Z","messageCount":3,"participants":["Marco Sirabella","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"489938","messageId":"20240305020815.2980-1-marco@sirabella.org","threadId":"61051","inReplyTo":null,"subject":"[PATCH] gpg-interface: Look up signing keys with only email address","fromName":"Marco Sirabella","fromEmail":"marco@sirabella.org","sentAt":"2024-03-05T02:08:15Z","receivedAt":"2024-03-05T02:18:01Z","isPatch":true,"sender":{"key":"marco@sirabella.org","avatar":"https://gravatar.com/avatar/7631f17688dcadb421a7b8973b3a2dae999701f22d238ae3cbc0b80e17d4c6d1?d=mp&s=160"},"body":"Sometimes gpg signing key UIDs include a comment between the name and\nparenthesis in the form of:\n\n  John Smith (example) jsmith@example.com\n\nThere's no way for git to find signing keys associated with just these\nUIDs, so look up a partial match on the email only.\n\nSigned-off-by: Marco Sirabella <marco@sirabella.org>\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 95e764acb1..3c303e05bd 100644\n--- a/gpg-interface.c\n+++ b/gpg-interface.c\n@@ -922,7 +922,7 @@ const char *get_signing_key(void)\n \t\treturn use_format->get_default_key();\n \t}\n \n-\treturn git_committer_info(IDENT_STRICT | IDENT_NO_DATE);\n+\treturn git_committer_info(IDENT_NO_NAME | IDENT_STRICT | IDENT_NO_DATE);\n }\n \n const char *gpg_trust_level_to_str(enum signature_trust_level level)\n-- \n2.43.0\n\n"},{"id":"489941","messageId":"xmqqy1ax5k5w.fsf@gitster.g","threadId":"61051","inReplyTo":"20240305020815.2980-1-marco@sirabella.org","subject":"Re: [PATCH] gpg-interface: Look up signing keys with only email address","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-05T05:20:43Z","receivedAt":"2024-03-05T05:20:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marco Sirabella <marco@sirabella.org> writes:\n\n> Sometimes gpg signing key UIDs include a comment between the name and\n> parenthesis in the form of:\n>\n>   John Smith (example) jsmith@example.com\n>\n> There's no way for git to find signing keys associated with just these\n> UIDs, so look up a partial match on the email only.\n\nThis codepath is about finding the key for the current user who is\nin control of what committer is found by the git_committer_info()\ncall, no?  It is not like we are finding the key that corresponds to\na random name and e-mail address on \"From:\" line, right?\n\nAssuming that it is the case, it is unclear where the claim \"There's\nno way for git to find\" comes from.  It isn't a statement that is so\nobviously true, at least to me, without some explanation.\n\n> -\treturn git_committer_info(IDENT_STRICT | IDENT_NO_DATE);\n> +\treturn git_committer_info(IDENT_NO_NAME | IDENT_STRICT | IDENT_NO_DATE);\n\nWith this change, those who use more than one identities associated\nwith the same e-mail address, but different human-readable names,\nwill get their workflow broken, won't they?\n\nThey may be using \"Will <a@dd.re.ss>\" when they work on a project,\nwhile using \"Bill <a@dd.re.ss>\" for another project, configured via\ntheir .git/config in the repositories used for these two projects.\nAnd each name+address combination they have may map to a distinct\nGPG key, used to sign for each project.  With this change, since the\ncall no longer returns the name they were using to differentiate the\ntwo keys, one of the projects they manage would lose out, no?\n\nIn general, there may be more than one signing keys that correspond\nto a given human user, and the user may choose a specific key based\non what project the signatures are made for, and in such a case,\nwith or without the proposed change, the fallback code based on the\ngit_committer_info() is an unreliable way to specify the key to be\nused, especially for an action as important as cryptographic\nsigning.  I have always assumed that people use something like this\nin practice:\n\n    $ git config user.signingkey = 955980DA!\n\nthat can be used to more reliably identify a specific key in their\nkeyring, among the ones associated with similar identifiers meant\nfor human consumption such as name/e-mail pairs.\n\nSo, I am not convinced that the patch is trying to address the right\nproblem, and I have a mild suspicion that the proposed solution to\ntweak NO_NAME may simply be robbing Peter to pay Paul.  If you have\nnamed your GPG key in your keyring with a name-email pair that is\ndifferent from how you configured your committer identity, the right\nsolution for such a case already exists in the form of user.signingkey\nconfiguration variable already.\n\nThanks.\n"},{"id":"489943","messageId":"20240305075339.tpmaa4xobng7zvbz@Ne0Ridl3y","threadId":"61051","inReplyTo":"xmqqy1ax5k5w.fsf@gitster.g","subject":"Re: [PATCH] gpg-interface: Look up signing keys with only email address","fromName":"Marco Sirabella","fromEmail":"marco@sirabella.org","sentAt":"2024-03-05T07:53:39Z","receivedAt":"2024-03-05T07:54:14Z","isPatch":true,"sender":{"key":"marco@sirabella.org","avatar":"https://gravatar.com/avatar/7631f17688dcadb421a7b8973b3a2dae999701f22d238ae3cbc0b80e17d4c6d1?d=mp&s=160"},"body":"> > Sometimes gpg signing key UIDs include a comment between the name and\n> > parenthesis in the form of:\n> >\n> >   John Smith (example) jsmith@example.com\n> >\n> > There's no way for git to find signing keys associated with just these\n> > UIDs, so look up a partial match on the email only.\n> \n> This codepath is about finding the key for the current user who is\n> in control of what committer is found by the git_committer_info()\n> call, no?  It is not like we are finding the key that corresponds to\n> a random name and e-mail address on \"From:\" line, right?\n> \n> Assuming that it is the case, it is unclear where the claim \"There's\n> no way for git to find\" comes from.  It isn't a statement that is so\n> obviously true, at least to me, without some explanation.\n\nHi, yeah. This statement was in referral to specifically gpg UIDs with\ncomments, the parenthetical that finds itself between the full name &\nemail. \n\nA workaround could be to set the committer name to \"Full Name (comment)\"\nbut that would end up being embedded in the git committer info too.\n\n> > -\treturn git_committer_info(IDENT_STRICT | IDENT_NO_DATE);\n> > +\treturn git_committer_info(IDENT_NO_NAME | IDENT_STRICT | IDENT_NO_DATE);\n> \n> With this change, those who use more than one identities associated\n> with the same e-mail address, but different human-readable names,\n> will get their workflow broken, won't they?\n> \n> They may be using \"Will <a@dd.re.ss>\" when they work on a project,\n> while using \"Bill <a@dd.re.ss>\" for another project, configured via\n> their .git/config in the repositories used for these two projects.\n> And each name+address combination they have may map to a distinct\n> GPG key, used to sign for each project.  With this change, since the\n> call no longer returns the name they were using to differentiate the\n> two keys, one of the projects they manage would lose out, no?\n\nThis is true, yes. This is a backwards incompatible change and if you\nthink there's a reasonable / used use case for multiple GPG keys with\nthe same emails but different names then yeah, this commit breaks that\nworkflow.\n\nBut also as you've mentioned user.signingkey is a very easy workaround\nto resolve this.\n\n> So, I am not convinced that the patch is trying to address the right\n> problem, and I have a mild suspicion that the proposed solution to\n> tweak NO_NAME may simply be robbing Peter to pay Paul.  If you have\n> named your GPG key in your keyring with a name-email pair that is\n> different from how you configured your committer identity, the right\n> solution for such a case already exists in the form of user.signingkey\n> configuration variable already.\n\nI currently have a GPG key in my keyring with an identical name-email\npair to my git committer info, but it has an *additional* gpg UID\ncomment that introdues text within parenthesis that falls between the\nowner full name & email and results in git's key lookup not working.\n\nI appreciate the swift response!\n\n-- \nMarco Sirabella\n"}]}