[Reportbug-maint] Bug#857794: reportbug: crash when encountering some non-ASCII characters

[Nis Martensen]

Hi Stuart,

Thanks for your comments!

On 22-03-2017 02:45, Stuart Prescott wrote:
> C.UTF-8 is provided within glibc (it's in the libc-bin package so it
> is always available). Is it worth setting that as the locale for all
> communication with subprocesses? It strikes me that could simplify
> some parts of this encoding handling.

We could do this if we knew that we'd then always get UTF-8 encoded
data. Is it guaranteed that all subprocesses will produce text output
encoded in the charset associated with the current locale? Or are the
tools just passing on what they get from their input files?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848729
has a case where reportbug ran into such "foreign charset" data; setting
LC_ALL=C.UTF-8 for reportbug would not have helped there.

Things might be easier if the subprocesses called by reportbug would
only output the bits of information needed. Unfortunately they don't,
they output much more, and reportbug needs to deal with it and parse it.
Most information needed is ASCII-only anyway, so limiting other tools'
output would be ideal. We just can't fix that in reportbug.

So the minimum we should do is avoid the crashes, and changing the error
handler allows us to do that.

> If we're touching every invocation subprocess.* anyway, can we also
> take this opportunity to get rid of any invocations via the shell?
> 
> +def get_command_output(cmd): +    use_shell = False +    if
> isinstance(cmd, str) and ' ' in cmd: +        use_shell = True +
> return subprocess.run(cmd, shell=use_shell, 
> stdout=subprocess.PIPE).stdout.decode(errors='backslashreplace')
> 
> specifically, my suggestion is that we *require* cmd to be a list or
> tuple and always force use_shell=False. Then we never need to worry
> about nasty characters going near the shell, there's also one less
> subprocess being used.
> 
> Associated with that:
> 
> * redirection of stderr to /dev/null can be done in python instead
> 
> * the uses of COLUMNS=79 are either no-ops because the command
> doesn't respect COLUMNS anyway or no-ops because the command ignores
> COLUMNS when invoked within a pipe.

No problem with that idea :)
I just tried to keep the changes to a minimum since we're in deep freeze
at the moment.

Cheers,
 Nis