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

[Baptiste Beauplat]

Hi Andreas,

On Fri, 2024-06-28 at 18:46 +0200, Andreas Metzler wrote:
> 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.

Agreed. Thank you for relaying the initial bug report.

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/20240701/ca6cd05b/attachment.sig>