patch attachments still unwelcome?

patch attachments still unwelcome?

[Eric Wong]

The BDFL sets an example by attaching patches:

https://lore.kernel.org/lkml/?q=f%3Atorvalds+n%3Apatch

So the documentation in the kernel advising against sending
patch attachments seems hypocritical.  Changing the kernel docs
allow patch attachments could be a good start to making life
easier for contributors without SMTP or IMAP access.

Are many MUAs still incapable of handling them?
mutt shows text patches inline, at least.

I've already been making public-inbox look harder for pre/post-image
OIDs in attachments that it wouldn't decode before:

https://public-inbox.org/meta/20191031031220.21048-1-e@80x24.org/

And I'm considering making it handle application/octet-stream, too;
since patches do end up with the wrong Content-Type, sometimes:

https://lore.kernel.org/lkml/CANAwSgRs2DUXwvhJD5qpXg04qEdP_Nt-wQqRbD2FpY2SWnHpAA@mail.gmail.com/

Re: patch attachments still unwelcome?

[Greg KH]

On Fri, Nov 01, 2019 at 02:27:46AM +0000, Eric Wong wrote:
> The BDFL sets an example by attaching patches:
> 
> https://lore.kernel.org/lkml/?q=f%3Atorvalds+n%3Apatch
> 
> So the documentation in the kernel advising against sending
> patch attachments seems hypocritical.  Changing the kernel docs
> allow patch attachments could be a good start to making life
> easier for contributors without SMTP or IMAP access.

It's not hypocritical, as lots of email clients still get this wrong and
make responding to attachments almost impossible.  Many do get it right,
but trying to document the differences here is quite difficult (I tried
once, gave up as it was a mess).

> Are many MUAs still incapable of handling them?
> mutt shows text patches inline, at least.

For most MUAs that send them, yes, but not for all.  I know of at least
2 that send text attachments in formats that mutt will not show it
inline, nor allow responding to them properly.  MacOS Mail is one easy
example to point to as getting this totally wrong.

So, if you know what you are doing, yes, this is fine, but it's still a
good idea to say "please do not do this" to make it easier for people
just starting out.

thanks,

greg k-h

Re: patch attachments still unwelcome?

[Konstantin Ryabitsev]

On Fri, Nov 01, 2019 at 02:27:46AM +0000, Eric Wong wrote:
> The BDFL sets an example by attaching patches:
> 
> https://lore.kernel.org/lkml/?q=f%3Atorvalds+n%3Apatch
> 
> So the documentation in the kernel advising against sending
> patch attachments seems hypocritical.  Changing the kernel docs
> allow patch attachments could be a good start to making life
> easier for contributors without SMTP or IMAP access.
> 
> Are many MUAs still incapable of handling them?

It's not really that they are incapable of "handling" them, it's that
patches-as-attachments make it significantly harder to do code review in
a way that is convenient to developers. While some MUAs will properly
inline-quote an attached text/plain file when you hit "Reply All",
many others won't, requiring manual copy-pasting in order to comment on
actual patch contents.

-K

Re: patch attachments still unwelcome?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

On Fri, Nov 01, 2019 at 09:00:12AM -0400, Konstantin Ryabitsev wrote:
> On Fri, Nov 01, 2019 at 02:27:46AM +0000, Eric Wong wrote:

> > patch attachments seems hypocritical.  Changing the kernel docs
> > allow patch attachments could be a good start to making life
> > easier for contributors without SMTP or IMAP access.

> > Are many MUAs still incapable of handling them?

> It's not really that they are incapable of "handling" them, it's that
> patches-as-attachments make it significantly harder to do code review in
> a way that is convenient to developers. While some MUAs will properly
> inline-quote an attached text/plain file when you hit "Reply All",
> many others won't, requiring manual copy-pasting in order to comment on
> actual patch contents.

It's not just the recieving end either - persuading some MTAs to encode
things as text can be a challenge.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: patch attachments still unwelcome?

[Theodore Y. Ts'o]

On Fri, Nov 01, 2019 at 10:04:56AM +0100, Greg KH wrote:
> > So the documentation in the kernel advising against sending
> > patch attachments seems hypocritical.  Changing the kernel docs
> > allow patch attachments could be a good start to making life
> > easier for contributors without SMTP or IMAP access.
> 
> It's not hypocritical, as lots of email clients still get this wrong and
> make responding to attachments almost impossible.  Many do get it right,
> but trying to document the differences here is quite difficult (I tried
> once, gave up as it was a mess).
> 
> > Are many MUAs still incapable of handling them?
> > mutt shows text patches inline, at least.
> 
> For most MUAs that send them, yes, but not for all.  I know of at least
> 2 that send text attachments in formats that mutt will not show it
> inline, nor allow responding to them properly.  MacOS Mail is one easy
> example to point to as getting this totally wrong.
> 
> So, if you know what you are doing, yes, this is fine, but it's still a
> good idea to say "please do not do this" to make it easier for people
> just starting out.

Perhaps we should explicitly explain this and then include a white
list of MUA's that can send text attachments safely/correctly?  (e.g.,
if you are using the following MUA's, using text attachments are OK;
if you are using the following MUA's, it will definitely NOT work;
with all others, proceed with caution.)

					- Ted

