Ping: [PATCH man-pages v6] Document encoded I/O

["Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>]

Hi Omar,

Linux 5.10 has been recently released.
Do you have any updates for this patch?

Thanks,

Alex

On 12/1/20 10:56 PM, Michael Kerrisk (man-pages) wrote:
> Hi Alex,
> 
> On 12/1/20 10:35 PM, Alejandro Colomar (man-pages) wrote:
>> Hi Michael,
>>
>> On 12/1/20 9:20 PM, Michael Kerrisk (man-pages) wrote:
>>>>>>>> +.SS Security
>>>>>>>> +Encoded I/O creates the potential for some security issues:
>>>>>>>> +.IP * 3
>>>>>>>> +Encoded writes allow writing arbitrary data which the kernel will decode on
>>>>>>>> +a subsequent read. Decompression algorithms are complex and may have bugs
>>>>>>>> +which can be exploited by maliciously crafted data.
>>>>>>>> +.IP *
>>>>>>>> +Encoded reads may return data which is not logically present in the file
>>>>>>>> +(see the discussion of
>>>>>>>> +.I len
>>>>>>>> +vs.
>>>>>>>
>>>>>>> Please, s/vs./vs/
>>>>>>> See the reasons below:
>>>>>>>
>>>>>>> Michael (mtk),
>>>>>>>
>>>>>>> Here the renderer outputs a double space
>>>>>>> (as for separating two sentences).
>>>>>>>
>>>>>>> Are you okay with that?
>>>>
>>>> Yes, that should probably be avoided. I'm not sure what the
>>>> correct way is to prevent that in groff though. I mean, one
>>>> could write
>>>>
>>>> .RI "vs.\ " unencoded_len
>>>>
>>>> but I think that simply creates a nonbreaking space,
>>>> which is not exactly what is desired.
>>>
>>> Ahh -- found it. From https://groff.ffii.org/groff/groff-1.21.pdf,
>>> we can write:
>>>
>>> vs.\&
>>>
>>> to prevent the double space.
>>
>> Nice to see it's possible.
>> However, I would argue for simplicity,
>> and use a simple 'vs',
>> which is already in use.
> 
> Indeed better. Thanks for noticing that.
> 
> Thanks,
> 
> Michael
> 
> 

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/