Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

From: Josh Triplett <josh@joshtriplett.org>
Date: Jul 29, 2016, 02:08 UTC
Message-ID: <20160729020801.GA14892@x>
In-Reply-To: <20160729001618.GA9646@sigill.intra.peff.net>

On Thu, Jul 28, 2016 at 08:16:19PM -0400, Jeff King wrote:

Show 11 quoted lines

> The question in my mind is whether people actually use format-patch for
> things besides emailing, and if the final destination is something other
> than "git am".  It is a handy format because it is the least-lossy way
> to move commits around external to git itself.  That's why "rebase" used
> it originally. If the final destination is "am" (as it is for rebase),
> then in-body headers are OK, because we know it understands those. If
> not, then it's a regression.
> 
> I think on the whole that defaulting to "--from" would help more people
> than hurt them, but if we do believe there are scripts that would be
> regressed, it probably needs a deprecation period.

I don't think it's likely that there are scripts that would be regressed (and I think it's likely that there are scripts that would be progressed), but I'd also have no objection to a deprecation period.

I just confirmed that with the default changed, --no-from works to return to the current behavior, so we don't need a new option. And --no-from has worked for a long time, so scripts won't need to care if they're working with an old version of git.

I can provide a patch implementing a new config option to set the format-patch --from default ("false" for --no-from, "true" for --from, or a string value for --from=value).

Do you think this needs the kind of very noisy deprecation period that push.default had, where anyone without the git-config option set gets a warning to stderr? Or do you think it would suffice to provide a warning in the release notes for a while and then change the default?