Re: [PATCH] md5sum, sha*sum: only escape file names containing newlines

[Pádraig Brady]

On 11/01/2013 06:08 PM, Eric Blake wrote:
> On 11/01/2013 12:02 PM, Pádraig Brady wrote:
>> On 11/01/2013 05:39 PM, Eric Blake wrote:
>>> On 11/01/2013 10:29 AM, Pádraig Brady wrote:
>>>> This should be fully backwards and forwards compatible with previous
>>>> escaping, since we'll never have a file name at the start of a line,
>>>> thus '\' at the start of a line always means the file name is escaped.
>>>
>>> This feels like it could be a step in the wrong direction to me.  I've
>>> been arguing that we need to escape file names containing \r, for the
>>> sake of people that transmit files with \r\n line endings compared to
>>> files that contain a literal trailing \r.
>>
>> I can see the need for that yes.
>>
>> Though I don't think avoiding the redundant escaping
>> of file names with just '\' characters would impact that?
> 
> Indeed, after thinking a bit more, I think your proposal still makes
> sense; we have an unambiguous marker at the front of the line telling us
> whether escape processing is employed for the rest of the line.  And as
> long as we are changing the output, we might as well make the one
> release change all output at once (back to the argument of the
> NEWS-worthy mention that output between older versions and newer is not
> identical, even though newer versions will continue to correctly parse
> older version).  It may be sufficient to just check for newline
> anywhere, or carriage return as final byte, as the two conditions that
> warrant escaping.  I guess that means I should try and make some time to
> actually write my \r patches that I've been rambling on about for
> several years.

For my reference.

The \n escaping is especially important as that directly
impacts the --check parsing.  I.E. one could construct a file
and an embedded newline and "valid format checksum" to bypass a
valid --check for a replaced file.

While escaping \r in the output would allow one to parse
DOS format checksum files, but would be backwards and forwards
incompatible in the edge case where \r is actually the last
character of a file.

cheers,
Pádraig.