list From mangling and git am

list From mangling and git am

[Mark Wielaard]

Hi sourceware overseers,

The mailinglist From/Reply-To mangling doesn't interact nicely with
git am. For example I got the following message from Matthias (in CC):
https://sourceware.org/pipermail/elfutils-devel/2020q1/002484.html
Which looks fine in the archives, but as received by me has:

  X-Mailer: git-send-email 2.25.1.481.gfbce0eb801-goog
  Subject: [PATCH] libelf: decompress: ensure zlib resource cleanup
  To: elfutils-devel@sourceware.org
  From: Matthias Maennich via Elfutils-devel <elfutils-devel@sourceware.org>
  Reply-To: Matthias Maennich <maennich@google.com>

Normally I just | git am such messages to apply, but that generates a
commit that has:

  Author: Matthias Maennich via Elfutils-devel <elfutils-devel@sourceware.org>

Which seems wrong. How are others dealing with this?

Thanks,

Mark

Re: list From mangling and git am

[Matthias Maennich]

Hi!

On Mon, Mar 16, 2020 at 01:16:24PM +0100, Mark Wielaard wrote:
>Hi sourceware overseers,
>
>The mailinglist From/Reply-To mangling doesn't interact nicely with
>git am. For example I got the following message from Matthias (in CC):
>https://sourceware.org/pipermail/elfutils-devel/2020q1/002484.html
>Which looks fine in the archives, but as received by me has:
>
>  X-Mailer: git-send-email 2.25.1.481.gfbce0eb801-goog
>  Subject: [PATCH] libelf: decompress: ensure zlib resource cleanup
>  To: elfutils-devel@sourceware.org
>  From: Matthias Maennich via Elfutils-devel <elfutils-devel@sourceware.org>
>  Reply-To: Matthias Maennich <maennich@google.com>
>
>Normally I just | git am such messages to apply, but that generates a
>commit that has:
>
>  Author: Matthias Maennich via Elfutils-devel <elfutils-devel@sourceware.org>
>
>Which seems wrong. How are others dealing with this?

I would be grateful for a solution to this. I had the same issue when
initially posting to libabigail@sourceware.org and now work around this
by cc'ing Dodji on all patches. I am using git-send-email as usual and
usually do not have those issues.

Cheers,
Matthias

>
>Thanks,
>
>Mark

Re: list From mangling and git am

[Frank Ch. Eigler]

Hi -

> > The mailinglist From/Reply-To mangling doesn't interact nicely with
> > git am. [...]

As you know, increasing mail security/spam measures are what is
driving cleanliness with respect to mailing list systems.  Even as we
speak, we have outgoing email from sourceware to important receivers
like gmail -blocked- because the receiver doesn't think we are clean
enough.  So I suspect we'll need to retain/enhance these measures
rather than roll them back.

For git am workflows, consider:

- running "git amend --author=<....>" after "git am" to fix things

- asking submitters to use "git format-patch --from="Real Name git <...>"
  where the enclosed name is different enough that git format-patch
  includes a second From: header in the body, which git-am prefers

- using the mailing list mbox (which has the received form of emails
  rather than the retransmitted ones) as patch source

And also:

- using git branches / bugzilla / other systems, which do not rely
  on mailing list header preservation

- adding patches as attachments (so not plain git send-email)


- FChE

Re: list From mangling and git am

[Mark Wielaard]

Hi,

On Mon, 2020-03-16 at 09:06 -0400, Frank Ch. Eigler wrote:
> The mailinglist From/Reply-To mangling doesn't interact nicely
> > > with git am. [...]
> 
> As you know, increasing mail security/spam measures are what is
> driving cleanliness with respect to mailing list systems.  Even as we
> speak, we have outgoing email from sourceware to important receivers
> like gmail -blocked- because the receiver doesn't think we are clean
> enough.  So I suspect we'll need to retain/enhance these measures
> rather than roll them back.

Rolling things back is probably not a good idea. There are two ways you
can go, strip dkim headers and rewrite From/Reply-To, or make sure you
keep the original headers and body in tact (no Reply-to mangling, no
subject rewriting, no body or attachment rewriting/removing) so the
dkim signature is correct. The first is probably less work and they
easiest way to comply with any dmarc policy. The second is probably
more work since you have to make sure that no part of the mailing-list
pipeline mangles the original email in any way.

> For git am workflows, consider:
> 
> - running "git amend --author=<....>" after "git am" to fix things

Yes, this is what I am using now. But it is slightly inconvenient since
it is easy to forget and you cannot easily script it.

> - asking submitters to use "git format-patch --from="Real Name git
> <...>"
>   where the enclosed name is different enough that git format-patch
>   includes a second From: header in the body, which git-am prefers

This works but only if the "real from" (Author) is slightly different
from the normal From. So if I do --from="Mark J. Wielaard
<mark@klomp.org>" while the Author is "Mark Wielaard <mark@klomp.org>"
then the Body of the email will start with a From: Mark Wielaard <
mark@klomp.org> which git am will pick up correctly.

This should be possible to script (on the sender side). But it is odd
there is no git send-email option to always generate this extra "Body
From:". That would be ideal. Maybe it is something that upstream git
could consider adding for mailing-lists that mangle From headers?

Cheers,

Mark

Re: list From mangling and git am

[Matthias Maennich]

Hi!

On Fri, Mar 20, 2020 at 07:03:14PM +0100, Mark Wielaard wrote:
>Hi,
>
>On Mon, 2020-03-16 at 09:06 -0400, Frank Ch. Eigler wrote:
>> The mailinglist From/Reply-To mangling doesn't interact nicely
>> > > with git am. [...]
>>
>> As you know, increasing mail security/spam measures are what is
>> driving cleanliness with respect to mailing list systems.  Even as we
>> speak, we have outgoing email from sourceware to important receivers
>> like gmail -blocked- because the receiver doesn't think we are clean
>> enough.  So I suspect we'll need to retain/enhance these measures
>> rather than roll them back.
>
>Rolling things back is probably not a good idea. There are two ways you
>can go, strip dkim headers and rewrite From/Reply-To, or make sure you
>keep the original headers and body in tact (no Reply-to mangling, no
>subject rewriting, no body or attachment rewriting/removing) so the
>dkim signature is correct. The first is probably less work and they
>easiest way to comply with any dmarc policy. The second is probably
>more work since you have to make sure that no part of the mailing-list
>pipeline mangles the original email in any way.
>
>> For git am workflows, consider:
>>
>> - running "git amend --author=<....>" after "git am" to fix things
>
>Yes, this is what I am using now. But it is slightly inconvenient since
>it is easy to forget and you cannot easily script it.
>
>> - asking submitters to use "git format-patch --from="Real Name git
>> <...>"
>>   where the enclosed name is different enough that git format-patch
>>   includes a second From: header in the body, which git-am prefers
>
>This works but only if the "real from" (Author) is slightly different
>from the normal From. So if I do --from="Mark J. Wielaard
><mark@klomp.org>" while the Author is "Mark Wielaard <mark@klomp.org>"
>then the Body of the email will start with a From: Mark Wielaard <
>mark@klomp.org> which git am will pick up correctly.
>
>This should be possible to script (on the sender side). But it is odd
>there is no git send-email option to always generate this extra "Body
>From:". That would be ideal. Maybe it is something that upstream git
>could consider adding for mailing-lists that mangle From headers?

It is the second condition (ident_cmp) in
https://github.com/git/git/blob/master/pretty.c#L459 that one would need
to target via a command line option. Not sure upstream would accept yet
another option like --always-from.

Cheers,
Matthias

>
>Cheers,
>
>Mark