[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 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.

(Fact is we don't even parse/decode the NOTATION_DATA value in our
python code.)

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/6ac2e361/attachment.sig>