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

[Andreas Metzler]

On 2024-06-26 Baptiste Beauplat <lyknode at debian.org> wrote:
> On Wed, 2024-06-26 at 19:46 +0200, Baptiste Beauplat wrote:
>> On Wed, 2024-06-26 at 18:47 +0200, Andreas Metzler wrote:
>>> 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.

>> Yes, I have to admit, I'm a bit surprised by the reply.

>> Status output is a text protocol. That's what is described by
>> doc/DETAILS. However, it can generate raw binary, non-printable
>> characters.

>> I do think this is bad design, and that's what I wanted to challenge
>> with this issue.

>> I guess I also fail to see why a single char patch, fixing a design
>> issue, with no drawbacks (escaping is already implemented) would not be
>> an improvement to GunPG.

>> We've had a single input on that issue, I would be curious to know what
>> other people think about this issue.

> A small precision: I'm only talking about how the NOTATION_DATA value
> is represented in the status output. Not the actual data itself nor its
> encoding.

> My argument is, it could be binary, utf-8, latin-9 or whatever, as long
> as it's represented as an ascii printable value in the output (%XX
> escaped or base64 for example), it would not fail a textual parser
> looking for a GOODSIG.

Hello,

well, upstream does not seem to share the opinion that status output is an
ASCII text protocol but thinks UTF-8 may be sent in some special
circumstances. With this premise the proposed patch is not a bugfix but
a design change.

So I think the correct thing to do is to close this report. Could you
please take it directly to upstream if you want to argue for the design
change? I doubt adding me as a messenger in between will improve the
rationale.

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'