Re: patch attachments still unwelcome?

[Dmitry Vyukov]

On Mon, Nov 4, 2019 at 2:13 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Fri, Nov 01, 2019 at 10:04:56AM +0100, Greg KH wrote:
> > > So the documentation in the kernel advising against sending
> > > patch attachments seems hypocritical.  Changing the kernel docs
> > > allow patch attachments could be a good start to making life
> > > easier for contributors without SMTP or IMAP access.
> >
> > It's not hypocritical, as lots of email clients still get this wrong and
> > make responding to attachments almost impossible.  Many do get it right,
> > but trying to document the differences here is quite difficult (I tried
> > once, gave up as it was a mess).
> >
> > > Are many MUAs still incapable of handling them?
> > > mutt shows text patches inline, at least.
> >
> > For most MUAs that send them, yes, but not for all.  I know of at least
> > 2 that send text attachments in formats that mutt will not show it
> > inline, nor allow responding to them properly.  MacOS Mail is one easy
> > example to point to as getting this totally wrong.
> >
> > So, if you know what you are doing, yes, this is fine, but it's still a
> > good idea to say "please do not do this" to make it easier for people
> > just starting out.
>
> Perhaps we should explicitly explain this and then include a white
> list of MUA's that can send text attachments safely/correctly?  (e.g.,
> if you are using the following MUA's, using text attachments are OK;
> if you are using the following MUA's, it will definitely NOT work;
> with all others, proceed with caution.)


One thing that wasn't clear to me when I implemented syzbot is that
some people see attachments inline. syzbot included whole kernel
config and 1MB of logs as attachments, I assumed that other people see
them as, well, attachments. So that may be worth documenting as well.
Though, I did not know that document exists as well, so it would not
help me...

Re: patch attachments still unwelcome?

[Greg KH]

On Mon, Nov 04, 2019 at 08:13:10AM -0500, Theodore Y. Ts'o wrote:
> On Fri, Nov 01, 2019 at 10:04:56AM +0100, Greg KH wrote:
> > > So the documentation in the kernel advising against sending
> > > patch attachments seems hypocritical.  Changing the kernel docs
> > > allow patch attachments could be a good start to making life
> > > easier for contributors without SMTP or IMAP access.
> > 
> > It's not hypocritical, as lots of email clients still get this wrong and
> > make responding to attachments almost impossible.  Many do get it right,
> > but trying to document the differences here is quite difficult (I tried
> > once, gave up as it was a mess).
> > 
> > > Are many MUAs still incapable of handling them?
> > > mutt shows text patches inline, at least.
> > 
> > For most MUAs that send them, yes, but not for all.  I know of at least
> > 2 that send text attachments in formats that mutt will not show it
> > inline, nor allow responding to them properly.  MacOS Mail is one easy
> > example to point to as getting this totally wrong.
> > 
> > So, if you know what you are doing, yes, this is fine, but it's still a
> > good idea to say "please do not do this" to make it easier for people
> > just starting out.
> 
> Perhaps we should explicitly explain this and then include a white
> list of MUA's that can send text attachments safely/correctly?  (e.g.,
> if you are using the following MUA's, using text attachments are OK;
> if you are using the following MUA's, it will definitely NOT work;
> with all others, proceed with caution.)

I'm not going to try to keep such a list up-to-date, that's crazy.  It
usually depends on defaults/configurations as well, so it's not always
the specific program.  Also different versions do different things (like
Mail from OS-X).  So it's just much easier to say, "no attachments" and
then if you really know what you are doing, and you know your email
client will set it up properly, then do it.

Also, Zoho mail, ugh, I never understood how that could always send
stuff out so horribly...

greg k-h

Re: patch attachments still unwelcome?

[Drew DeVault]

Also pitching in with a vote against patches-as-attachments. My mailing
list software doesn't know how to deal with these and I don't really
want to teach it about them.

Re: patch attachments still unwelcome?

[Jani Nikula]

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]

