Hi Andreas, On Fri, 2024-06-28 at 18:46 +0200, Andreas Metzler wrote: > On 2024-06-26 Baptiste Beauplat <lykn...@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
signature.asc
Description: This is a digitally signed message part
