linux-kernel - Re: [PATCH] Documentation: networking: device drivers: Remove stray asterisks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <xmqq7e3g12xo.fsf@gitster-ct.c.googlers.com>
Date:   Sun, 01 Dec 2019 07:27:31 -0800
From:   Junio C Hamano <gitster@...ox.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Jonathan Corbet <corbet@....net>,
        Git List Mailing <git@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list\:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Jonathan Neuschäfer 
        <j.neuschaefer@....net>
Subject: Re: [PATCH] Documentation: networking: device drivers: Remove stray asterisks

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Sat, Nov 30, 2019 at 10:35 PM Junio C Hamano <gitster@...ox.com> wrote:
>>
>> OK, so it appears that the tool is working as documented.
>
> Well, yes and no.
>
> I think it's a mistake that --no-keep-cr (which is the default) only
> acts on the outer envelope.
>
> Now, *originally* the outer envelope was all that existed so it makes
> sense in a historical context of "CR removal happens when splitting
> emails in an mbox". And that's the behavior we have.

Hmph, first of all, the one I was referring to as "documented" was
about --ignore-whitespace, and not --no-keep-cr.

And I am not as sure as you seem to be about "--no-keep-cr" either.

What was the reason why "--no-keep-cr" was invented and made
default?  Wasn't it because RFC says that each line of plaintext
transfer of an e-mail is terminated with CRLF?  It would mean that,
whether the payload originally had CRLF terminated or LF terminated,
we would not be able to tell---the CR may have been there from the
beginning, or it could have been added in transit.  And because we
(the projects Git was originally designed to serve well) wanted our
patches with LF terminated lines most of the time, it made sense to
strip CR from CRLF (i.e. assuming that it would be rare that the
sender wants to transmit CRLF terminated lines).

If the contents were base64 protected from getting munged during
transit, we _know_ CRLF in the payload after we decode MIME is what
the sender _meant_ to give us, no?  Which leads me to say ...

>
> But then git learnt to do MIME decoding and extracting things from
> base64 etc, and the CR removal wasn't updated to that change.

... I do not think it was a wrong decision (well, I do not think we
made the conscious decision to do so, though) not to do that update.

I dunno.