{"thread":{"id":"23652","subject":"PATCH: Less fragile lookup of gpg key","startedAt":"2010-05-01T15:16:59Z","lastAt":"2010-05-04T06:07:23Z","messageCount":13,"participants":["Grant Olson","A Large Angry SCM","Junio C Hamano","Greg A. Woods","Theodore Tso","tytso@mit.edu","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140679","messageId":"4BDC45EB.8090305@grant-olson.net","threadId":"23652","inReplyTo":null,"subject":"PATCH: Less fragile lookup of gpg key","fromName":"Grant Olson","fromEmail":"kgo@grant-olson.net","sentAt":"2010-05-01T15:16:59Z","receivedAt":"2010-05-01T15:16:59Z","isPatch":false,"sender":{"key":"kgo@grant-olson.net","avatar":"https://gravatar.com/avatar/401c976b3d10d0c43c14d6643336b174d76a5ecec3056e5c22b1f81390853005?d=mp&s=160"},"body":"When signing a tag, git will attempt to lookup your gpg key if you don't\nprovide the key id.  Right now, it's a little fragile.  My gpg key uid\nis \"Grant T. Olson (Personal Email) <kgo@grant-olson.net>\".  My git user\ninfo is \"Grant T. Olson <kgo@grant-olson.net>\".  Things don't match\nbecause git doesn't have the comment.\n\nHowever, if I lookup just by email, things work perfectly.\n\nI think doing this would make life much easier for new users, and in the\ncase that someone has an OpenPGP key without email (e.g. Ubuntu Master\nSigning Key) we can safely assume they're an expert and will either add\nthe key id to their configuration or use -u instead of -s.\n\nHere's a patch that will try to lookup the user by email only if no\nsigning key is provided.  If there is no email, it will still fall back\nto the default generated by git.\n\nFrom d0fcf1340495045813758f910e8f4d745e28546b Mon Sep 17 00:00:00 2001\nFrom: Grant Olson <kgo@grant-olson.net>\nDate: Sat, 1 May 2010 11:02:18 -0400\nSubject: [PATCH] Lookup gpg key by email\n\n---\n builtin/tag.c |    2 +-\n ident.c       |    9 +++++++++\n 2 files changed, 10 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/tag.c b/builtin/tag.c\nindex d311491..4eb3cc5 100644\n--- a/builtin/tag.c\n+++ b/builtin/tag.c\n@@ -165,7 +165,7 @@ static int do_sign(struct strbuf *buffer)\n \tint i, j;\n\n \tif (!*signingkey) {\n-\t\tif (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),\n+\t\tif (strlcpy(signingkey, git_committer_email(),\n \t\t\t\tsizeof(signingkey)) > sizeof(signingkey) - 1)\n \t\t\treturn error(\"committer info too long.\");\n \t\tbracket = strchr(signingkey, '>');\ndiff --git a/ident.c b/ident.c\nindex 9e24388..0e8b78a 100644\n--- a/ident.c\n+++ b/ident.c\n@@ -260,6 +260,15 @@ const char *git_committer_info(int flag)\n \t\t\t flag);\n }\n\n+const char *git_committer_email(void)\n+{\n+\tconst char *email = getenv(\"GIT_COMMITTER_EMAIL\");\n+\tif(!email)\n+\t\temail = git_default_email;\n+\n+\treturn email;\n+}\n+\n int user_ident_sufficiently_given(void)\n {\n #ifndef WINDOWS\n-- \n1.7.0.4\n\n\n"},{"id":"140681","messageId":"4BDC561B.4030307@gmail.com","threadId":"23652","inReplyTo":"4BDC45EB.8090305@grant-olson.net","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2010-05-01T16:26:03Z","receivedAt":"2010-05-01T16:26:03Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Grant Olson wrote:\n> When signing a tag, git will attempt to lookup your gpg key if you don't\n> provide the key id.  Right now, it's a little fragile.  My gpg key uid\n> is \"Grant T. Olson (Personal Email) <kgo@grant-olson.net>\".  My git user\n> info is \"Grant T. Olson <kgo@grant-olson.net>\".  Things don't match\n> because git doesn't have the comment.\n> \n> However, if I lookup just by email, things work perfectly.\n> \n> I think doing this would make life much easier for new users, and in the\n> case that someone has an OpenPGP key without email (e.g. Ubuntu Master\n> Signing Key) we can safely assume they're an expert and will either add\n> the key id to their configuration or use -u instead of -s.\n> \n> Here's a patch that will try to lookup the user by email only if no\n> signing key is provided.  If there is no email, it will still fall back\n> to the default generated by git.\n\nWhy not fall back to just the email if the full lookup fails?\n"},{"id":"140692","messageId":"7vhbmr5ym4.fsf@alter.siamese.dyndns.org","threadId":"23652","inReplyTo":"4BDC561B.4030307@gmail.com","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-01T17:18:59Z","receivedAt":"2010-05-01T17:18:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A Large Angry SCM <gitzilla@gmail.com> writes:\n\n> Grant Olson wrote:\n>> When signing a tag, git will attempt to lookup your gpg key if you don't\n>> provide the key id.  Right now, it's a little fragile.  My gpg key uid\n>> is \"Grant T. Olson (Personal Email) <kgo@grant-olson.net>\".  My git user\n>> info is \"Grant T. Olson <kgo@grant-olson.net>\".  Things don't match\n>> because git doesn't have the comment.\n>>\n>> However, if I lookup just by email, things work perfectly.\n>>\n>> I think doing this would make life much easier for new users, and in the\n>> case that someone has an OpenPGP key without email (e.g. Ubuntu Master\n>> Signing Key) we can safely assume they're an expert and will either add\n>> the key id to their configuration or use -u instead of -s.\n>>\n>> Here's a patch that will try to lookup the user by email only if no\n>> signing key is provided.  If there is no email, it will still fall back\n>> to the default generated by git.\n>\n> Why not fall back to just the email if the full lookup fails?\n\nThanks; I like that suggestion a lot better.  Grant's suggestion does not\nmake the lookup \"less fragile\", but actually makes it less reliable for\npeople with the same address with different spellings of name and want to\nchoose which one to use per project.\n"},{"id":"140695","messageId":"4BDC63FB.7060202@grant-olson.net","threadId":"23652","inReplyTo":"7vhbmr5ym4.fsf@alter.siamese.dyndns.org","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Grant Olson","fromEmail":"kgo@grant-olson.net","sentAt":"2010-05-01T17:25:15Z","receivedAt":"2010-05-01T17:25:15Z","isPatch":false,"sender":{"key":"kgo@grant-olson.net","avatar":"https://gravatar.com/avatar/401c976b3d10d0c43c14d6643336b174d76a5ecec3056e5c22b1f81390853005?d=mp&s=160"},"body":"On 5/1/2010 1:18 PM, Junio C Hamano wrote:\n> A Large Angry SCM <gitzilla@gmail.com> writes:\n>>\n>> Why not fall back to just the email if the full lookup fails?\n> \n> Thanks; I like that suggestion a lot better.  Grant's suggestion does not\n> make the lookup \"less fragile\", but actually makes it less reliable for\n> people with the same address with different spellings of name and want to\n> choose which one to use per project.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\nUnless I'm mis-understanding you, the does the opposite of that.  It\nfinds your gpg key based on your git email, ignoring your git name, so\nthat different spellings of the name between gpg and git become irrelevant.\n\n-- \nGrant\n\n\"Can you construct some sort of rudimentary lathe?\"\n\n"},{"id":"140710","messageId":"7v7hnn4cun.fsf@alter.siamese.dyndns.org","threadId":"23652","inReplyTo":"4BDC63FB.7060202@grant-olson.net","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-01T19:54:24Z","receivedAt":"2010-05-01T19:54:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Grant Olson <kgo@grant-olson.net> writes:\n\n> On 5/1/2010 1:18 PM, Junio C Hamano wrote:\n>> A Large Angry SCM <gitzilla@gmail.com> writes:\n>>>\n>>> Why not fall back to just the email if the full lookup fails?\n>> \n>> Thanks; I like that suggestion a lot better.  Grant's suggestion does not\n>> make the lookup \"less fragile\", but actually makes it less reliable for\n>> people with the same address with different spellings of name and want to\n>> choose which one to use per project.\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n> Unless I'm mis-understanding you, the does the opposite of that.  It\n> finds your gpg key based on your git email, ignoring your git name, so\n> that different spellings of the name between gpg and git become irrelevant.\n\nIf I have two keys like these:\n\n    Junio C Hamano <gitster@pobox.com>\n    Junio Hamano <gitster@pobox.com>\n\nand I have the latter set in .git/config to use for the project I am\nworking on, your patch picks one at random, making the process less\nreliable.\n\nAFAIU, ALASCM's suggestion was to first try the current method (which\nreliably picks what I told git to use by specifying user.name), and only\nif that fails, i.e. if I do not have neither of the above two keys but\nonly have a key named like e.g.\n\n    Git Panda <gitster@pobox.com>\n\nthen use only the e-mail as you wanted to, but do so purely as a\nfallback.\n\nWhich I found quite reasonable.\n"},{"id":"140801","messageId":"4BDE0D48.9060109@grant-olson.net","threadId":"23652","inReplyTo":"7v7hnn4cun.fsf@alter.siamese.dyndns.org","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Grant Olson","fromEmail":"kgo@grant-olson.net","sentAt":"2010-05-02T23:39:52Z","receivedAt":"2010-05-02T23:39:52Z","isPatch":false,"sender":{"key":"kgo@grant-olson.net","avatar":"https://gravatar.com/avatar/401c976b3d10d0c43c14d6643336b174d76a5ecec3056e5c22b1f81390853005?d=mp&s=160"},"body":"On 05/01/2010 03:54 PM, Junio C Hamano wrote:\n> Grant Olson <kgo@grant-olson.net> writes:\n>>\n>> Unless I'm mis-understanding you, the does the opposite of that.  It\n>> finds your gpg key based on your git email, ignoring your git name, so\n>> that different spellings of the name between gpg and git become irrelevant.\n> \n> If I have two keys like these:\n> \n>     Junio C Hamano <gitster@pobox.com>\n>     Junio Hamano <gitster@pobox.com>\n> \n> and I have the latter set in .git/config to use for the project I am\n> working on, your patch picks one at random, making the process less\n> reliable.\n> \n> AFAIU, ALASCM's suggestion was to first try the current method (which\n> reliably picks what I told git to use by specifying user.name), and only\n> if that fails, i.e. if I do not have neither of the above two keys but\n> only have a key named like e.g.\n> \n>     Git Panda <gitster@pobox.com>\n> \n> then use only the e-mail as you wanted to, but do so purely as a\n> fallback.\n> \n> Which I found quite reasonable.\n\nFair enough.  This version of the patch will try to gpg sign by email\naddress only, if (and only if) you try to sign a tag without explicitly\nproviding a key id (-s) and the lookup by \"user.name <user.email>\" fails.\n\nFrom 791a110dc4d362b2cd11b19ae25a86bf91710e34 Mon Sep 17 00:00:00 2001\nFrom: Grant Olson <kgo@grant-olson.net>\nDate: Sun, 2 May 2010 19:33:41 -0400\nSubject: [PATCH] Lookup gpg key by email address if user+email lookup\nfails with -s\n\n---\n builtin/tag.c |   67\n+++++++++++++++++++++++++++++++++++++++++++++------------\n cache.h       |    1 +\n ident.c       |    9 +++++++\n 3 files changed, 63 insertions(+), 14 deletions(-)\n\ndiff --git a/builtin/tag.c b/builtin/tag.c\nindex d311491..45dd43d 100644\n--- a/builtin/tag.c\n+++ b/builtin/tag.c\n@@ -156,22 +156,13 @@ static int verify_tag(const char *name, const char\n*ref,\n \treturn 0;\n }\n\n-static int do_sign(struct strbuf *buffer)\n+static int do_gpg(struct strbuf *buffer)\n {\n+\t/* retval can be standard -1 for error, 0 for ok, or 1 for a warning\n+\t * so that we can attempt to recover by running gpg again. */\n \tstruct child_process gpg;\n \tconst char *args[4];\n-\tchar *bracket;\n \tint len;\n-\tint i, j;\n-\n-\tif (!*signingkey) {\n-\t\tif (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),\n-\t\t\t\tsizeof(signingkey)) > sizeof(signingkey) - 1)\n-\t\t\treturn error(\"committer info too long.\");\n-\t\tbracket = strchr(signingkey, '>');\n-\t\tif (bracket)\n-\t\t\tbracket[1] = '\\0';\n-\t}\n\n \t/* When the username signingkey is bad, program could be terminated\n \t * because gpg exits without reading and then write gets SIGPIPE. */\n@@ -199,8 +190,56 @@ static int do_sign(struct strbuf *buffer)\n \tlen = strbuf_read(buffer, gpg.out, 1024);\n \tclose(gpg.out);\n\n-\tif (finish_command(&gpg) || !len || len < 0)\n-\t\treturn error(\"gpg failed to sign the tag\");\n+\tif(finish_command(&gpg))\n+\t\t{\n+\t\t\twarning(\"gpg failed to sign the tag\");\n+\t\t\treturn 1;\n+\t\t}\n+\n+\treturn 0;\n+}\n+\n+static int do_sign(struct strbuf *buffer)\n+{\n+\tchar *bracket;\n+\tint i, j;\n+\tint uid_for_key = 0;\n+\tint err_ok_warning;\n+\n+\tif (!*signingkey) {\n+\t\tif (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),\n+\t\t\t\tsizeof(signingkey)) > sizeof(signingkey) - 1)\n+\t\t\treturn error(\"committer info too long.\");\n+\t\tbracket = strchr(signingkey, '>');\n+\t\tif (bracket)\n+\t\t\tbracket[1] = '\\0';\n+\t\tuid_for_key = 1;\n+\t}\n+\n+\terr_ok_warning = do_gpg(buffer);\n+\n+\tif(!err_ok_warning || err_ok_warning != 1)\n+\t\treturn -1;\n+\n+\tif (err_ok_warning == 1 || !buffer->len || buffer->len < 0)\n+\t{\n+\t\tif (uid_for_key)\n+\t\t{\n+\t\t\twarning(\"couldn't find key for '%s'...\", signingkey);\n+\t\t\twarning(\"Trying key lookup by email address only.\");\n+\n+\t\t\tif (strlcpy(signingkey, git_committer_email(),\n+\t\t\t\tsizeof(signingkey)) > sizeof(signingkey) - 1)\n+\t\t\t\t\treturn error(\"committer info too long.\");\n+\n+\t\t\t\terr_ok_warning = do_gpg(buffer);\n+\n+\t\t\tif (err_ok_warning || !buffer->len || buffer-> len < 0)\n+\t\t\t\treturn error(\"gpg failed to sign the tag\");\n+\t\t} else {\n+\t\t\treturn error(\"gpg failed to sign the tag\");\n+\t\t}\n+\t}\n\n \t/* Strip CR from the line endings, in case we are on Windows. */\n \tfor (i = j = 0; i < buffer->len; i++)\ndiff --git a/cache.h b/cache.h\nindex 5eb0573..90a3067 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -789,6 +789,7 @@ enum date_mode parse_date_format(const char *format);\n #define IDENT_NO_DATE\t       4\n extern const char *git_author_info(int);\n extern const char *git_committer_info(int);\n+extern const char *git_committer_email();\n extern const char *fmt_ident(const char *name, const char *email, const\nchar *date_str, int);\n extern const char *fmt_name(const char *name, const char *email);\n extern const char *git_editor(void);\ndiff --git a/ident.c b/ident.c\nindex 9e24388..0e8b78a 100644\n--- a/ident.c\n+++ b/ident.c\n@@ -260,6 +260,15 @@ const char *git_committer_info(int flag)\n \t\t\t flag);\n }\n\n+const char *git_committer_email(void)\n+{\n+\tconst char *email = getenv(\"GIT_COMMITTER_EMAIL\");\n+\tif(!email)\n+\t\temail = git_default_email;\n+\n+\treturn email;\n+}\n+\n int user_ident_sufficiently_given(void)\n {\n #ifndef WINDOWS\n-- \n1.7.0.4\n\n"},{"id":"140803","messageId":"m1O8k0Z-000kndC@most.weird.com","threadId":"23652","inReplyTo":"7v7hnn4cun.fsf@alter.siamese.dyndns.org","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Greg A. Woods","fromEmail":"woods@planix.com","sentAt":"2010-05-03T00:59:34Z","receivedAt":"2010-05-03T00:59:34Z","isPatch":false,"sender":{"key":"woods@planix.com","avatar":null},"body":"At Sat, 01 May 2010 12:54:24 -0700, Junio C Hamano <gitster@pobox.com> wrote:\nSubject: Re: PATCH:  Less fragile lookup of gpg key\n> \n> If I have two keys like these:\n> \n>     Junio C Hamano <gitster@pobox.com>\n>     Junio Hamano <gitster@pobox.com>\n\nI'm not an expert on PGP internals or such, but I think that's a really\nbad thing to do.  I'm surprised you were able to get gpg to do it in the\nfirst place.  I would have hoped it wouldn't allow it.  As far as I can\ntell it's _not_ compatible with other implementations of PGP.\n\nPGP keys normally are searched by the e-mail portion only.  All the\nother stuff (comments and the display name, etc.) is for decoration\nonly.  This is just as it is in e-mail routing too of course.\n\nYou can of course have more than one e-mail address per key, but you\nshould NEVER have more than one key per e-mail.\n\nI.e. it's less reliable in the first place to have two different keys\nwhich can be found using the same e-mail address.\n\n-- \n\t\t\t\t\t\tGreg A. Woods\n\t\t\t\t\t\tPlanix, Inc.\n\n<woods@planix.com>       +1 416 218 0099        http://www.planix.com/\n"},{"id":"140808","messageId":"4BDE3055.9010602@grant-olson.net","threadId":"23652","inReplyTo":"m1O8k0Z-000kndC@most.weird.com","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Grant Olson","fromEmail":"kgo@grant-olson.net","sentAt":"2010-05-03T02:09:25Z","receivedAt":"2010-05-03T02:09:25Z","isPatch":false,"sender":{"key":"kgo@grant-olson.net","avatar":"https://gravatar.com/avatar/401c976b3d10d0c43c14d6643336b174d76a5ecec3056e5c22b1f81390853005?d=mp&s=160"},"body":"On 5/2/2010 8:59 PM, Greg A. Woods wrote:\n> At Sat, 01 May 2010 12:54:24 -0700, Junio C Hamano <gitster@pobox.com> wrote:\n> Subject: Re: PATCH:  Less fragile lookup of gpg key\n>>\n>> If I have two keys like these:\n>>\n>>     Junio C Hamano <gitster@pobox.com>\n>>     Junio Hamano <gitster@pobox.com>\n> \n> I'm not an expert on PGP internals or such, but I think that's a really\n> bad thing to do.  I'm surprised you were able to get gpg to do it in the\n> first place.  I would have hoped it wouldn't allow it.  As far as I can\n> tell it's _not_ compatible with other implementations of PGP.\n> \n> PGP keys normally are searched by the e-mail portion only.  All the\n> other stuff (comments and the display name, etc.) is for decoration\n> only.  This is just as it is in e-mail routing too of course.\n> \n> You can of course have more than one e-mail address per key, but you\n> should NEVER have more than one key per e-mail.\n> \n> I.e. it's less reliable in the first place to have two different keys\n> which can be found using the same e-mail address.\n> \n\nThis might be getting a little off-topic for the git list, but...\n\nIt's a weird thing to do, which is why I didn't account for it in the\noriginal patch, but the RFC doesn't have any specific requirements\nregarding what a UID is:\n\n5.11. User ID Packet (Tag 13)\n\n   A User ID packet consists of UTF-8 text that is intended to represent\n   the name and email address of the key holder.  By convention, it\n   includes an RFC 2822 [RFC2822] mail name-addr, but there are no\n   restrictions on its content.  The packet length in the header\n   specifies the length of the User ID.\n\nUltimately the key ID is the unique identifier, so there's nothing\ntechnically wrong with creating multiple keys with the same email.  It\nwill cause some email clients to flip out, but that's a non-issue with\ngit tags.\n\nBut if someone is a regular user of OpenPGP, and they get two signatures\nfrom the same email address with different keys, the assumption is going\nto be that at least one of them is a forgery.  Maybe the keys are\ncross-signed if, for example, someone is phasing out an old 1024-bit key\nwith a new 2048-bit one.  But that's still going to raise a few\neyebrows.  And even in that case, you still probably want to sign\neverything with the same key.\n\nIf you look at any day-to-day usage of gpg, or examples posted around,\nthey're almost always going to just pass an email address only with the\n-u flag, if they use the -u flag at all.  I don't think you're going to\nfind any examples or tutorials that suggest you type:\n\ngpg -u \"Junio Hamano <gitster@pobox.com>\" --armor --sign file.txt\n\nthey'll all use:\n\ngpg -u gitster@pobox.com --armor --sign file.txt\n\nAnd normally a user wouldn't even use the -u flag to begin with.  They\nwould just go with the default secret key on your keyring.  But that\nmight have a different email address than your git settings, so it does\nmake sense to use -u within git.\n\nI personally think that using multiple keys with the same UID falls into\nthe 'advanced user' category, where you can expect the advanced user to\nfigure out how to deal with the exceptional usage, and have the defaults\nset out to cover the general case.\n\nBut all that being said, I don't have a problem with the proposed\nsolution of falling back to a straight email search after the username +\nemail search fails.\n\n-- \nGrant\n\n\"Can you construct some sort of rudimentary lathe?\"\n\n"},{"id":"140821","messageId":"BA24F2BF-018D-403B-A23B-0F2E57A7C00A@mit.edu","threadId":"23652","inReplyTo":"m1O8k0Z-000kndC@most.weird.com","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2010-05-03T11:16:55Z","receivedAt":"2010-05-03T11:16:55Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"\nOn May 2, 2010, at 8:59 PM, Greg A. Woods wrote:\n\n> I'm not an expert on PGP internals or such, but I think that's a really\n> bad thing to do.  I'm surprised you were able to get gpg to do it in the\n> first place.  I would have hoped it wouldn't allow it.  As far as I can\n> tell it's _not_ compatible with other implementations of PGP.\n\n> You can of course have more than one e-mail address per key, but you\n> should NEVER have more than one key per e-mail.\n\nThis is pretty common actually.  At the very least it will happen if people are trying to transition between an older and a newer key --- for example, if they are trying to move from a less secure crypto algorithm to a more secure crypto algorithm.\n\nAnd most versions of PGP support it _just_ _fine_.\n\nThey may not pick the key I want, but that's why I have environment or config files set up in various programs which use PGP to use a specific PGP KeyID.\n\n-- Ted\n"},{"id":"140855","messageId":"m1O93yz-000kndC@most.weird.com","threadId":"23652","inReplyTo":"BA24F2BF-018D-403B-A23B-0F2E57A7C00A@mit.edu","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Greg A. Woods","fromEmail":"woods@planix.com","sentAt":"2010-05-03T22:19:17Z","receivedAt":"2010-05-03T22:19:17Z","isPatch":false,"sender":{"key":"woods@planix.com","avatar":null},"body":"At Mon, 3 May 2010 07:16:55 -0400, Theodore Tso <tytso@MIT.EDU> wrote:\nSubject: Re: PATCH:  Less fragile lookup of gpg key\n> \n> On May 2, 2010, at 8:59 PM, Greg A. Woods wrote:\n> > \n> > You can of course have more than one e-mail address per key, but you\n> > should NEVER have more than one key per e-mail.\n> \n> This is pretty common actually.  At the very least it will happen if\n> people are trying to transition between an older and a newer key ---\n> for example, if they are trying to move from a less secure crypto\n> algorithm to a more secure crypto algorithm.\n\nAs I understand things the best way to manage these kinds of things is\nto use sub-keys.  You can change the expire time on a sub-key, and then\neventually you can revoke it, all the while preserving your one primary\npublic key for signing.  Indeed it's a good idea to regularly change\nyour sub-key and expire the older ones.\n\nAny time I've ever encountered anyone with more than one published key\nassociated with any given e-mail address, confusion has inevitably\nensued.\n\nNormally the only time I've ever seen anyone end up with multiple\npublished keys associated with the same e-mail address it has happened\nwhen they have accidentally lost their private key somehow and therefore\nthey were unable to revoke it properly.\n\nIf you must regenerate your primary public key, and you have control of\nyour old public key then the right thing to do is to set the old one to\nexpire ASAP, and/or to revoke it, upon generating a new one, then\npublish the updates together.  This way there doesn't have to be any\nwindow of confusion.\n\nSo, as Grant Olson has also explained, publishing multiple keys with the\nsame e-mail address in one of their UIDs (even if the entire UID is not\nidentical), is only for advanced users who are willing to deal with the\nexceptional usage that results.  Not all Git users are advanced users\nwho will be willing and/or able to deal with these issues.\n\nMeanwhile the original problem here appears to me to be that Git\neffectively encourages use of multiple valid keys that may have the same\ne-mail address attached to multiple key-IDs.\n\nIf I understand correctly from the GnuPG documentation, the desired way\nto search for a key has a very well defined algorithm based on the\nsyntax identifying the format of the \"key\".  I think Git should use that\nsame algorithm at minimum, but by default if there's no hint based on\nthe expressed syntax of the key given it should follow the example of\nmost/all(?) MUA interfaces to PGP, which if I'm not mistaken is to\nsearch by exact match of the e-mail address stripped of any display name\nand all comments.\n\n-- \n\t\t\t\t\t\tGreg A. Woods\n\t\t\t\t\t\tPlanix, Inc.\n\n<woods@planix.com>       +1 416 218 0099        http://www.planix.com/\n"},{"id":"140872","messageId":"20100504021937.GY14986@thunk.org","threadId":"23652","inReplyTo":"m1O93yz-000kndC@most.weird.com","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"","fromEmail":"tytso@mit.edu","sentAt":"2010-05-04T02:19:37Z","receivedAt":"2010-05-04T02:19:37Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, May 03, 2010 at 06:19:17PM -0400, Greg A. Woods wrote:\n> \n> Normally the only time I've ever seen anyone end up with multiple\n> published keys associated with the same e-mail address it has happened\n> when they have accidentally lost their private key somehow and therefore\n> they were unable to revoke it properly.\n\nWell, I suspect this case happens fairly often.  (And there are other\ncases; where you're still gathering enough signatures so you can use\nyour new key, and the old key hasn't been compromised, but people have\nstarted getting paranoid about the crypto algorithms involved, etc.)\nSo I'd argue that saying this is only something that Advanced GPG\nusers will use is probably a bit short-sighted.\n\n> Meanwhile the original problem here appears to me to be that Git\n> effectively encourages use of multiple valid keys that may have the same\n> e-mail address attached to multiple key-IDs.\n\nYes, I think that *is* the problem.  If you want to optimize for the\ncommon case, that's fine, but it's also useful to have a way for users\nto specify in their gitconfig files that a specific KeyID should be\nused if they are signing with a particular e-mail ID.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"140873","messageId":"4BDF8523.1030202@grant-olson.net","threadId":"23652","inReplyTo":"20100504021937.GY14986@thunk.org","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Grant Olson","fromEmail":"kgo@grant-olson.net","sentAt":"2010-05-04T02:23:31Z","receivedAt":"2010-05-04T02:23:31Z","isPatch":false,"sender":{"key":"kgo@grant-olson.net","avatar":"https://gravatar.com/avatar/401c976b3d10d0c43c14d6643336b174d76a5ecec3056e5c22b1f81390853005?d=mp&s=160"},"body":"On 5/3/2010 10:19 PM, tytso@mit.edu wrote:\n> On Mon, May 03, 2010 at 06:19:17PM -0400, Greg A. Woods wrote:\n>> Meanwhile the original problem here appears to me to be that Git\n>> effectively encourages use of multiple valid keys that may have the same\n>> e-mail address attached to multiple key-IDs.\n> \n> Yes, I think that *is* the problem.  If you want to optimize for the\n> common case, that's fine, but it's also useful to have a way for users\n> to specify in their gitconfig files that a specific KeyID should be\n> used if they are signing with a particular e-mail ID.\n> \n\nThat's already there:\n\ngit config user.signingkey 0xDEADBEEF\n\n-Grant\n\n"},{"id":"140887","messageId":"4BDFB99B.7050802@op5.se","threadId":"23652","inReplyTo":"20100504021937.GY14986@thunk.org","subject":"Re: PATCH: Less fragile lookup of gpg key","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2010-05-04T06:07:23Z","receivedAt":"2010-05-04T06:07:23Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 05/04/2010 04:19 AM, tytso@mit.edu wrote:\n> On Mon, May 03, 2010 at 06:19:17PM -0400, Greg A. Woods wrote:\n>>\n>> Meanwhile the original problem here appears to me to be that Git\n>> effectively encourages use of multiple valid keys that may have the same\n>> e-mail address attached to multiple key-IDs.\n> \n> Yes, I think that *is* the problem.  If you want to optimize for the\n> common case, that's fine, but it's also useful to have a way for users\n> to specify in their gitconfig files that a specific KeyID should be\n> used if they are signing with a particular e-mail ID.\n> \n\nOr even better, use the patch with Junio's suggested improvements, so\nnothing changes from how things stand today for people with multiple\nkeys and where git_UID == gpg_UID, but for those where that's not so,\ntry again with just the mail part when no signing key is configured.\n\nEverything else is theoretical discussion that would best be dealt\nwith on some crypto-related mailing list where people actually care.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"}]}