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. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
