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

[Baptiste Beauplat]

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.

Best,
-- 
Baptiste Beauplat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20240626/765def66/attachment.sig>