[pkg-gnupg-maint] Bug#1074127: gnupg2: write_status_text_and_buffer fails to escape some non-printable characters

[Andreas Metzler]

Control: forwarded -1 https://dev.gnupg.org/T7176

On 2024-06-24 Baptiste Beauplat <lyknode at debian.org> wrote:
> On Mon, 2024-06-24 at 18:43 +0200, Andreas Metzler wrote:
> > Thank you, I have forwarded this to the upstream tracker.

> Thanks a lot.

> To give out a bit more context, we got an python Exception on
> mentors.debian.net triggered by an upload, signed by sq (Sequoia).

> The tool apparently adds a random binary salt to the signature as
> notation data, which is then present in the status output.

> We read the status output as utf-8 encoded data (perhaps wrongfully)
> and python failed to decode the output because the salt was neither
> escaped properly nor valid utf-8 output.

> I do expect we will not be the only one affected by this issue.

> I'd like to point out that other function in gpg seem to escape char
> over 127 (such as in `print_hashline` from `g10/gpg.c`).
[...]

Hello,

This has been closed upstream as not-a-bug with the following rationale:
| The point here is to escape control characters so that we do not run
| into problems when reading the stuff. Escaping non-ascii (c >127) is
| not required and would put a lower limit on the number of (utf-8)
| characters we can print via the status lines.

| Note also that we use almost everywhere ascii versions of the
| character checks. Thus I would not consider this a bug.

And later:
| Reading the original bug report it is clear that this is not a gpg bug
| but a problem in the Python code. This should only be read as utf-8 if
| the NOTATION_FLAGS line indicated that this is human readable.

In my test with sqop no NOTATION_FLAGS were set for the salt.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'