On Mon, 04 Nov 2019, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Mon, Nov 4, 2019 at 2:13 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>>
>> On Fri, Nov 01, 2019 at 10:04:56AM +0100, Greg KH wrote:
>> > > So the documentation in the kernel advising against sending
>> > > patch attachments seems hypocritical.  Changing the kernel docs
>> > > allow patch attachments could be a good start to making life
>> > > easier for contributors without SMTP or IMAP access.
>> >
>> > It's not hypocritical, as lots of email clients still get this wrong and
>> > make responding to attachments almost impossible.  Many do get it right,
>> > but trying to document the differences here is quite difficult (I tried
>> > once, gave up as it was a mess).
>> >
>> > > Are many MUAs still incapable of handling them?
>> > > mutt shows text patches inline, at least.
>> >
>> > For most MUAs that send them, yes, but not for all.  I know of at least
>> > 2 that send text attachments in formats that mutt will not show it
>> > inline, nor allow responding to them properly.  MacOS Mail is one easy
>> > example to point to as getting this totally wrong.
>> >
>> > So, if you know what you are doing, yes, this is fine, but it's still a
>> > good idea to say "please do not do this" to make it easier for people
>> > just starting out.
>>
>> Perhaps we should explicitly explain this and then include a white
>> list of MUA's that can send text attachments safely/correctly?  (e.g.,
>> if you are using the following MUA's, using text attachments are OK;
>> if you are using the following MUA's, it will definitely NOT work;
>> with all others, proceed with caution.)
>
>
> One thing that wasn't clear to me when I implemented syzbot is that
> some people see attachments inline. syzbot included whole kernel
> config and 1MB of logs as attachments, I assumed that other people see
> them as, well, attachments. So that may be worth documenting as well.
> Though, I did not know that document exists as well, so it would not
> help me...

Typically you'd have a multipart/mixed MIME message with several parts
of various Content-Types. In this case presumably text/plain, but
text/x-diff is not out of the question for patches. Also seen a lot of
application/octet-stream for logs.

You can give a *hint* to the recipient MUA on how to interpret each part
by setting Content-Disposition: attachment or inline. Bottom line,
whether you can control that in your MUA, and whether the recipient MUA
actually respects that is anyone's guess.

For fun, this multipart message contains three parts, the one you're
reading, and two additional parts, one of which should be inline and the
other one an attachment.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

[-- Attachment #2: inline --]
[-- Type: text/plain, Size: 31 bytes --]

This is supposed to be inline.

[-- Attachment #3: attachment --]
[-- Type: text/plain, Size: 38 bytes --]

This is supposed to be an attachment.

Re: patch attachments still unwelcome?

[Geert Uytterhoeven]

Hi Jani,

On Mon, Nov 4, 2019 at 3:52 PM Jani Nikula <jani.nikula@intel.com> wrote:
> Typically you'd have a multipart/mixed MIME message with several parts
> of various Content-Types. In this case presumably text/plain, but
> text/x-diff is not out of the question for patches. Also seen a lot of
> application/octet-stream for logs.
>
> You can give a *hint* to the recipient MUA on how to interpret each part
> by setting Content-Disposition: attachment or inline. Bottom line,
> whether you can control that in your MUA, and whether the recipient MUA
> actually respects that is anyone's guess.
>
> For fun, this multipart message contains three parts, the one you're
> reading, and two additional parts, one of which should be inline and the
> other one an attachment.

So the Gmail web interface shows both as attachments, but can show
the contents when I click on them.
The Gmail Android app shows both as attachments, and forces me to
download the attachments to read them, using a selected app.

Ergo, no attachments is the safest.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: patch attachments still unwelcome?

[Geert Uytterhoeven]

Hi Jani,

On Mon, Nov 4, 2019 at 6:40 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Nov 4, 2019 at 3:52 PM Jani Nikula <jani.nikula@intel.com> wrote:
> > Typically you'd have a multipart/mixed MIME message with several parts
> > of various Content-Types. In this case presumably text/plain, but
> > text/x-diff is not out of the question for patches. Also seen a lot of
> > application/octet-stream for logs.
> >
> > You can give a *hint* to the recipient MUA on how to interpret each part
> > by setting Content-Disposition: attachment or inline. Bottom line,
> > whether you can control that in your MUA, and whether the recipient MUA
> > actually respects that is anyone's guess.
> >
> > For fun, this multipart message contains three parts, the one you're
> > reading, and two additional parts, one of which should be inline and the
> > other one an attachment.
>
> So the Gmail web interface shows both as attachments, but can show
> the contents when I click on them.
> The Gmail Android app shows both as attachments, and forces me to
> download the attachments to read them, using a selected app.

Just for fun, I tried alpine, which I still use from time to time.

Alpine shows the first one "sort of" inline, at the bottom:

| --
| Jani Nikula, Intel Open Source Graphics Center
|
|
|     [ Part 2: "Attached Text" ]
|
| This is supposed to be inline.
|
|
|     [ Part 3, Text/PLAIN 2 lines. ]
|     [ Not Shown. Use the "V" command to view or save this part. ]

But when replying, the "inline" one is not quoted, so I can't provide
review comments.

> Ergo, no attachments is the safest.

Unless your patches are perfect, and will receive no comments but
RoB or AB tags ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds