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
signature.asc
Description: This is a digitally signed message part
