{"thread":{"id":"37491","subject":"git format-patch --in-reply-to allows header injection. Intended?","startedAt":"2014-09-04T21:21:49Z","lastAt":"2014-09-04T23:59:49Z","messageCount":4,"participants":["Niklas Hambüchen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"248874","messageId":"5408D7ED.9010203@nh2.me","threadId":"37491","inReplyTo":null,"subject":"git format-patch --in-reply-to allows header injection. Intended?","fromName":"Niklas Hambüchen","fromEmail":"mail@nh2.me","sentAt":"2014-09-04T21:21:49Z","receivedAt":"2014-09-04T21:21:49Z","isPatch":false,"sender":{"key":"mail@nh2.me","avatar":null},"body":"Hi,\n\nI just wanted to ask if the --in-reply-to flag of git format-patch is\nsupposed to write the given string unmodified into the email or whether\nit ought to perform some check against header injection.\n\nFor example, if you pass \"--in-reply-to=<msgid>\\nTo: <other@example.com\"\n(notice lack of trailing `>`), then the generated email will actually\ncontain a\n  To: <other@example.com>\nheader.\n\n(Depending on your shell you might also use \"--in-reply-to=`cat`\" to get\nthe above working more easily.)\n\nIs this known and working as intended, or undesired?\n\nThanks!\nNiklas\n"},{"id":"248876","messageId":"xmqqppfbqd9x.fsf@gitster.dls.corp.google.com","threadId":"37491","inReplyTo":"5408D7ED.9010203@nh2.me","subject":"Re: git format-patch --in-reply-to allows header injection. Intended?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-04T21:36:09Z","receivedAt":"2014-09-04T21:36:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Niklas Hambüchen <mail@nh2.me> writes:\n\n> For example, if you pass \"--in-reply-to=<msgid>\\nTo: <other@example.com\"\n> (notice lack of trailing `>`), then the generated email will actually\n> contain a\n>   To: <other@example.com>\n> header.\n\nWhile I do not think of a reason to specify such a string to the\nin-reply-to option (I'd rather edit the output in the editor if I\nwanted to do anything fancy [*1*]), I do not think there is a reason\nwhy you want to add a code to forbid such use, either.\n\n\n[Footnote]\n\n*1* For that matter, --in-reply-to option itself is superfluous.\n"},{"id":"248878","messageId":"5408DCC5.8000607@nh2.me","threadId":"37491","inReplyTo":"xmqqppfbqd9x.fsf@gitster.dls.corp.google.com","subject":"Re: git format-patch --in-reply-to allows header injection. Intended?","fromName":"Niklas Hambüchen","fromEmail":"mail@nh2.me","sentAt":"2014-09-04T21:42:29Z","receivedAt":"2014-09-04T21:42:29Z","isPatch":false,"sender":{"key":"mail@nh2.me","avatar":null},"body":"On 04/09/14 23:36, Junio C Hamano wrote:\n> While I do not think of a reason to specify such a string to the\n> in-reply-to option (I'd rather edit the output in the editor if I\n> wanted to do anything fancy [*1*]), I do not think there is a reason\n> why you want to add a code to forbid such use, either.\n\nMy question was to find out whether I can pass untrusted user input to\n--in-reply-to and expect that no header beyond \"In-Reply-To\" and\n\"References\" is modified, but your answer makes clear that I cannot.\n\nA possible alternative might have been that git verifies that the input\nto --in-reply-to matches the format specified RFC2822 (section 3.6.4.).\n\nThanks!\n"},{"id":"248883","messageId":"xmqqd2bbq6mi.fsf@gitster.dls.corp.google.com","threadId":"37491","inReplyTo":"5408DCC5.8000607@nh2.me","subject":"Re: git format-patch --in-reply-to allows header injection. Intended?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-04T23:59:49Z","receivedAt":"2014-09-04T23:59:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Niklas Hambüchen <mail@nh2.me> writes:\n\n> On 04/09/14 23:36, Junio C Hamano wrote:\n>> While I do not think of a reason to specify such a string to the\n>> in-reply-to option (I'd rather edit the output in the editor if I\n>> wanted to do anything fancy [*1*]), I do not think there is a reason\n>> why you want to add a code to forbid such use, either.\n>\n> My question was to find out whether I can pass untrusted user input to\n> ...\n\nAh, in general, anybody who passes unvetted user input to any Git\nPorcelain deserves what s/he gets, so perhaps you would want to at\nleast make sure that the input is a single line, or something.\n"}]}